MVC 2 AntiForgeryToken - 为什么对称加密+ IPrinciple？

我们最近更新了我们的MVC 2解决方案,这已经更新了它的AntiForgeryToken工作方式.不幸的是,这不再符合我们的AJAX框架.

问题是MVC 2现在使用对称加密来编码关于用户的一些属性,包括用户的Name属性(来自IPrincipal).我们能够使用AJAX安全地注册新用户,之后后续的AJAX调用将无效,因为当用户被授予新的主体时,防伪令牌将会改变.还有其他可能发生这种情况的情况,例如用户更新姓名等.

我的主要问题是为什么MVC 2甚至会使用对称加密？那为什么它关心主体上的用户名属性呢？

如果我的理解是正确的,那么任何随机共享秘密都可以.基本原则是将向用户发送带有一些特定数据的cookie(HttpOnly!).然后,需要此cookie来匹配发回的表单变量以及可能具有副作用的每个请求(通常是POST).由于这只是为了防止跨站点攻击,因此很容易制定一个易于通过测试的响应,但前提是您可以完全访问cookie.由于跨站点攻击者无法访问您的用户cookie,因此您受到保护.

通过使用对称加密,检查cookie内容有什么好处？也就是说,如果我已经发送了一个HttpOnly cookie,攻击者就无法覆盖它(除非浏览器存在重大安全问题),那么为什么我需要再次检查呢？

在考虑之后它似乎是那些"增加的安全层"案例之一 - 但是如果你的第一道防线已经下降(HttpOnly)那么攻击者无论如何都会通过第二层,因为他们有完全访问权限对用户cookie集合,可以直接模仿它们,而不是使用间接的XSS/CSRF攻击.

当然我可能会错过一个重大问题,但我还没有找到它.如果这里有一些明显或微妙的问题,那么我想了解它们.

添加它是为了在你有一个子域试图攻击另一个子域的情况下提供更好的保护 - bad.example.com试图攻击good.example.com.添加用户名会使bad.example.com更难以在幕后联系good.example.com并尝试让它代表您生成令牌.

展望未来,cookie可能会被删除,因为它对于系统的正常运行并不是绝对必要的.(例如,如果您正在使用表单身份验证,则该 cookie可以用作反XSRF cookie,而不是要求系统生成第二个cookie.)例如,可能仅在匿名用户的情况下发出cookie.