安全在web领域是一个永远都不会过期的话题,今天咱们就来看一看一些在开发ASP.NET MVC应用程序时一些值得咱们注意的安全问题。本篇主要包括如下几个内容 :web
所谓认证,简单的来讲就是验证一个用户的身份。这取决于咱们开发的站点的类型,是否容许匿名访问,是不是属于管理员或者其它角色的用户等等。也就是说咱们的整个程序或者某些功能是针对某些特定的用户开发的,那么咱们可能就要进行认证来肯定用户的身份。须要注意的是,认证与受权是是彻底不同的概念,咱们要区别对待。打个比方,在ASP.NET MVC里面容许某一类用户访问某个Action就是受权。windows
ASP.NET MVC中主要有两种认证机制浏览器
从字面上咱们就能够获得一些信息,基于表单的认证提供给用户一个表单能够输入用户名和密码,而后咱们能够在咱们的程序中写本身的逻辑去验证这些信息。ASP.NET MVC为Forms认证提供了不少支持,而且有很强自定义性。从经过表单登陆到用户信息存储在什么地方,到怎么样去验证这些用户信息。Forms认证默认是依靠cookie技术实现的,一旦某个用户登陆站点,那么用户所使用的这个浏览器就会获得一个cookie而且在后面全部与这个站点的其它请求中都会将这个cookie包含在http的头中。ASP.NET可以检测到这个cookie,这个cookie中包含了用户的认证信息,那么后面就不须要再重复的认证用户了。安全
Windows 认证也就是你们熟悉的集成身份认证,由于它使用了集成在Windows操做系统中的用户组件来认证用户。一旦某个用户登陆到域中,Windows可以在应用程序中自动认证他们。Windows认证通常在企业局域网内比较经常使用,通常企业局域网中全部的用户都须要用域身份来登陆,这个有点像单点登陆的体验,一旦进入域中就能够就能够很方便的同时登陆域内的其它应用程序。服务器
首先咱们须要更改web.config中的authentication结点。cookie
这个配置信息很简单,首先咱们要使用的authentication类型是Forms认证。经过loginUrl指定咱们认证用户的页面。这个Account Controller和 Login View还有一些容许用户注册的View都被ASP.NET MVC的internet模板默认实现了。咱们能够垂手可得在在ASP.NET MVC中实现Forms认证。app
打开Visual Studio 2010 > New Project > Select ASP.NET MVC 4 Web Application 点击确认。ide
而后选择Internet Application点击确认,Forms认证所须要的Controller 和View等等都会默认包含在咱们的项目里面了。网站
Authorize不关注咱们如何认证用户,咱们既能够用Forms认证也能够用Windows认证。Authorize会去检测当前用户是否有身份信息。若是咱们在Index上加上Authorize属性那么匿名用户就不能访问咱们的Index Action了。他们会被跳转到Account/Login,也就是咱们上面在web.config中配置的loginUrl。
和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中的链接字符串。
在web领域,有几个比较常见的安全隐患,其中一个比较流行的就是跨站脚本攻击。一些恶意的用户经过一些手段让咱们的站点加载一些恶意的脚本,那么若是其它用户访问到这些脚本就有可能成为受害者。除了脚本,包括active-x控件,甚至一些恶意的Html均可以成为XSS的武器。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输出到客户端。
若是咱们容许用户输入html的话,有些人可能会尝试输入一些脚本 (不要说你没有想过在博客园输入一些脚原本玩玩?)
幸运的是,Microsoft为咱们提供了一个组件,咱们能够经过nugget或者Library Package Manager Console( Visual Studio > Tools > Library Package Manager > Package Manager Console 输入 Install-Package AntiXss回车 )
只须要简单的一句话,就能够移除全部的有害代码,是否是感受又被Microsoft搞蠢了?
跨站请求伪造也是一种危险的主流攻击。试想一下,某个用户登陆到网站想修改一些我的信息,若是服务器端使用了Forms认证,那么在这个用户登陆以后就会获得一个包含身份信息的cookie而且在后面全部这个站点下的请求中传递。固然这个并无错,毕竟若是每次都去验证用户名和密码是一次不小的开销,验证一次以后将登陆信息保存到cookie中,至少在用户不关闭浏览器以前,咱们不用再从新去验证用户。
若是浏览器端依然保留着个人身份信息,那在我访问其余恶意的站点的时候。这些恶意的站点就能够本身封装一个表单并提交到咱们的服务器,虽然这个请求时恶意站点伪造的,可是由于它带有用户的身份,因此服务器是会正常处理的。小到更改用户资料,大到转走用户的帐户余额都成为可能。
因此咱们在处理请求的时候,不只仅须要验证用户身份信息,还须要确保发送数据的表单是由咱们服务器产生的。这样就能够避免其余恶意用户伪造表单发送数据。
这里有一段很常见的代码,经过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
本篇是根据上面的文章按照个人理解翻译的。
今天的故事就讲到这里,谢谢你们的收看!