认识ASP.NET MVC的5种AuthorizationFilter一、IAuthorizationFilter二、AuthorizeAttribute三、RequireHttpsAttribute 四、ValidateInputAttribute五、ValidateAntiForgeryTokenAttribute六、ChildActionOnlyAttribute

目录 一、IAuthorizationFilter 二、AuthorizeAttribute 三、RequireHttpsAttribute 四、ValidateInputAttribute 五、ValidateAntiForgeryTokenAttribute 六、ChildActionOnlyAttribute

AuthorizationContext的ActionDescriptor属性表示描述当前执行Action的ActionDescriptor对象，而Result属性返回一个用于在授权阶段呈现的ActionResult。AuthorizationFilter的执行是ActionInvoker进行Action执行的第一项工作，因为后续的工作（Model绑定、Model验证、Action方法执行等）只有在成功授权的基础上才会有意义。

ActionInvoker在通过执行AuthorizationFilter之前，会先根据当前的Controller上下文和解析出来的用于描述当前Action的ActionDescriptor，并以此创建一个表示授权上下文的AuthorizationContext对象。然后将此AuthorizationContext对象作为参数，按照Filter对象Order和Scope属性决定的顺序执行所有AuthorizationFilter的OnAuthorization。

在所有的AuthorizationFilter都执行完毕之后，如果指定的AuthorizationContext对象的Result属性表示得ActionResult不为Null，整个Action的执行将会终止，而ActionInvoker将会直接执行该ActionResult。一般来说，某个AuthorizationFilter在对当前请求实施授权的时候，如果授权失败它可以通过设置传入的AuthorizationContext对象的Result属性响应一个“401，Unauthrized”回复，或者呈现一个错误页面。

很多会将AuthorizeAttribute对方法的授权与PrincipalPermissionAttribute等同起来，实际上不但它们实现授权的机制不一样（后者是通过代码访问安全检验实现对方法调用的授权），它们的授权策略也一样。以下面定义的两个方法为例，应用了PrincipalPermissionAttribute的FooOrAdmin意味着可以被帐号为Foo或者具有Admin角色的用户访问，而应用了AuthorizeAttribute特性的方法FooAndAdmin方法则只能被用户Foo访问，而且该用户必须具有Admin角色。也就是说PrincipalPermissionAttribute特性对User和Role的授权逻辑是“逻辑或”，而AuthorizeAttribute 采用的则是“逻辑与”。

除此之外，我们可以将多个PrincipalPermissionAttribute和AuthorizeAttribute应用到同一个类型或者方法上。对于前者，如果当前用于通过了任意一个PrincipalPermissionAttribute特性的授权就有权调用目标方法；对于后者来说，意味着需要通过所有AuthorizeAttribute特性的授权在具有了调用目标方法的权限。以如下两个方法为例，用户Foo或者Bar可以有权限调用FooOrBar方法，但是没有任何一个用户有权调用CannotCall方法（因为一个用户只一个用户名）。

如果当前请求的HTTP方法并不是GET，RequireHttpsAttribute会直接抛出一个InvalidOperationException异常。如上面的代码片断所示，针对非HTTPS请求的处理通过调用受保护的方法HandleNonHttpsRequest来完成，如果我们需要不同的处理，可以继承RequireHttpsAttribute并重写该方法。

为了避免用户在请求中包含一些不合法的内容对网站进行恶意攻击（比如XSS攻击），我们一般需要对请求的输入进行验证。如下面的代码片断所示，表示HTTP请求的基类HttpRequestBase具有一个ValidateInput方法用于验证请求的输入。实际上这个方法仅仅是在请求上作一下标记而已，在读取相应的请求输入时才根据这些表示决定是否需要进行相应的验证。不过为了便于表达，我们就将针对该ValidateInput方法的调用说成是针对请求输入的验证。

所有Controller的基类ControllerBase具有如下一个布尔类型的属性ValidateRequest表示是否需要对请求输入进行验证，在默认情况下该属性的默认值为True，意味着针对请求输入的验证默认情况下是开启的。

当ActionInvoker在完成了对所有AuthorizationFilter的执行之后，会根据该属性决定是否会通过调用表示当前请求的HttpRequest对象的ValidateInput方法进行请求输入的验证。

为了让读者对ValidateInputAttribute这个AuthorizationFilter针对开启和关闭输入验证的作用有一个深刻映像，我们来进行一个简单的实例演示。在通过Visual

Studio的ASP.NET MVC项目模板创建的空Web应用中我们

定义了如下一个HomeController，包含在该Controller中的两个Action方法（Action1和Action2）具有一个字符串类型的参数foo，其中Action1上应用了ValidateInputAttribute特性并将参数设置为False。

我们直接运行该程序并在浏览器中通过输入相应的地址来访问这两个Action，并以查询字符串的形式指定它们的两个参数。为了检验ASP.NET MVC对请求输入的验证，我们将表示参数foo的查询字符串的值设置为为“<script></script>”。如下图所示，Action1能够正常地被调用，而Action2在调用过程中抛出异常 ，并提示请求中包含危险的查询字符串。

<a href="http://images.cnblogs.com/cnblogs_com/artech/201207/201207022238244467.png"></a>

具有如下定义的System.Web.Mvc.ValidateAntiForgeryTokenAttribute用于解决一种叫做“跨站请求伪造（CSRF：Cross-Site Request Forgery）”。这是一种不同于XSS（Cross Site Script）的跨站网络攻击，如果说XSS是利用了用户对网站的信任，而CSRF就是利用了站点对认证用户的信任。

我们通过一个简单的例子来对CSRF的原理进行说明。假设我们通过ASP.NET

MVC构建了一个博客应用，作为博主的用户可以发表博文，而一般用于可以对博文发表评论。除此之外，注册用于可以修改自己的Email地址，相关的操作定义在如下所示的BlogController的Action方法UpdateAddress中。

对于上面定义的UpdateEmailAddress方法，由于应用了AuthorizeAttribute特性，意味着只有认证的用户才能调用它来修改自己提供的Email地址。此外，HttpPostAttribute特性应用在该Action方法上，使我们只能以POST请求的方式调用它，这无形之中也增强了安全系数。但是这个方法提供的Email修改功能真的安全吗？它真的确保修改后的Email地址真的是登录用户提供的Email地址吗？

我们假设BlogController所在的Web应用部署的域名为Foo，那么Action方法UpdateEmailAddress对应的地址可以表示为http://foo/blog/updateemailaddress。现在一个恶意攻击者创建如下一个简单的HTML页面，该页面具有一个指向上面这个地址的表单，并且该表单中具有一个名为emailAddress

&lt;input&gt;元素提供属于供给者自身的Email地址。由于注册了window的onload事件，该表单会在页面加载完成之后自动提交。

&lt;/script&gt;

假设攻击者部署该页面的地址为http://bar/maliciouspage.html。然后它通过某篇博文中添加一个包含如下链接的评论。作为登录用户的你点击该连接后将会间接地调用定义在BlogController的UpdateEmailAddress方法。由于登录用户的安全令牌一般以Cookie形式存在，而该Cookie会存在于发送给针对Action方法UpdateEmailAddress的调用请求中，服务器会认为该请求来自被认证用户，所以最终造成了你的Email地址被恶意修改而不自知。如果攻击者具有你的用户名，它可以通过重置密码，是新的密码发送到属于他自己的电子邮箱中。

这个例子充分说明了CSRF是一种比较隐蔽并且具有很大危害型的网络攻击，促成攻击的原因在于服务器在针对某个请求执行某个操作的时候并没有验证请求的真正来源。对于ASP.NET

MVC来说，如果我们在执行某个Action方法之前能够确认当前的请求来源的有效性，就能从根本上解决CSRF攻击，而ValidateAntiForgeryTokenAttribute结合HtmlHelper的AntiForgeryToken方法有效地解决了这个问题。

如上面的代码片断所示，HtmlHelper具有三个AntiForgeryToken方法（这里的方式是HtmlHelper的实例方法，不是扩展方法）。当我们在一个View中调用这些方法是，它们会为我们生成一个所谓“防伪令牌（Anti-Forgery Token）”的字符串，并以此生成一个类型为Hidden的&lt;input&gt;元素。除此之外，该方法的调用还会根据这个防伪令牌设置一个Cookie。接下来我们来详细地来讨论这个过程。

上述的这个防伪令牌通过内部类型为AntiForgeryData的对象生成。如下面的代码片断所示，AntiForgeryData具有四个属性，其核心是通过属性Value表示的值。属性UserName和CreationDate表示访问令牌授权的用户名和创建时间。字符串属性Salt是为了增强防伪令牌的安全系数，不同的Salt值对应着不同的防伪令牌，不同的防伪令牌在不同的地方被使用以避免供给者对一个防伪令牌的破解而使整个应用受到全面的攻击。ValidateAntiForgeryTokenAttribute也具有一个同名的属性。

当AntiForgeryToken被调用的时候，会先根据当前的请求的应用路径（对应HttpRequest的ApplicationPath属性）计算出表示防伪令牌Cookie的名称，该名称会在通过对应用路径进行Base64编码（编码之前需要进行一些特殊字符的替换工作）生成的字符串前添加“__RequestVerificationToken”前缀。

如果当前请求具有一个同名的Cookie，则直接通过对Cookie的值进行反序列化得到一个AntiForgeryData对象。需要注意的是，这里针对AntiForgeryData进行序列化和反序列化并不是一个简单地实现运行时对象到字符串之间的转换，还包含采用MachineKey对AntiForgeryData的四个属性进行加密/解密的过程。如果这样的Cookie不存在，HtmlHelper会随机生成一个长度为16的字节数组，并将对该字节数组进行Base64编码后生成的字符串作为值创建一个AntiForgeryData对象。系统当前时间（UTC）作为该AntiForgeryData对象的创建时间，但是该AntiForgeryData对象的UserName和Salt属性为空。

接下来HtmlHelper会根据之前计算出来的Cookie名称创建一个）HttpCookie对象，而新创建出来的AntiForgeryData对象被序列化后生成的字符串作为该HttpCookie的值。如果我们在AntiForgeryToken方法调用中设置了表示域和路径的domain和path参数，它们将会作为该HttpCookie对象的Path和Domain属性。最后HtmlHelper将HttpCookie对象设置给当前的HTTP响应。

AntiForgeryToken返回的是一个类型为hidden的&lt;input&gt;元素对应的HTML，该Hidden元素的名称为“__RequestVerificationToken”（即代码访问令牌Cookie名称的前缀）。为了生成该Hidden元素的值，HtmlHelper会根据现有的AntiForgeryData对象（从当前请求获取的或者新创建的）创建一个新的AntiForgeryData对象，两个对象具有相同的CreationDate和Value属性，而当前用户名和指定的Salt参数将会设置给新AntiForgeryData对象的UserName和Salt属性。

在一个View中我们通过如上的代码在一个表单中调用HtmlHelper的AntiForgeryToken方法并将一个GUID作为Salt，最终将会生成如下一个名为“__RequestVerificationToken”的Hidden元素。

对于该View的首次访问（或者对应的Cookie不存在），如下所示的名称为“__RequestVerificationToken_L012Y0FwcDEx”防伪令牌Cookie将会设置，并且是HttpOnly的。

对于一个请求，如果确保请求提供的表单中具有一个名为“__RequestVerificationToken”的Hidden元素，并且该元素的值与对应的防伪令牌的Cookie值相匹配，就能够确保请求并不是由第三方恶意站点发送的，进而防止CSRF攻击。原因很简单：由于Cookie值是经过加密的，供给者可以得到整个Cookie的内容，但是不能解密获得具体的值（AntiForgeryData的Value属性），所以不可能在提供的表单中也包含一个具有匹配值的Hidden元素。针对防伪令牌的验证就实现在ValidateAntiForgeryTokenAttribute的OnAuthorization方法中。

然后从提交的表单中提取一个名称为“__RequestVerificationToken”的输入元素，如果这样的元素不存在，同样抛出HttpAntiForgeryException异常；否则直接对具体的值进行反序列化生成一个AntiForgeryData对象。最后ValidateAntiForgeryTokenAttribute对这两个AntiForgeryData的Value属性进行比较，以及后者的UserName和Salt属性与当前用户名和自身的Salt属性值进行比较，任何一个不匹配都会抛出HttpAntiForgeryException异常。

有的读者可能会问，AuthorizationFilter如何区分当前的请求是基于子Action的调用，而不是一般的Action调用呢？其实很简单，当我们在调用HtmlHelper的扩展方法Action或者RenderAction的时候会将当前的View上下文作为“父View上下文”保存到表示当前路由信息的RouteData的DataTokens属性中，对应的Key为“ParentActionViewContext”。如下面的代码片断所示，ControllerContext中用于判断是否为子Action请求的IsChildAction属性正式通过该路由信息进行判断的。

作者：蒋金楠

微信公众账号：大内老A

如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

<a href="http://www.cnblogs.com/artech/archive/2012/07/02/AuthorizationFilter.html" target="_blank">原文链接</a>