ASP.NET MVC中的安全性

最新推荐文章于 2023-04-20 16:47:28 发布

寒冰屋

最新推荐文章于 2023-04-20 16:47:28 发布

阅读量1.1k

点赞数

分类专栏： MVC 架构及框架 CSharp.NET 文章标签： MVC 安全性

原文链接：https://www.codeproject.com/Articles/654846/Security-In-ASP-NET-MVC

版权

CSharp.NET 同时被 3 个专栏收录

1368 篇文章

订阅专栏

架构及框架

655 篇文章

订阅专栏

MVC

82 篇文章

订阅专栏

我们如何使用Windows身份验证进行身份验

介绍

在本文中，我想解释一些在开发安全的ASP.NET MVC应用程序时应该注意的安全措施。在本文中，我将解释：

认证
授权
XSS
CSRF（跨站请求伪造）

认证

对用户进行身份验证时，您将验证用户的身份。如果您需要验证MVC应用程序中的用户，可能是因为您正在构建一个限制对特定用户的访问的应用程序。这与授权完全分开，授权决定是否允许特定人员执行某项操作。

MVC中有两种身份验证机制：

表单身份验证
Windows身份验证

表单身份验证

基于表单的身份验证提供了一个输入表单，用户可以在该表单中输入用户名和密码以及验证这些凭据所需的应用程序中的逻辑。MVC为表单身份验证提供了大量基础结构支持。表单身份验证是高度可自定义的，您可以自定义从登录表单到凭据存储位置以及如何验证这些凭据的所有内容。ASP.NET中的表单身份验证默认情况下依赖于Cookie。用户登录到应用程序后，运行时可以在浏览器上发出cookie。然后，浏览器将向每个后续请求发送cookie给应用程序。ASP.NET将看到cookie并知道用户已经通过身份验证，无需再次登录。

注意：要使表单身份验证安全，需要使用SSL警告。如果您通过http运行应用程序，则任何窥探网络的人都可以看到用户凭据。

Windows身份验证

Windows身份验证也称为集成身份验证，因为Windows操作系统中内置的用户组件用于对用户进行身份验证。用户登录到域后，Windows可以自动将其验证到应用程序中。Windows身份验证通常用于在公司防火墙内运行的Intranet应用程序，其中所有用户都登录到Windows域。它将提供单点登录体验。他们在域中登录一次，并可以通过多个Intranet应用程序进行身份验证。

我们何时选择表单身份验证以及何时选择Windows身份验证？

如果您想构建一个公共网站，那么表单身份验证最好，因为它可以在Windows域之外使用。
如果要构建使用Windows标识运行的Intranet应用程序，请使用Windows身份验证。

如何配置表单身份验证？

首先，我们需要在web.config中更改配置，如下所示：

<authentication mode="Forms">
    <forms loginUrl="~/Account/Login" timeout="2880 />
</authentication>

这个配置位告诉运行时何时需要对用户进行身份验证，重定向浏览器到/Account/Logon。此Account控制器和此登录视图以及其他一些视图允许我在网站上注册。ASP.NET MVC Internet模板中默认提供这些内容。表单身份验证所需的一切都随此模板一起提供。

选择表单身份验证模板

打开Visual Studio 2010 >>新建项目>>选择“ASP.NET MVC4 Web应用程序”，然后单击“确定”。

然后选择互联网应用程序模板，其为我们提供了所需的表单验证，如AccountController，Views等等，然后单击确定。

授权

[Authorize]
public ActionResult Index()
{
    return View();
}

该Authorize属性并不真正关心我们如何验证用户。我们可以使用表单身份验证或Windows身份验证。所有授权关心的是用户具有身份并且我们知道他们是谁并且它不会让匿名用户进入Index操作。当我们尝试在不进行身份验证的情况下执行Index操作时，它会自动重定向到Account/Logon，因为用户在此应用程序中没有帐户。所以我们需要注册Logon。

我们如何使用Windows身份验证进行身份验

首先，我们需要在web.config文件中的下面的配置部分中进行一些更改。

<authentication mode="Windows">
    <!--<forms loginUrl="~/Account/Login" timeout="2880" />-->
</authentication>

然后将authorize属性应用于index操作：

[Authorize]
public ActionResult Index()
{
    return View();
}

您可以将授权过滤器应用于单个操作方法或控制器。将过滤器应用于控制器时，它的工作方式就好像您已经将它应用于控制器类中的每个操作方法，并将Authorize筛选器应用于该类，所以Account控制器中的所有操作方法都只对经过身份验证的用户可用。

为了使Windows集成身份验证能够正常工作，我们需要在IIS Express中启用Windows身份验证，否则我们会收到以下错误，这就是您今天的服务器配置中常见的情况。

服务器程序（如Web服务和数据库服务）通常默认关闭功能以减少攻击面。如果我们想要Windows身份验证工作，我们需要打开它。

转到文档>> IISExpress >> config >> applicationhost.config文件并启用Windows身份验证为true。

您可以获取如下认证详细信息：

授权

authorize属性还允许您设置一些参数以强制执行授权规则。首先，我们需要知道用户的身份，然后我们只能说出允许访问这些操作的特定身份。

[Authorize(Users = "jameel,vinayan")]
public ActionResult Index()
{
    ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
    
    return View();
}

Authorize属性还允许您指定角色。Windows身份验证（默认情况下）映射到服务器上的Windows组或活动目录中配置的组。你可以把角色放在下面：

[Authorize(Roles = "@domainname\username")]
public ActionResult Index()
{
    ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
    
    return View();
}

在Forms身份验证中，ASP.NET具有角色提供程序。通过使用这些，您可以在SqlServer数据库中存储，管理角色。默认情况下，可以在应用程序中配置它们。最简单的方法是使用解决方案资源管理器中的以下按钮。

它启动了ASP.NET配置工具。这是您将仅在本地开发计算机中使用的工具。它将查看web.config位置并使用与已在其中配置的表单身份验证提供程序使用相同的应用程序服务数据库。您可以从此处添加，管理角色。执行这些操作时，它会自动映射到我们在web.config文件中配置的db。

XSS

我们将面临一些具体的威胁。此阶段的一个流行攻击是跨站点脚本攻击或XSS。在跨脚本攻击中，恶意用户会尝试让您的网站将恶意脚本加载到用户的浏览器中。它可能是恶意脚本，Active-X控件，甚至是一些恶意HTML。恶意脚本可以窃取cookie，修改用户设置，下载恶意软件或修改内容。最糟糕的跨站点脚本攻击之一是Account Hijacking;恶意用户可以访问用户的凭据和个人信息。

一旦发生这种情况，您的用户就会容易受到任何问题的影响。

演示

这是一个用于保存员工信息的简单应用程序。我正在放置一些HTML标签，就像我来自<em> India </ em>，然后当我尝试保存它时，ASP.NET自动拒绝此请求以防止跨站点脚本攻击，因为ASP.NET将查找类似于HTML的任何内容，并拒绝请求。实际上，强调标签没有任何问题，但是ASP.NET并没有试图在这里进行区分，任何看起来像HTML的东西都将被拒绝。

有时，用户需要将一些HTML上传到服务器，然后始终绕过此请求验证。你必须非常小心。一个选择是将ValidationInput属性放在Create操作上。

因此，您可以成功处理此请求。

现在我们可能遇到HTML编码的问题。这是因为razor默认会对所有内容进行编码，这很好。对于跨站点脚本还有另一种防御，我们可以轻松解决这个问题。但是，验证输入false完全禁用对跨站点脚本、恶意HTML的检查，实际上我们只需要在一个特定属性中使用HTML。因此，您可以使用该AllowHtml属性将HTML允许到一个属性。此外，还需要进行一些更改，从Create操作中删除ValidateInput属性，并确保我们应该将EmployeeViewModel类作为操作参数传递，这意味着将发生模型绑定并将HTML移动到该属性。此外，视图中的一个变化是通过将ViewData放入Html.Raw帮助器来显示不带编码的HTML。

然后，再次保存一个ViewData并在包含HTML标记的同一视图中显示。

Anti XSS Library

有人来到表单并输入如下脚本：

它也更恶毒。幸运的是，Microsoft提供了一个用于防止这种情况的库。您可以通过nugget或Library Package Manager控制台（Visual Studio >>工具>>库包管理器>>包管理器控制台Install-Package AntiXSS）下载它，然后键入并按Enter键。

我要做的是我在下面的Edit action post方法中添加一行代码。

此代码将删除所有恶意内容。

跨站点请求伪造

跨站点请求伪造是一种危险且极其重要的攻击。想象一下，用户进入该站点，尝试更新一些需要身份验证的信息，然后才允许他们执行更新。一旦用户登录表单身份验证，您的站点将向用户浏览器发送身份验证cookie以及该站点的每个后续请求，用户浏览器将发送该cookie，并且ASP.NET将看到用户已经通过过身份验证。浏览器发送cookie没有任何问题，这就是浏览器和cookie的工作方式 - 这意味着用户不需要在他们发出的每个请求中输入用户名和密码。他们对自己进行一次身份验证，并且cookie将允许他们至少在会话期间保持身份验证。

那问题是什么？

如果用户访问其他网站或严格从恶意源中提取HTML，而恶意源有恶意，则此恶意源可以提供表单，就像我们的应用程序会提供给用户表单一样，然后如果用户再次提交表单，身份验证将再次被调用，因为身份验证cookie将提供给用户的浏览器。始终沿着每个请求行进，它会像我们在对请求进行身份验证一样将信息保存到数据库中。只有当请求中的信息可能是用户想要提交的内容。有人欺骗用户转账或编辑账户。这里的问题不是简单地说我们需要在提交一些信息时对用户进行身份验证。我们还必须检查用户提交的信息来自我们的应用程序提供给用户的表单。我们希望在从恶意来源提交表单时阻止它们。

演示

为了演示CSRF，我将authorize属性应用于我的应用程序的两个Edit操作方法。

//
// GET: /CSRF/Edit/5
[Authorize]
public ActionResult Edit(int id = 0)
{
    Employee employee = db.Employees.Find(id);
    if (employee == null)
    {
        return HttpNotFound();
    }
    return View(employee);
}

//
// POST: /CSRF/Edit/5

[HttpPost]
[Authorize]
public ActionResult Edit(Employee employee)
{
    if (ModelState.IsValid)
    {
        db.Entry(employee).State = EntityState.Modified;
        db.SaveChanges();
        return RedirectToAction("Index");
    }
    return View(employee);
}

我可以保存，编辑记录，因为我已经通过身份验证。下面是我成功保存到数据库中的示例记录。