_ _ VIEWSTATE to Protect Against CSRF

Question

I am not a .NET developer and I am trying to understand how exactly does __ViewState protect against CSRF/XSRF attacks.

I came across the following :

security Stack exchange discussion on similar topic and OWASP Guide to CSRF Protection

I am a little confused with how exactly is the CSRF protection happening here. If we look at the below code taken from the OWASP link mentioned above:

    private const string AntiXsrfTokenKey = "__AntiXsrfToken";
    private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
    private string _antiXsrfTokenValue;
    protected void Page_Init(object sender, EventArgs e)
{
    // The code below helps to protect against XSRF attacks
    var requestCookie = Request.Cookies[AntiXsrfTokenKey];
    Guid requestCookieGuidValue;
    if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
    {
       // Use the Anti-XSRF token from the cookie
       _antiXsrfTokenValue = requestCookie.Value;
       Page.ViewStateUserKey = _antiXsrfTokenValue;
    }
    else
    {
       // Generate a new Anti-XSRF token and save to the cookie
       _antiXsrfTokenValue = Guid.NewGuid().ToString("N");
       Page.ViewStateUserKey = _antiXsrfTokenValue;
       var responseCookie = new HttpCookie(AntiXsrfTokenKey)
       {
          HttpOnly = true,
          Value = _antiXsrfTokenValue
       };
       if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)
       {
          responseCookie.Secure = true;
       }
       Response.Cookies.Set(responseCookie);
    }
    Page.PreLoad += master_Page_PreLoad;
}

From what I can understand, the above code checks to see if there is a cookie named, '__AntiXsrfToken', already present.

If not, then a new random value is generated, which is assigned to ViewStateUserKey and also set as the value for the cookie, '__AntiXsrfToken'.

If the cookie is already present, the value of the cookie is simply taken and is assigned to ViewStateUserKey.

Now what I do not understand is that the whole point about an antiXSRF token is that it should not be guessable and certainly not be passed in cookies, because cookies will always be sent with every request by the browser. In the above case, since the AntiXsrf token is being used in as cookies, how does it protect against it? And what really is the use of ViewStateUserKey and how does it play a role in the protection against XSRF here?

Answer 1

The issue is that the code sample in the OWASP guide is not complete. Specifically, it is missing the implementation of the master_Page_PreLoad method that it wires up in the last line of the Page_Init method.

What you would see, if that method were included (and I may go add it shortly here) is that the ViewStateUserKey value being set by the cookie is being compared to the ViewState[AntiXsrfTokenKey] value that is being submitted with the form's ViewState field.

This is what provides the CSRF protection. You are absolutely correct that when the malicious request is submitted, it will be submitted with your cookie, which will have your anti-forgery token, and this will be set to the ViewStateUserKey value. However, what you're not seeing, is that this is being compared to the form value that was submitted. In a cross-site request forgery scenario, that form value is going to be the attacker's anti-forgery token; the one that was added as the viewstate to be his ViewStateUserKey, and that's not going to match the match the value that's in your cookie. So, validation will fail, and the request will not be successful.

Given nothing but the code on the OWASP page currently, you're right to be confused.

Answer 2

Please keep in mind though, that while cookies and sessions can be accessed from all your pages on your website, ViewState values are not carried between pages, they carry values between postbacks:

If your Web site authenticates users, you can set the ViewStateUserKey property in the Page_Init event handler to associate the page's view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid, pre-filled Web page with view state from a previously created page. The attacker then lures a victim into clicking a link that sends the page to the server using the victim's identity.

When the ViewStateUserKey property is set, the attacker's identity is used to create the hash of the view state of the original page. When the victim is lured into resending the page, the hash values will be different because the user keys are different. The page will fail verification and an exception will be thrown.

You must the ViewStateUserKey property to a unique value for each user, such as the user name or identifier.

In your code :

// Generate a new Anti-XSRF token and save to the cookie

_antiXsrfTokenValue = Guid.NewGuid().ToString("N");
   Page.ViewStateUserKey = _antiXsrfTokenValue;
   var responseCookie = new HttpCookie(AntiXsrfTokenKey)
   {
      HttpOnly = true,
      Value = _antiXsrfTokenValue
   };

it will generate a new Anti-XSRF token each time the page loads . so the attacker can't guess the value.And each time the cookie value is changes. So it is very difficult to hack.