3

I am confused about differences between those two solutions from OWASP ASP.NET Web Froms Guidance

Solution one:

While viewstate isn't always appropriate for web development, using it can provide CSRF mitigation. To make the ViewState protect against CSRF attacks you need to set the ViewStateUserKey:

protected override OnInit(EventArgs e) {
    base.OnInit(e); 
    ViewStateUserKey = Session.SessionID;
} 

Solution two:

If you don't use Viewstate, then look to the default master page of the ASP.NET Web Forms default template for a manual anti-CSRF token using a double-submit cookie.

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;
}

protected void master_Page_PreLoad(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
       // Set Anti-XSRF token
       ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey;
       ViewState[AntiXsrfUserNameKey] = Context.User.Identity.Name ?? String.Empty;
    }
    else
    {
       // Validate the Anti-XSRF token
       if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue || 
          (string)ViewState[AntiXsrfUserNameKey] != (Context.User.Identity.Name ?? String.Empty))
       {
          throw new InvalidOperationException("Validation of Anti-XSRF token failed.");
       }
    }
}

What I didn't get is this comment about the first approach: "To make the ViewState protect against CSRF attacks you need to set the ViewStateUserKey." Looking at the code for the second solution, it clearly using ViewSate in the code, I assume the author means that "using ViewState to persist control state". So if EnableViewState is set to false in for the page or master page, the first approach will not work at all?

Update: A better comment about the second approach in OWASP Anti CSRF Tokens ASP.NET

Since Visual Studio 2012, the anti-CSRF mechanism has been improved.

The new strategy still uses the ViewState as the main entity for CSRF protection but also makes use of tokens (which you can generate as GUIDs) so that you can set the ViewStateUserKey to the token rather than the Session ID, and then validate it against the cookie.

1

The tricky part for me, at least, is to construct a successful/working example CSRF attack, then it is trivial to implement both approaches and see them in working and actually mitigate the CSRF attack.

The first approach, using ViewStateUserKey only, seems not been affected by turn off enableViewState, either in page level or in web app level. As hidden ViewState is still in the rendered HTML, and the process of encoding ViewState is still in place so that you can not turn off ViewStateUserKey by simply turn off ViewState.

On the other hand, as the second approach is using ViewState for the storage of AntiXsrfTokenKey, it will stop working if the ViewState is disabled. So the comments from that OWASP page are wrong, or at least, misleading, the other comment from OWASP other page is much better and clearer.

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.