MVC 2 AntiForgeryToken - 为什么采用对称加密 + IP原则？
我们最近将解决方案更新为 MVC 2，这更新了 AntiForgeryToken 的工作方式。不幸的是，这不再适合我们的 AJAX 框架。
问题在于，MVC 2 现在使用对称加密来对有关用户的某些属性进行编码，包括用户的 Name 属性（来自 IPrincipal）。我们能够使用 AJAX 安全地注册新用户，之后后续的 AJAX 调用将无效，因为当用户被授予新主体时，防伪令牌将发生变化。还有其他情况可能会发生这种情况，例如用户更新其姓名等。
我的主要问题是为什么 MVC 2 甚至不使用对称加密？那么为什么它关心主体上的用户名属性呢？
如果我的理解是正确的，那么任何随机的共享秘密都可以。基本原理是向用户发送一个带有一些特定数据的 cookie（HttpOnly！）。然后需要此 cookie 来匹配随每个可能产生副作用的请求（通常是 POST）发回的表单变量。由于这只是为了防止跨站点攻击，因此很容易制作一个可以轻松通过测试的响应，但前提是您拥有对 cookie 的完全访问权限。由于跨站点攻击者无法访问您的用户 cookie，因此您受到了保护。
通过使用对称加密，检查cookie的内容有什么好处？也就是说，如果我已经发送了 HttpOnly cookie，攻击者就无法覆盖它（除非浏览器存在重大安全问题），那么为什么我需要再次检查它呢？
想一想，这似乎是“增加安全层”的情况之一 - 但如果你的第一道防线已经失效（仅 Http），那么攻击者无论如何都会突破第二层，因为他们拥有完全访问权限到用户的 cookie 集合，并且可以直接模拟他们，而不是使用间接的 XSS/CSRF 攻击。
当然，我可能会遗漏一个重大问题，但我还没有找到它。如果这里存在一些明显或微妙的问题，那么我想了解它们。
We recently updated our solution to MVC 2, and this has updated the way that the AntiForgeryToken works. Unfortunately this does not fit with our AJAX framework any more.
The problem is that MVC 2 now uses symmetric encryption to encode some properties about the user, including the user's Name property (from IPrincipal). We are able to securely register a new user using AJAX, after which subsequent AJAX calls will be invalid as the anti forgery token will change when the user has been granted a new principal. There are also other cases when this may happen, such as a user updating their name etc.
My main question is why does MVC 2 even bother using symmetric encryption? And then why does it care about the user name property on the principal?
If my understanding is correct then any random shared secret will do. The basic principle is that the user will be sent a cookie with some specific data (HttpOnly!). This cookie is then required to match a form variable sent back with each request that may have side effects (POST's usually). Since this is only meant to protect from cross site attacks it is easy to craft up a response that would easily pass the test, but only if you had full access to the cookie. Since a cross site attacker is not going to have access to your user cookies you are protected.
By using symmetric encryption, what is the advantage in checking the contents of the cookie? That is, if I already have sent an HttpOnly cookie the attacker cannot override it (unless a browser has a major security issue), so why do I then need to check it again?
After having a think about it it appears to be one of those 'added layer of security' cases - but if your first line of defence has fallen (HttpOnly) then the attacker is going to get past the second layer anyway as they have full access to the users cookie collection, and could just impersonate them directly, instead of using an indirect XSS/CSRF attack.
Of course I could be missing a major issue, but I haven't found it yet. If there are some obvious or subtle issues at play here then I would like to be aware of them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
添加它是为了在一个子域试图攻击另一个子域的情况下提供更好的保护 - bad.example.com 试图攻击 good.example.com。添加用户名会使 bad.example.com 更难以在幕后联系 good.example.com 并尝试让它代表您生成令牌。
展望未来，cookie 可能会被删除，因为它对于系统的正常运行并不是绝对必要的。 （例如，如果您使用表单身份验证，该 cookie 可以充当反 XSRF cookie，而不是要求系统生成第二个 cookie。）该 cookie 可能仅在以下情况下发出例如，匿名用户。
It was added to offer greater protection in the case where you have one subdomain trying to attack another - bad.example.com trying to attack good.example.com. Adding the username makes it more difficult for bad.example.com to contact good.example.com behind the scenes and try to get it to generate a token on your behalf.
Going forward, it's possible that the cookie will be removed as it's not strictly necessary for the proper functioning of the system. (For example, if you're using Forms Authentication, that cookie could serve as the anti-XSRF cookie instead of requiring the system to generate a second cookie.) The cookie might only be issued in the case of anonymous users, for example.
除了 Levi 概述的“邪恶子域”场景之外，请考虑在目标站点上拥有帐户的攻击者。如果 CSRF 令牌未对用户特定信息进行编码，则服务器无法验证该令牌是否是专门为登录用户生成的。然后，攻击者可以在构建伪造请求时使用他自己合法获取的 CSRF 令牌之一。
话虽如此，匿名令牌在某些情况下会被 ASP.NET MVC 接受。请参阅为什么 ValidateAntiForgeryTokenAttribute 允许匿名令牌？
Besides the "evil subdomain"-scenario outlined by Levi, consider an attacker that has an account on the targeted site. If the CSRF-token does not encode user-specific information, the server can not verify that the token has been generated exclusively for the logged-in user. The attacker could then use one of his own legitimately acquired CSRF-tokens when building a forged request.
That being said, anonymous tokens are during certain circumstances accepted by ASP.NET MVC. See Why does ValidateAntiForgeryTokenAttribute allow anonymous tokens?