8

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

当然，我可能遗漏了一个主要问题，但我还没有找到它。如果这里有一些明显或微妙的问题，那么我想知道它们。

4

2 回答 2

6

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

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

于 2010-04-23T16:46:12.460 回答
2

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

话虽如此，匿名令牌在某些情况下被 ASP.NET MVC 接受。请参阅为什么 ValidateAntiForgeryTokenAttribute 允许匿名令牌？

于 2015-03-12T07:30:46.277 回答