ASP.NET MVC uses a variation of synchronizer token pattern. In a typical implementation, syncrhonizer token pattern works by generating a large random token and preserving it in two locations:
- Session state (either on server or client)
- In a hidden form field
When a form is submitted, server will check that both values match and fail if they don't. This works because an attacker can't get the token value in advance.
ASP.NET MVC slightly modifies this pattern by not using session state, instead using session cookie. Token also contains some additional data depending on whether it is a cookie token or form field token:
/* The serialized format of the anti-XSRF token is as follows:
* Version: 1 byte integer
* SecurityToken: 16 byte binary blob
* IsCookieToken: 1 byte Boolean
* [if IsCookieToken != true]
* +- IsClaimsBased: 1 byte Boolean
* | [if IsClaimsBased = true]
* | `- ClaimUid: 32 byte binary blob
* | [if IsClaimsBased = false]
* | `- Username: UTF-8 string with 7-bit integer length prefix
* `- AdditionalData: UTF-8 string with 7-bit integer length prefix
Both tokens are encrypted and authenticated and thus not readable on the client side. See the implementation of serializer here. Given the anatomy of the token above you can see that they are not even identical on the client side, both will encrypt to two different ciphertexts and can't be validated there.
You can probably change the behavior in a way that cookie is not needed by storing CSRF token server side in session state. But you really need two of them and you really need to compare them to make CSRF protection work.
To answer more directly to your original question
What is the purpose of the default header/cookie in an MVC
To give a complete solution that will work all the time and for any application.
It even has an ability to protect login pages:
The anti-XSRF system contains special support for anonymous users,
where "anonymous" is defined as a user where the
IIdentity.IsAuthenticated property returns false. Scenarios include
providing XSRF protection to the login page (before the user is
authenticated) and custom authentication schemes where the application
uses a mechanism other than IIdentity to identify users. To support
these scenarios, recall that the session and field tokens are joined
by a security token, which is a 128-bit randomly-generated opaque
identifier. This security token is used to track an individual user's
session as she navigates the site, so it effectively serves the
purpose of an anonymous identifier. An empty string is used in place
of the username for the generation and validation routines described
As per your comments, you are wondering whether you can do it without cookie by including encrypted username and expiration date into a hidden form field. The answer would be it depends.
Such token could be stolen with an XSS attack whereas an authentication cookie (or CSRF token cookie) marked with httpOnly couldn't. This would make your solution vulnerable in the time frame of your expiration. Whether this is acceptable or not depends on you and the type of the application. For example, a net banking application wouldn't tolerate any kind of CSRF vulnerability but a simple online game could.