4

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?

  • They can't be read if you set the HTTPOnly flag. – Lucas Kauffman Nov 18 '14 at 9:41
  • That's true as long as a script is trying to access it. But if there is a form getting submitted by the victim, the cookie does not really even need to be accessed. Because it will be automatically sent by the browser thus successfully submitting the form, right ? – qre0ct Nov 18 '14 at 10:33
8

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.

  • +1, additionally, this is a double-submit cookie based CSRF token. – rook Nov 19 '14 at 2:22
  • great explanation. Thanks. And I think it would be fruitful to have this clarification added onto the OWASP page as well. – qre0ct Nov 19 '14 at 5:36
  • 1
    @geek_ji I've updated the OWASP cheatsheet. – Xander Nov 19 '14 at 20:20
0

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.

  • ok i understand that, but, the point is that the newly generated Anti-XSRF token, even though it is unique to the user and the page, it is still getting assigned to a cookie. So it does not really matter if it is unique, right?. Because, the attacker doesn't really need to know this token. He simply needs to send the pre-filled form to the victim. And as the form gets submitted from the victim's browser, the token in the cookie also gets sent to the server, thus leading to the successful submission of the form. Right ? – qre0ct Nov 18 '14 at 10:30
  • @geek_ji yes you are right. but there is some another point related with ViewStateUserKey Declaration. U just think in a programming point of view then simply u can understand the concept . just go through msdn.microsoft.com/en-us/library/ms972976.aspx this article .. "The ViewStateUserKey Property" portion tells how it works.just check it, i hope u got the idea after reading that – Arunprasanth KV Nov 18 '14 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.