问题描述
在ASP.NET MVC中，称为由ValidateAntiForgeryTokenAttribute验证逻辑允许匿名防伪标记，即令牌无需任何用户特定的信息，如IIdentity.Name或ClaimUid
In ASP.NET MVC, the validation logic called by ValidateAntiForgeryTokenAttribute allows anonymous anti-forgery tokens, i.e. tokens without any user-specific information such as IIdentity.Name or ClaimUid.
所以，如果权利要求书没有使用和HttpContext.User中登录（并不少见）后没有被设置，该系统的恶意用户可以阶段性针对任何其他用户跨站请求伪造攻击，使用恶意用户自己的合法取得抗伪造令牌。
So, if claims are not used and HttpContext.User is not set after login (not uncommon), a malicious user of the system can stage a CSRF-attack against any other user, using the malicious user's own legitimately acquired anti-forgery tokens.
这似乎并不理想。为什么匿名令牌允许吗？
This doesn't seem desirable. Why are anonymous tokens allowed?
推荐答案
防CSRF系统MVC允许匿名用户，因为它需要保护的登录页面，然后根据定义你匿名之前你已经登录。尤其是攻击它试图防范的是登录CSRF 。
The anti-CSRF system in MVC allows anonymous users because it needs to protect the login page, and by definition you're anonymous before you've logged in. In particular, the attack it's trying to defend against is Login CSRF.
由于抗CSRF令牌拆分跨既一个HTTP cookie和一个隐藏的＆其中;输入＆GT;元素，攻击者是否能够拉断登录CSRF取决于在那里他坐。当然 - 你也许能说服我的浏览器提交＆LT;形式GT;含有的您的道理，但我的浏览器会提交的我的cookie发送到服务器，连同请求。 Cookie，并形成令牌连接code不仅仅是字符串匿名：它们还包含一个随机标识符链接两者结合起来。在这种情况下，你仍然不会能够拉断登录CSRF攻击反对我，因为你不知道的随机标识符包含我的cookie中。
Since the anti-CSRF token is split across both an HTTP cookie and a hidden <input> element, whether an attacker will be able to pull off login CSRF depends on where he's sitting. Sure - you might be able to convince my browser to submit a <form> containing your token, but my browser will submit my cookie to the server along with the request. The cookie and form token encode more than just the string "anonymous": they also contain a random identifier that links the two together. In this scenario, you still wouldn't be able to pull off a login CSRF attack against me since you don't know the random identifier contained within my cookie.
如果攻击者共享与目标网站（例如，attacker.shareddomain.com和bank.shareddomain.com）域，那么攻击者可以设置一个cookie为* .shareddomain.com并覆盖受害者的cookie有一个他自己选择的。这将允许CSRF攻击发生。你需要另一种机制（如2FA或HTML5本地存储）在一个共享的子域的情况prevent CSRF攻击。
If the attacker shares a domain with the target web site (e.g., attacker.shareddomain.com and bank.shareddomain.com), then the attacker can set a cookie for *.shareddomain.com and overwrite the victim's cookie with one of his own choosing. This would allow a CSRF attack to take place. You'd need another mechanism (like 2FA or HTML5 local storage) to prevent CSRF attacks in a shared subdomain scenario.
这篇关于为什么ValidateAntiForgeryTokenAttribute允许匿名令牌？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！