Garantire che una stringa casuale in un cookie e un'intestazione siano la stessa cosa da proteggere contro XSRF?

3

In uno schema cookie-to-header di invio dei token xsrf / csrf , il server imposta un numero pseudo-casuale crittograficamente sicuro come cookie nella macchina del client. Il codice di script java sul computer client è tenuto a leggere questo codice dal cookie, garantendo così di fronte alla stessa politica di origine del browser che lo script proviene dalla stessa pagina del token. Lo script prende quindi il token e lo aggiunge all'intestazione della richiesta http con il nome xsrf-token o qualcosa del genere.

Nel frattempo il server dovrebbe mantenere una registrazione persistente del token xsrf emesso. Quando arriva la richiesta, prende il token dall'intestazione, lo confronta con quello registrato, se è abbinabile, ci siamo!

Ora è qui che inizia la mia confusione. Dato che stiamo memorizzando le informazioni nel cookie, verrà inevitabilmente inviato con ogni richiesta al server quando viene effettuata la richiesta http. Quindi, sul lato server non abbiamo solo una ma due copie delle stesse informazioni. Perché non possiamo semplicemente abbinarci l'uno con l'altro e accettare la validità della richiesta? Questo esercizio non vale la pena solo perché crediamo che il browser esegua i controlli incrociati di origine. Non ci fidiamo dei cookie? Per il mio ingenuo, almeno questo sembra qualcosa che potrebbe funzionare. Ovviamente potrei essere egregiamente in errore, e mi affiderei a te per chiamarmi nel caso in cui mi manchi un po 'di base.

Sto presumendo che mi manchi qualcosa. Quindi, ecco lo schema che sto attualmente implementando per il mio sito. Utilizzo i token JWT per stabilire e proteggere l'identità dell'utente in un cookie httponly. Quello che sto proponendo è che io emetto un token JWT separato (contenente solo un numero pseudo casuale) firmato da una chiave completamente diversa e memorizzato in un cookie di sessione. Il codice lato client lo legge, lo invia nell'intestazione. Il server legge il cookie e il campo di intestazione e vede che sono gli stessi. Quindi il server autentica il token JWT e vede che è stato effettivamente firmato dalla chiave nel server.

La mia domanda è, può funzionare? Con questo non intendo solo quello che riguarda i token JWT. Intendo anche quello senza alcun tipo di controllo per verificare che il server fosse l'emittente, cioè quello con solo un numero pseudo-casuale e solo un singolo assegno da abbinare al cookie. Ogni suggerimento costruttivo è benvenuto, incluso informarmi su come io sia un vero e proprio idiota. Quali sono alcune vulnerabilità presenti in questo schema? C'è la possibilità di indagare ulteriormente su questo? Si tratta di uno schema sufficientemente buono da proteggere contro CSRF?

    
posta Debabrata Roy 29.10.2017 - 02:52
fonte

1 risposta

1

Sì, il sistema che descrivi, confrontando semplicemente un valore di cookie con un valore di intestazione, è una difesa CSRF pienamente funzionale. In effetti, ha persino un nome: doppio invio cookie . È un ottimo modo per fare anti-CSRF quando non si vuole mantenere lo stato del server. Nota che non hai bisogno di una JWT per questo. Qualsiasi numero casuale crittograficamente sicuro andrà bene.

Quindi perché non farlo sempre? Perché perdere tempo con il salvataggio di un token casuale in una sessione, quando puoi semplicemente fare in modo che il client risolva tutto il problema? Forse il doppio invio dei cookie è un po 'più incline agli errori di implementazione (ad es. Cosa succede se entrambi sono vuoti, problemi di digitazione, ecc.). Ma penso che il principale motivo sia che il token ordinario è più semplice da capire. Il server mantiene un segreto che l'attaccante non sa. Il funzionamento del doppio invio è concettualmente più difficile da capire.

    
risposta data 29.10.2017 - 10:08
fonte

Leggi altre domande sui tag