Protezione CSRF con intestazione CORS Origin e token CSRF

103

Questa domanda riguarda solo la protezione dagli attacchi Cross Site Request Forgery.

Si tratta in particolare di: La protezione tramite l'intestazione Origin (CORS) è buona quanto la protezione tramite un token CSRF?

Esempio:

Alice ha effettuato l'accesso (utilizzando un cookie) con il suo browser a " https://example.com ". Presumo che utilizzi un browser moderno.
Alice visita " https://evil.com " e il codice lato client di evil.com esegue una sorta di richiesta a " https://example.com " (scenario CSRF classico).

Così:

Se non controlliamo l'intestazione Origin (lato server) e nessun token CSRF, abbiamo un buco di sicurezza CSRF.
Se controlliamo un token CSRF, siamo al sicuro (ma è un po 'noioso).
Se controlliamo l'intestazione Origin, la richiesta dal codice lato client di evil.com dovrebbe essere bloccata proprio come farebbe quando si utilizza un token CSRF, tranne se è possibile in qualche modo per il codice di evil.com impostare l'intestazione Origin.

So che questo non dovrebbe essere possibile con XHR (vedi ad es.Sicurezza per la condivisione di risorse cross-origin ), almeno no, se ci fidiamo che le specifiche W3C siano implementate correttamente in tutti i browser moderni (possiamo?)

Ma per quanto riguarda altri tipi di richieste, ad esempio l'invio di un modulo? Caricamento di uno script / img / ... tag? O in qualsiasi altro modo una pagina può utilizzare per creare (legalmente) una richiesta? O forse qualche noto hack JS?

Nota: non sto parlando di

applicazioni native,
browser manipolati,
bug di cross site scripting nella pagina example.com,
...

— Chris Lercher
fonte

Credo che molti proxy rimuovano l'intestazione di origine.

— thefourtheye

E per i tag di invio del modulo e img / script, dovremmo fare affidamento sui CSP, sebbene non siano sicuri dei vecchi browser.

— thefourtheye

@thefourtheye: poiché la connessione viene avviata tramite TLS, l'utente ha un problema molto più urgente rispetto a CSRF se un proxy può man-in-the-middle lui / lei.

— Perseidi

@thefourtheye, perché dovrebbero spogliarsi Origin? Ciò negherebbe la protezione CORS.

— Paul Draper

Mi piace questa domanda e le sue risposte perché riguardano qualcosa di specifico, ma mi ricordano anche la differenza tra CSRF e CORS. (Ammetto che questi non sono concetti facilmente confondibili ... Ma riesco comunque a confonderli.)

— The Red Pea

Risposte:

sappi che questo non dovrebbe essere possibile con XHR (vedi ad es.Sicurezza per la condivisione di risorse cross-origin), almeno no, se crediamo che le specifiche W3C siano implementate correttamente in tutti i browser moderni (possiamo?)

Alla fine della giornata devi "fidarti" del browser del client per memorizzare in modo sicuro i dati dell'utente e proteggere il lato client della sessione. Se non ti fidi del browser client, dovresti smettere di usare il Web per qualsiasi cosa diversa dal contenuto statico. Anche con l'utilizzo di token CSRF, ci si affida al browser client per obbedire correttamente alla politica della stessa origine .

Sebbene ci siano state precedenti vulnerabilità del browser come quelle in IE 5.5 / 6.0 in cui è stato possibile per gli aggressori aggirare la politica della stessa origine ed eseguire attacchi, in genere ci si può aspettare che vengano corrette non appena scoperte e con la maggior parte dei browser che si aggiorna automaticamente , questo rischio sarà per lo più mitigato.

Ma per quanto riguarda altri tipi di richieste, ad esempio l'invio di un modulo? Caricamento di uno script / img / ... tag? O in qualsiasi altro modo una pagina può utilizzare per creare (legalmente) una richiesta? O forse qualche noto hack JS?

L' Originintestazione viene normalmente inviata solo per le richieste cross-domain XHR. Le richieste di immagini non contengono l'intestazione.

Nota: non sto parlando di

applicazioni native,

browser manipolati,

bug di cross site scripting nella pagina example.com,

Non sono sicuro che ciò rientri o meno nei browser manipolati, ma le vecchie versioni di Flash consentivano l'impostazione di intestazioni arbitrarie che avrebbero consentito a un utente malintenzionato di inviare una richiesta con refererun'intestazione falsificata dalla macchina della vittima per eseguire un attacco.

— SilverlightFox
fonte

L'esempio di Flash è buono e forse altri plugin potrebbero avere una vulnerabilità simile. Posso (sfortunatamente) proteggere Alice solo da CSRF, se usa un browser moderno, ecc., È chiaro. Ma non è irragionevole che, anche come utente attento alla sicurezza, possa aver installato plug-in di terze parti, specialmente quando provengono da grandi aziende (affidabili). Anche se possono scrivere plugin sicuri, non sono convinto al 100%, se pensano anche a CSRF! Quindi, a meno che i sandbox del browser non impediscano ai plug-in di violare SOP (lo fanno forse?), Preferisco raccomandare di attenersi al token CSRF.

— Chris Lercher

@ChrisLercher: Sì, i plug-in moderni sembrano essere un po 'più robusti. Tuttavia, in qualsiasi momento potrebbe essere rilasciata una nuova versione che consente a un utente malintenzionato di sfruttarla in modo tale da aggirare le protezioni del browser. Il modo migliore per gestirlo (ad es. Token / header) dipenderà dalla sensibilità dei tuoi dati e se tale rischio è accettabile. Flash obbedisce a una SOP, ma l'origine di un plug-in Flash è il sito da cui è stato caricato (piuttosto che il sito chiamante come JavaScript). C'è un crossdomain.xmlche può abilitare la comunicazione tra domini.

— SilverlightFox

Il contenuto web non può manomettere l'intestazione Origin. Inoltre, con la stessa politica di origine, un'origine non può nemmeno inviare intestazioni personalizzate ad altre origini. [1]

Pertanto, controllare l'intestazione Origin è altrettanto efficace per bloccare gli attacchi quanto utilizzare un token CSRF.

La preoccupazione principale di fare affidamento su questo è se consente a tutte le richieste legittime di funzionare. Il richiedente è a conoscenza di questo problema e ha impostato la domanda per escludere i casi principali (nessun vecchio browser, solo HTTPS).

I fornitori di browser seguono queste regole, ma per quanto riguarda i plugin? Potrebbero no, ma la domanda ignora i "browser manipolati". E i bug nel browser che consentono a un utente malintenzionato di falsificare l'intestazione Origin? Possono esserci bug che consentono al token CSRF di trapelare anche tra le origini, quindi ci vorrebbe più lavoro per sostenere che uno è migliore dell'altro.

— ospite
fonte

Ho appena testato Firefox 47 e non invia un'intestazione di origine per un post del modulo cross-origin (un modo comune di attaccare i servizi REST che non abilitano CORS per XHR), quindi non credo che un controllo dell'intestazione di origine sarebbe efficace se l'utente utilizza Firefox.

— Andy

Per riferimento, il problema di Firefox che non invia un'intestazione "Origin" viene monitorato su Bugzilla: bugzilla.mozilla.org/show_bug.cgi?id=446344 Potresti ripiegare al controllo dell'intestazione "Referer" in questo caso ma nella mia esperienza alcuni Gli utenti di Firefox bloccano l'intestazione "Referer" per motivi di privacy (anche se IMHO sarebbe sufficiente per rimuovere il percorso e la query).

— Steffen