我们最近将解决方案更新为 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 攻击。
当然，我可能会遗漏一个重大问题，但我还没有找到它。如果这里存在一些明显或微妙的问题，那么我想了解它们。
添加它是为了在一个子域试图攻击另一个子域的情况下提供更好的保护 - bad.example.com 试图攻击 good.example.com。添加用户名会使 bad.example.com 更难以在幕后联系 good.example.com 并尝试让它代表您生成令牌。
展望未来，cookie 可能会被删除，因为它对于系统的正常运行并不是绝对必要的。 （例如，如果您使用表单身份验证，that例如，cookie 可能仅在匿名用户的情况下发出。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
