CSRF manipolando le intestazioni HTTP dal lato client utilizzando JavaScript

1

Sto cercando di eseguire un'analisi di vulnerabilità CSRF per il mio sito web. Il mio sito Web utilizza un token anti-CSRF che viene inviato dal server al client con il cookie di sessione e quindi Javascript nel client lo elimina dal cookie e lo attacca come un'intestazione XSRF-TOKEN separata per essere rispedito al server .

Ho provato gli attacchi CSRF su un modulo vulnerabile XSS sul mio sito web da BurpSuite generando CSRF PoC dopo aver intercettato la richiesta, salvandola in un file html e aprendo il file in una nuova scheda con una sessione attiva in un'altra scheda. Ho scoperto che il browser non è in grado di inviare automaticamente il token XSRF ma lo fa per tutti i cookie e le altre intestazioni.

Voglio sapere se è possibile creare un nuovo o manipolare l'intestazione XSRF-TOKEN esistente dal lato client usando uno script e inviarlo con la richiesta. O se esiste un altro modo per inviare forzatamente l'intestazione XSRF-TOKEN o qualsiasi altro modo per eseguire l'attacco CSRF ?? A partire da ora, l'unica vulnerabilità che conosco è che sono in grado di aprire il mio sito web in un iframe proveniente da un altro dominio.

    
posta Akshay 18.09.2015 - 12:41
fonte

2 risposte

1

JavaScript di un altro dominio non può manipolare o leggere contenuti dal tuo dominio, anche in un IFrame, a causa della stessa politica di origine . Pertanto lo scenario di attacco che descrivi non è un rischio in quanto questa non è una vulnerabilità.

Ricorda che Double Submit Cookies ha altre vulnerabilità. Vedi questa risposta .

Un modo per eludere le protezioni CSRF è che un utente malintenzionato usi invece Clickjacking . Per evitare che ciò accada, assicurati che il tuo sito non possa essere inquadrato utilizzando l' X-FRAME-OPTIONS intestazione e la politica di sicurezza dei contenuti frame ancestors direttiva.

    
risposta data 22.09.2015 - 11:31
fonte
0

L'ultima frase non riguarda CSRF, ma riguarda Click Jacking, questi non sono correlati.

L'unica cosa che posso pensare di modificare l'intestazione XSRF-TOKEN come un utente malintenzionato è quando sei vulnerabile all'inquinamento dei parametri HTTP.

Per una migliore comprensione della tua implementazione anti CSRF, sarebbe meglio se descrivessi come vengono controllati il cookie e l'intestazione.

Ho visto implementazioni che controllano solo se il valore del cookie è uguale al valore dell'intestazione, che a mio parere non è corretto in quanto il server dovrebbe controllarne il valore e non solo confrontare i due.

    
risposta data 18.09.2015 - 13:02
fonte

Leggi altre domande sui tag