为什么ValidateAntiForgeryTokenAttribute允许匿名令牌？

Question

在ASP.NET MVC中，ValidateAntiForgeryTokenAttribute调用的验证逻辑允许使用匿名防伪标记，即没有任何用户特定信息（如IIdentity.Name或ClaimUid）的标记。

因此，如果未使用声明且登录后未设置HttpContext.User（非常见），则系统的恶意用户可以使用恶意用户自己的合法获取的反攻击对任何其他用户发起CSRF攻击伪造令牌。

这似乎不太可取。为什么允许使用匿名令牌？

Answer 1

MVC中的反CSRF系统允许匿名用户，因为需要保护登录页面，根据定义，您在登录前是匿名的。特别是，它正在尝试攻击防御是Login CSRF。

由于反CSRF令牌分散在HTTP cookie和隐藏的＆lt; input＆gt;上。元素，攻击者是否能够启动登录CSRF取决于他所处的位置。当然 - 您可以说服我的浏览器提交＆lt; form＆gt;包含您的令牌，但我的浏览器会将我的 Cookie连同请求一起提交给服务器。 cookie和表单令牌不仅仅编码字符串“anonymous”：它们还包含将两者链接在一起的随机标识符。在这种情况下，由于您不知道我的cookie中包含的随机标识符，您仍然无法对我进行登录CSRF攻击。

如果攻击者与目标网站共享域名（例如，attacker.shareddomain.com和bank.shareddomain.com），则攻击者可以为* .shareddomain.com设置cookie并用一个覆盖受害者的cookie他自己选择的。这将允许进行CSRF攻击。您需要其他机制（如2FA或HTML5本地存储）来防止共享子域方案中的CSRF攻击。

Answer 2

它不允许匿名令牌！

由于某些原因（我不了解自己！），令牌都写在HTTP标头和cookie中。但是，只会检查用COOKIE编写的令牌。换句话说：

1）如果您阻止发送Cookie并且您的ActionMethod具有[ValidateAntiForgeryToken()]属性，则会出现以下异常：

The required anti-forgery form field __requestverificationtoken is not present。

2）你可以改变Http Header中写的令牌......！ - 什么都不会发生错误......！

AntiForgeryToken 的主要目的：

它是一种确保接收到服务器的表单数据的解决方案，是通过服务器创建并发送给客户端的表单提交的（不是来自伪造的表单！）。

因此，如果两个合法用户更改其Cookie并提交表单，服务器将接受两者！因为服务器创建并发送了两个表单！（实际上，两个令牌......！）

详细了解AntiForgeryToken here

Answer 3

AntiForgery令牌用于防止CSRF（跨站点请求），它们不用于确保返回的数据来自授权用户，即Identity和{{ 1}}库用于（身份验证和授权）。

FormsAuthentication令牌使用一些已知的信息来生成POST响应中包含的随机文本字符串。该信息的一部分是用户名。可以使用POSTed表单而无需要求身份验证（匿名站点搜索，匿名调查等）。这就是为什么必须允许AntiForgery令牌与用户名匿名一起使用。

鉴于AntiForgery令牌的作用是仅防止CSRF攻击（从完全不同的网站向您的服务器发布），那么AntiForgery令牌中匿名用户名的使用不应该是在意。当有人回发到您的服务器并且他们必须登录才能执行该操作时，您应该使用AntiForgery属性来捕获它。该属性以及AntiForgery令牌将确保a）授权用户提出此请求，b）他们是从您的网站而不是从您网站外部这样做的。

Answer 4

AntiForgery令牌包含username，而anonymous用户username将为空。在用户登录和下次使用生成的令牌之后，令牌验证将失败，因为初始令牌中包含的空用户名与当前经过身份验证的用户名不同。了解更多信息read this。