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

Question

我们最近更新了我们的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攻击。

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

Answer 1

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

展望未来，cookie可能会被删除，因为它对于系统的正常运行并不是绝对必要的。 （例如，如果您正在使用表单身份验证，那么 cookie可以作为反XSRF cookie，而不是要求系统生成第二个cookie。）cookie可能只在案例中发出例如，匿名用户。

Answer 2

除了Levi概述的“邪恶子域名” - 场景之外，请考虑在目标站点上拥有帐户的攻击者。如果CSRF令牌不编码特定于用户的信息，则服务器无法验证是否已为登录用户专门生成令牌。然后，攻击者可以在构建伪造请求时使用他自己合法获得的CSRF令牌之一。

话虽这么说，匿名令牌在ASP.NET MVC接受的某些情况下。见Why does ValidateAntiForgeryTokenAttribute allow anonymous tokens?