_ _ VIEWSTATE su Protect Against CSRF

4

Non sono uno sviluppatore .NET e sto cercando di capire esattamente come __ViewState protegge dagli attacchi CSRF / XSRF.

Mi sono imbattuto in quanto segue:

sicurezza Discussione dello scambio di stack su argomenti simili e Guida OWASP alla protezione CSRF

Sono un po 'confuso da quanto esattamente la protezione CSRF sta accadendo qui. Se osserviamo il codice riportato di seguito tratto dal collegamento OWASP sopra menzionato:

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

Da quello che posso capire, il codice sopra controlla se c'è un cookie chiamato '__AntiXsrfToken', già presente.

In caso contrario, viene generato un nuovo valore casuale, assegnato a ViewStateUserKey e impostato anche come valore per il cookie, '__AntiXsrfToken'.

Se il cookie è già presente, il valore del cookie viene semplicemente preso e assegnato a ViewStateUserKey.

Ora quello che non capisco è che l'intero punto su un token antiXSRF è che non dovrebbe essere ipotizzabile e certamente non verrà passato nei cookies, perché i cookie saranno sempre inviati con ogni richiesta dal browser. Nel caso precedente, poiché il token AntiXsrf viene utilizzato come cookie, come lo protegge da esso? E quale è veramente l'uso di ViewStateUserKey e in che modo ha un ruolo nella protezione contro XSRF qui?

    
posta qre0ct 18.11.2014 - 07:48
fonte

2 risposte

8

Il problema è che l'esempio di codice nella guida OWASP non è completo. In particolare, manca l'implementazione del metodo master_Page_PreLoad che viene collegato nell'ultima riga del metodo Page_Init .

Cosa vedresti, se questo metodo fosse incluso (e potrei andare ad aggiungerlo qui) è che il valore di ViewStateUserKey impostato dal cookie viene confrontato con il valore di ViewState [AntiXsrfTokenKey] che viene inviato con il modulo Campo ViewState.

Questo è ciò che fornisce la protezione CSRF. Hai assolutamente ragione che quando la richiesta dannosa viene inviata, verrà inviata con il tuo cookie, che avrà il tuo token anti-contraffazione, e questo sarà impostato sul valore ViewStateUserKey. Tuttavia, ciò che non vedi, è che viene confrontato con il valore del modulo inviato. In uno scenario di falsificazione della richiesta tra siti, tale valore form sarà il token anti-contraffazione del pirata informatico ; quello che è stato aggiunto come viewstate per essere il suo ViewStateUserKey, e che non corrisponderà alla corrispondenza del valore presente nel tuo cookie. Pertanto, la convalida fallirà e la richiesta non avrà esito positivo.

Dato solo il codice sulla pagina OWASP al momento, hai ragione a essere confuso.

    
risposta data 18.11.2014 - 22:57
fonte
0

Tieni presente però che, mentre i cookie e le sessioni sono accessibili da tutte le pagine del tuo sito web, i valori di ViewState non vengono trasferiti tra le pagine, contengono valori tra i postback:

Se il tuo sito Web autentica gli utenti, puoi impostare la proprietà ViewStateUserKey nel gestore eventi Page_Init per associare lo stato di visualizzazione della pagina a un utente specifico. Questo aiuta a prevenire attacchi con un clic, in cui un utente malintenzionato crea una pagina Web pre-riempita con stato di visualizzazione da una pagina creata in precedenza. L'aggressore attira quindi una vittima nel fare clic su un collegamento che invia la pagina al server utilizzando l'identità della vittima.

Quando la proprietà ViewStateUserKey è impostata, l'identità dell'attaccante viene utilizzata per creare l'hash dello stato di visualizzazione della pagina originale. Quando la vittima viene indotta a reinviare la pagina, i valori dell'hash saranno diversi perché le chiavi dell'utente sono diverse. La pagina fallirà la verifica e verrà generata un'eccezione.

È necessario che la proprietà ViewStateUserKey sia un valore univoco per ciascun utente, ad esempio il nome utente o l'identificatore.

Nel tuo codice:

// Genera un nuovo token Anti-XSRF e salva nel cookie

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

genererà un nuovo token Anti-XSRF ogni volta che la pagina viene caricata. quindi l'attaccante non può indovinare il valore. E ogni volta che il valore del cookie cambia. Quindi è molto difficile da hackerare.

    
risposta data 18.11.2014 - 10:23
fonte

Leggi altre domande sui tag