Firma Double Submit Cookies, dove il valore è una stringa pseudo casuale e una sua firma. È più sicuro?

Naviga le tue risposte
3

Non sono sicuro se sto descrivendo qualcosa che è già stato proposto. In caso contrario, mi piacerebbe coniare questo " Double Submit Cookies " come metodo per migliorare la tecnica Double Submit Cookies che tenta di impedire Attacchi CSRF .

Ecco il concetto :

  1. Prima di generare una pagina web, il server imposta un cookie nell'intestazione in cui il valore include due valori:

    • token valore generato da un numero casuale strong e

    • firma valore che è la firma del token (o forse semplicemente un hash di esso che è stato salato).

  2. Quando il client effettua richieste successive, legge il cookie e include la firma del token + nelle richieste POST o GET (insieme a cookie che si trova automaticamente nelle intestazioni della richiesta).

  3. Quando il server riceve la richiesta, autentica con:

    • controlla se il token + firma inclusa nelle richieste POST o GET corrisponde al valore del cookie nell'intestazione della richiesta e

    • prendendo il valore (cookie / stringa di query) token e lo firma nuovamente e confronta se la firma risultante corrisponde al valore (cookie / stringa di query) signature . Se corrisponde, dimostra che il cookie non è stato scritto in modo cieco da un sottodominio o altro.

Per ragioni, supponiamo che le prevenzioni degli attacchi XSS siano state implementate correttamente e che solo SSL sia vero.

Questo metodo è già stato utilizzato in precedenza? Previene correttamente l'attacco in cui un sottodominio scrive i cookie sul dominio genitore ?

[EDIT: Originariamente avevo il token e la firma in due cookie separati, ma per semplificare come suggerito da @SteffenUllrich, ho modificato la domanda in modo da riflettere sia il token che la firma in un cookie.]

    
posta Joseph Shih 25.04.2016 - 06:01
fonte

2 risposte

1

Non credo che ciò fornirebbe più protezione rispetto ai normali cookie double submit.

Se un utente malintenzionato può sovrascrivere un cookie utilizzando un sottodominio non protetto (https), è possibile che sovrascrivano semplicemente 2 cookie.

L'attaccante nel senario otterrebbe un token legittimo e un valore token firmato, incorporerebbe entrambi quelli nella richiesta e scriverà questi due cookie nella cache del browser utilizzando la vulnerabilità del sottodominio.

    
risposta data 25.04.2016 - 07:43
fonte
2

Il problema con il doppio invio naive è che se l'utente malintenzionato potrebbe inserire un cookie controllato da un attaccante, potrebbe anche impostare il token CSRF su questo cookie e in questo modo sconfiggere la protezione CSRF - perché token e cookie corrispondono.

Questo può essere sconfitto se l'attaccante non è in grado di creare un token CSRF e indovinare il cookie di verifica corrispondente. Ciò può essere ottenuto avendo un certo segreto lato server che viene utilizzato nella creazione del cookie di verifica dal token CSRF, ovvero una firma utilizzando una chiave privata lato server, un hash di token segreto o simile. In questo caso, non importa se la firma è un cookie separato, è inclusa nel cookie di verifica o se si utilizza solo la firma come cookie di verifica.

Quindi, in questo caso, ritengo che la tua soluzione possa aiutare contro i problemi con il doppio invio nativo, ma è un complesso non necessario: non hai bisogno di due cookie ma puoi semplicemente usare la firma come cookie di verifica. Per la verifica, prova a firmare il token CSRF e, se corrisponde alla firma, tutto va bene. E l'attaccante non è in grado di creare un token e una firma corrispondente perché non conosce il segreto del lato server necessario per la firma.
MODIFICA: si noti che la firma dovrebbe includere anche informazioni riguardanti l'utente corrente, ad es. l'ID della sessione. Altrimenti sarebbe possibile per qualche altro utente ottenere una coppia di firma + token valida e riutilizzarla.

Si noti che nulla di tutto ciò aiuta se l'utente malintenzionato accede al token CSRF e al cookie di verifica perché in questo caso potrebbe essere utilizzato per riutilizzare questa coppia. Ma questo non è lo scenario di attacco di cui si occupa il doppio invio, cioè presuppone che la lettura del cookie sia protetta utilizzando i cookie httpOnly e una connessione protetta (https) e neanche XSS.

    
risposta data 25.04.2016 - 07:00
fonte

Leggi altre domande sui tag

La JWT è presente nei cookie con qualsiasi soluzione CSRF altrettanto vulnerabile all'XSS di JWT in localStorage? Analisi del testo dell'email spam