Due soluzioni per CSRF su OWASP per Web Form di ASP.NET

3

Sono confuso dalle differenze tra queste due soluzioni di OWASP Guida di ASP.NET Web

Soluzione 1:

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

Soluzione 2:

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.");
       }
    }
}

Ciò che non ho ottenuto è questo commento sul primo approccio: "Per proteggere ViewState dagli attacchi CSRF è necessario impostare ViewStateUserKey." Guardando il codice per la seconda soluzione, usando chiaramente ViewSate nel codice, presumo che l'autore significhi "usare ViewState per mantenere lo stato di controllo". Quindi se EnableViewState è impostato su false per la pagina o la pagina principale, il primo approccio non funzionerà affatto?

Aggiornamento: Un commento migliore sul secondo approccio 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.

    
posta Paul L 14.06.2018 - 04:24
fonte

1 risposta

1

Sembra che ho bisogno di rispondere di nuovo alla mia stessa domanda.

La parte difficile per me, almeno, è costruire un attacco CSRF di successo / operativo, quindi è semplice implementare entrambi gli approcci e vederli funzionare e mitigare l'attacco CSRF.

Il primo approccio, che utilizza solo ViewStateUserKey , non sembra influenzato dalla disattivazione di enableViewState , a livello di pagina o a livello di app Web. Come hidden viewState è ancora nell'Html renderizzato, e il processo di codifica ViewState è ancora sul posto, quindi non puoi disattivare ViewStateUserKey disattivando semplicemente ViewState.

D'altra parte, poiché il secondo approccio utilizza ViewState per il sorage di AntiXsrfTokenKey , smetterà di funzionare se ViewState è disabilitato. Quindi i commenti di quella pagina OWASP sono sbagliati, o almeno mancano, l'altro commento di OWASP è molto migliore e più chiaro.

    
risposta data 18.06.2018 - 02:39
fonte

Leggi altre domande sui tag