（转）asp.net mvc 开发环境下需要注意的安全问题（一）
概述
安全在web领域是一个永远都不会过时的话题，今天我们就来看一看一些在开发ASP.NET MVC应用程序时一些值得我们注意的安全问题。本篇主要包括以下几个内容 ：
认证
所谓认证，简单的来说就是验证一个用户的身份。这取决于我们开发的站点的类型，是否允许匿名访问，是否是属于管理员或者其它角色的用户等等。也 就是说我们的整个程序或者某些功能是针对某些特定的用户开发的，那么我们可能就要进行认证来确定用户的身份。需要注意的是，认证与授权是是完全不一样的概 念，我们要区别对待。打个比方，在ASP.NET MVC里面允许某一类用户访问某个Action就是授权。
ASP.NET MVC中主要有两种认证机制
- Forms 认证
- Windows 认证
Forms 认证
从字面上我们就可以得到一些信息，基于表单的认证提供给用户一个表单可以输入用户名和密码，然后我们可以在我们的程序中写自己的逻辑去验证这些 信息。ASP.NET MVC为Forms认证提供了很多支持，并且有很强自定义性。从通过表单登录到用户信息存储在什么地方，到怎么样去验证这些用户信息。Forms认证默认 是依靠cookie技术实现的，一旦某个用户登录站点，那么用户所使用的这个浏览器就会得到一个cookie并且在后面所有与这个站点的其它请求中都会将 这个cookie包含在http的头中。ASP.NET能够检测到这个cookie，这个cookie中包含了用户的认证信息，那么后面就不需要再重复的 认证用户了。
Windows认证
Windows 认证也就是大家熟悉的集成身份认证，因为它使用了集成在Windows操作系统中的用户组件来认证用户。一旦某个用户登录到域中，Windows能够在应 用程序中自动认证他们。Windows认证一般在企业局域网内比较常用，一般企业局域网中所有的用户都需要用域身份来登录，这个有点像单点登录的体验，一 旦进入域中就可以就可以很方便的同时登录域内的其它应用程序。
配置Forms认证
首先我们需要更改web.config中的authentication结点。
这个配置信息很简单，首先我们要使用的authentication类型是Forms认证。通过loginUrl指定我们认证用户的页面。这个 Account Controller和 Login View还有一些允许用户注册的View都被ASP.NET MVC的internet模板默认实现了。我们可以轻而易举在在ASP.NET MVC中实现Forms认证。
打开Visual Studio 2010 > New Project > Select ASP.NET MVC 4 Web Application 点击确认。
然后选择Internet Application点击确认，Forms认证所需要的Controller 和View等等都会默认包含在我们的项目里面了。
Authorize 属性
Authorize不关注我们如何认证用户，我们既可以用Forms认证也可以用Windows认证。Authorize会去检测当前用户是否 有身份信息。如果我们在Index上加上Authorize属性那么匿名用户就不能访问我们的Index Action了。他们会被跳转到Account/Login，也就是我们上面在web.config中配置的loginUrl。
如何配置Windows认证
和Forms认证一样，首先我们需要更改一下web.config中的authentication结点。
然后同样地，应用Authorize属性到我们的Index Action上。
我们可以将Authorize应用到一个单独的Action上，也可以应用到一个Controller上。当我们在某一个Controller 上应用Authorize属性时，也就意味着这个Controller下所有的Action都必须是经过认证的用户才允许访问 。
如果使用IIS Express的话，我们需要更改配置信息来启用Windows认证。否则我们就会得到以下错误页面。
我们可以到IIS Express的配置中去启用Windows认证，打开Windows Explorer进入我的文档>IIS Express > config > applicationhost.config。然后将windowsAuthentication enabled设置为true。
然后我们就可以拿到一些用户的信息。
授权
授权允许我们传递一些参数去设置规则，我们可以告诉Authroize属性只有某些具体用户才可以访问某个Action。
同时 ，我们还可以为Authorize属性指定 Roles。这些Roles默认匹配到我们web服务器的Windows Group或者是域管理器里面的用户组。
在Forms认证中, ASP.NET为我们提供了一个角色管理器（role provider）我们可以通过它来方便和将我们的角色信息存储到SQL中，并且进行管理。我们只需要点击一个按钮即可：
点击上面这个按钮之后，它会帮我们运行ASP.NET configuration tool。这个站点只能在本地运行，我们可以在这个站点管理我们的角色，这个站点默认使用的数据连接就是我们配置在web.config中的连接字符串。
XSS跨站脚本攻击
在web领域，有几个比较常见的安全隐患，其中一个比较流行的就是跨站脚本攻击。一些恶意的用户通过一些手段让我们的站点加载一些恶意的脚本，那么 如果其它用户访问到这些脚本就有可能成为受害者。除了脚本，包括active-x控件，甚至一些恶意的Html都可以成为XSS的武器。XSS可以做到哪 里事情 ？
- 窃取cookie
- 更改用户设置
- 下载恶意软件
- 更改内容
- 账户劫持
简单的说，我们可以通过XSS访问用户的个人信息以及身份信息。
XSS示例
这是一个简单的录入员工信息的页面，我们输入一些html代码然后保存页面。ASP.NET默认会去检测我们的request，发现类似html代码会直接拒绝我们的请求。
当然，有些时候我们需要允许用户输入html，那么只要在我们的Action上打上ValidateInput(false)即可。
这样我们就可以成功的提交 我们的请求了。
如上图所示，这样我们又遇到了另外一个问题。在ASP.NET MVC中razor默认会对所有输出进行html编码。这是ASP.NET MVC针对XSS攻击的另一道防火墙。通过为属性打上AllowHtml属性，我们可以允许某一个属性包含html的值，这样我们就可以移除Action 上的ValidateInput属性。通过Html.Raw 我们可以将html输出到客户端。
Anti XSS library
如果我们允许用户输入html的话，有些人可能会尝试输入一些脚本 (不要说你没有想过在博客园输入一些脚本来玩玩？)
幸运的是，Microsoft为我们提供了一个组件，我们可以通过nugget或者Library Package Manager Console( Visual Studio > Tools > Library Package Manager > Package Manager Console 输入 Install-Package AntiXss回车 )
只需要简单的一句话，就可以移除所有的有害代码，是不是感觉又被Microsoft搞蠢了？
CSRF跨站请求伪造
跨站请求伪造也是一种危险的主流攻击。试想一下，某个用户登录到网站想修改一些个人信息，如果服务器端使用了Forms认证，那么在这个用户登 录之后就会得到一个包含身份信息的cookie并且在后面所有这个站点下的请求中传递。当然这个并没有错，毕竟如果每次都去验证用户名和密码是一次不小的 开销，验证一次之后将登录信息保存到cookie中，至少在用户不关闭浏览器之前，我们不用再重新去验证用户。
安全隐患在哪里？
如果浏览器端依然保留着我的身份信息，那在我访问其他恶意的站点的时候。这些恶意的站点就可以自己封装一个表单并提交到我们的服务器，虽然这个 请求时恶意站点伪造的，但是因为它带有用户的身份，所以服务器是会正常处理的。小到更改用户资料，大到转走用户的账户余额都成为可能。
所以我们在处理请求的时候，不仅仅需要验证用户身份信息，还需要确保发送数据的表单是由我们服务器产生的。这样就可以避免其他恶意用户伪造表单发送数据。
CSRF示例
这里有一段很常见的代码，通过Edit Action来编辑用户信息。我们已经为Edit 打上了Authorize属性，也就是说用户是需要登录才能访问这个Action的。从普通开发的角度来看，这个程序是不会有什么问题的，我们首先通过正常渠道添加了一个用户。
接下来，很雷很雷的事情发生了。你收到一封邮件说你中奖了，给了你一个链接，或者在某个网站上本身就嵌入了一些恶意代码，而你不幸手一抖，就点了。接下来结果有可能是这样滴。
你的数据很轻松就被篡改了。如果账号是有余额的，你就哭吧。来看看这个页面 是如何实现的。
非常的简单，我们只需要将form的action指向实际的action就可以了。这个页面一旦被加载，这个表单就会自动提交，那我们的数据就被黑了，一切都是那么的简单。
如何避免？
ASP.NET MVC 为我们提供了Html.AntiForgeryToken() 方法，我们只需要在form中添加这句话。MVC 会为我们生成一个唯一标识放在form中的一个隐藏域中，该标识还会被存放到cookie中在客户端和服务器的请求中传输。另外我们要做的就是为我们的 Action打上ValidateAntiForgeryToken的属性。
如果请求不包含这个cookie，那服务器就会拒绝这个请求，从而避免CSRF的攻击。
原文：http://www.codeproject.com/Articles/654846/Security-In-ASP-NET-MVC
本篇是根据上面的文章按照我的理解翻译的。
今天的故事就讲到这里，谢谢大家的收看！
