Cross-Site Request Forgery (CSRF)
Un attacco CSRF costringe un utente autenticato (vittima) a inviare una richiesta HTTP contraffatta, incluso il cookie di sessione della vittima a un'applicazione Web vulnerabile, che consente all'aggressore di forzare il browser della vittima a generare richieste in modo tale che l'app vulnerabile percepisca come richieste legittime da la vittima.
Cerchiamo di comprendere gli agenti di minaccia, i vettori di attacco, la debolezza della sicurezza, l'impatto tecnico e gli impatti sul business di questo difetto con l'aiuto di un semplice diagramma.
Esempio
Ecco un classico esempio di CSRF:
Step 1 - Diciamo che l'applicazione vulnerabile invia una richiesta di modifica dello stato come testo normale senza alcuna crittografia.
http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243
Step 2 - Ora l'hacker costruisce una richiesta che trasferisce denaro dall'account della vittima all'account dell'attaccante incorporando la richiesta in un'immagine che viene archiviata su vari siti sotto il controllo dell'attaccante -
<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#"
width = "0" height = "0" />
Mani su
Step 1- Eseguiamo una contraffazione CSRF incorporando uno script Java in un'immagine. L'istantanea del problema è elencata di seguito.
Step 2 - Ora dobbiamo simulare il trasferimento in un'immagine 1x1 e fare in modo che la vittima faccia clic sulla stessa.
Step 3 - Dopo aver inviato il messaggio, il messaggio viene visualizzato come evidenziato di seguito.
Step 4- Ora se la vittima fa clic sul seguente URL, viene eseguito il trasferimento, che può essere trovato intercettando l'azione dell'utente utilizzando la suite burp. Siamo in grado di vedere il trasferimento individuandolo in Ricevi messaggio come mostrato di seguito -
Step 5 - Ora, facendo clic su Aggiorna, viene visualizzato il segno di completamento della lezione.
Meccanismi preventivi
CSRF può essere evitato creando un token univoco in un campo nascosto che verrebbe inviato nel corpo della richiesta HTTP piuttosto che in un URL, che è più incline all'esposizione.
Costringere l'utente a autenticarsi nuovamente o dimostrare di essere utenti al fine di proteggere CSRF. Ad esempio, CAPTCHA.