ASP.NET MVC3的AntiForgeryToken有哪些实现细节和基本原理？

Question

AntiForgeryToken用于防止CSRF攻击,但是MSDN上的链接并没有让我深入了解AntiForgeryToken究竟做了什么,或者它是如何工作的,或者为什么事情按照它们的方式完成.

从我收集的内容中,它在网页和cookie中创建了一个哈希.其中一个或两个使用散列IPrincipal.Name,并使用对称加密.

任何人都可以阐明:

1. AntiForgeryToken如何在内部工作
2. 应该用什么来保护
3. 什么不应该用来保护
4. 上面#1的实施选择背后的原因是什么？
   • 例:
     • 是"DoubleSubmit"cookie和其他常见漏洞的安全实现
     • 如果用户打开多个选项卡,是否存在实施问题
     • 是什么让MSFT的实现与SANS提供的实现不同

Answer 1

好吧，这是我最好的镜头。

1) 在内部，mvc 使用 RNG 加密方法创建 128 位字符串作为 XSRF 令牌。该字符串存储在 cookie 中以及表单上某处的隐藏字段中。cookie 名称的形式似乎是 __RequestVerificationToken + 应用程序路径（服务器端）的 Base 64 编码版本。其中的 html 部分使用 AntiForgeryDataSerializer 序列化以下数据片段 - salt - 值（令牌字符串） - 创建日期的刻度 - 用户名（看起来像 Context.User）

验证方法基本上将 cookie 和表单中的值反序列化，并根据值（salt/value/ticks/username）对它们进行比较。

2/3) 我认为这个讨论更多的是关于何时使用 XSRF 令牌以及何时不使用。在我看来，你应该在每种表单上使用它（我的意思是为什么不呢）。我能想到的唯一不能保护的是您是否确实点击了相关表格。了解应用程序名称的 base64 编码将使攻击者能够在 XSRF 攻击期间查看 cookie。也许我的解释是不正确的。

4) 不确定您到底要在这里寻找什么？我想我会构建一种机制，尝试将 XSRF 令牌存储在会话中（如果已经可用），如果没有，则尝试 cookie 方法。至于使用的加密类型，我找到了这篇文章。 RNGCryptoServiceProvider 的优缺点