我们最近更新了 MVC 2 的解决方案，这更新了 AntiForgeryToken 的方式。作品。不幸的是，这不再适合我们的 AJAX 框架。
问题是 MVC 2 现在使用对称加密来编码关于用户的一些属性，包括用户的 Name属性(property)(来自 IPrincipal)。我们能够使用 AJAX 安全地注册新用户，之后后续的 AJAX 调用将无效，因为当用户被授予新的委托(delegate)人时，防伪 token 将发生变化。还有其他情况可能会发生这种情况，例如用户更新其姓名等。
我的主要问题是为什么 MVC 2 甚至会费心使用对称加密？那么它为什么要关心主体上的用户名属性呢？
如果我的理解是正确的，那么任何随机共享的 secret 都可以。基本原则是用户将收到一个带有一些特定数据的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 并尝试让它代表您生成 token 。
展望 future ，cookie 可能会被删除，因为它对于系统的正常运行并不是绝对必要的。 (例如，如果您使用表单例份验证，则该 cookie 可以用作反 XSRF cookie，而不是要求系统生成第二个 cookie。)例如，该 cookie 可能仅在匿名用户的情况下发布。
关于asp.net - MVC 2 AntiForgeryToken - 为什么是对称加密 + IPrinciple？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2697772/