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.
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?
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.
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.
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.
It doesn't allow anonymous tokens!
For some reasons (Which I don't know myself!) the token is written in both HTTP Header and the cookie. However, only that token written in COOKIE will be checked. In other words:
1) if you prevent cookies from being sent and your ActionMethod has the [ValidateAntiForgeryToken()] attribute, you'll get the following exception:
The required anti-forgery form field __requestverificationtoken is not present.
2) You can change the token written in the Http Header...! - Nothing wrong will happen...!
The main purpose of the AntiForgeryToken:
It's a solution for ensuring that the form data received to the server, is submitted through the form which is created and sent to the client by the server(Not from a forged form!).
So, If two legal users change their cookies and submit the form, the server will ACCEPT both of them! Because the server created and sent both of that forms!(And indeed, both of tokens...!)
Read more about AntiForgeryToken here
AntiForgery tokens are used to prevent CSRF (cross-site requests), they are not used to ensure that the data coming back is from an authorized user, that is what the Identity and FormsAuthentication libraries are for (authentication and authorization).
The AntiForgery token uses some known pieces of information to generate a random string of text that is included with the POST response. One piece of this information is the user name. It is possible to have a POSTed form without needing to require authentication (anonymous site searching, anonymous survey, etc). This is why the AntiForgery token has to be allowed to be used with the username anonymous.
Given that the role of the AntiForgery token is to only prevent CSRF attacks (POSTing to your server from a completely different website), then the use of anonymous usernames in the AntiForgery token should not be a concern. When someone posts back to your server and they have to be logged in to perform that action, you should be catching that with the [Authorize] attribute. That attribute, along with the AntiForgery token will ensure that a) an authorized user has made this request and b) they did so from your website and not from outside of your website.
AntiForgery token contains the username and for anonymous user username will be empty. after user logon and next use of generated token, token validation will be failed because the empty username contained in the initial token is different than the currently authenticated username. for more info read this.
来源：https://stackoverflow.com/questions/26336435/why-does-validateantiforgerytokenattribute-allow-anonymous-tokens