Perché non esiste un flag SameOrigin che puoi mettere sui cookies per prevenire CSRF?

3

Oggi stavo passando attraverso il processo per assicurarmi che il mio server sia protetto dagli attacchi CSRF, e mi stavo chiedendo perché non c'è solo una bandiera SameOrigin che posso impostare sui miei cookie. Più o meno allo stesso modo in cui puoi impostare HTTPOnly o Secure sui cookie, penso che dovrebbe esserci un flag SameOrigin che invierebbe il cookie solo se il browser era attualmente nello stesso sito Web su cui era impostato il cookie.

Questa non sarebbe una soluzione elegante per risolvere gli attacchi CSRF? Puoi anche implementarlo in un modo compatibile con le versioni precedenti, in cui i cookie che non hanno impostato SameOrigin vengono trattati nel modo in cui i cookie si sono sempre comportati.

    
posta satnam 12.01.2017 - 20:57
fonte

2 risposte

2

È una buona idea, e come @ paj28 evidenziato nei commenti, c'è già un RFC bozza per i cookie SameSite .

Uno svantaggio menzionato nella bozza:

Consider the scenario in which a user reads their email at MegaCorp Inc's webmail provider "https://example.com/". They might expect that clicking on an emailed link to "https://projects.com/secret/project" would show them the secret project that they're authorized to see, but if "projects.com" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.

In sostanza, un cookie SameOrigin severo interromperebbe i collegamenti ai componenti back-end.

Il progetto propone anche una modalità privilegiata che invierebbe cookie sulle richieste GET attraverso le origini, ma è un problema comune che molte applicazioni non seguono restful, ma invece hanno richieste GET che cambiano lo stato del server.

Un altro problema è che le applicazioni dovranno ancora implementare la propria protezione CSRF per tutti quegli utenti che non utilizzano i cookie aggiornati, quindi i costi di sviluppo aggiuntivi per la corretta configurazione dei cookie SameOrigin potrebbero non valerne la pena per alcuni sviluppatori.

    
risposta data 11.02.2017 - 22:33
fonte
1

I cookie sono intrinsecamente della stessa origine, nel senso che i cookie vengono inviati dal browser solo all'origine (e ai possibili sotto-domini) che impostano il cookie in primo luogo. Facendo riferimento alle informazioni sul tuo commento, i cookie sono solo tra il browser e un sito. Il motivo per cui un attacco CSRF ha esito positivo anche se la richiesta di origine proviene da un dominio diverso è a causa del punto in cui la richiesta sta andando a, non da dove proviene FROM.

A proposito della retrocompatibilità, un cookie non di origine uguale potrebbe essere uno che potrebbe essere impostato o inviato ad altri domini. Sarebbe pericoloso dato che non vorresti che evil.com riceva i cookie di google.com.

    
risposta data 12.01.2017 - 22:05
fonte

Leggi altre domande sui tag