Un attacco CSRF è quello che fa sì che gli utenti autenticati eseguino azioni indesiderate nell'applicazione Web con cui sono autenticati. Questo viene fatto attraverso un sito esterno che l'utente visita e che innesca queste azioni.

In questo articolo, otterrai le informazioni richieste dall'applicazione per sapere cosa dovrebbe fare il sito di attacco per inviare richieste valide al server vulnerabile. Quindi, creerai una pagina che simuli le richieste legittime e inganni l'utente a visitare quella pagina mentre è autenticato. Farai anche alcune iterazioni sulla prova di base del concetto per renderlo più simile a un attacco del mondo reale, in cui la vittima non se ne accorge. Si noti che il file di codice per questo articolo è disponibile presso il github dell'autore.

Prepararsi

Avrai bisogno di un account utente valido in Bodgeit per questo articolo. Questo articolo utilizza [email protected] Come vittima:

Come farlo…

Innanzitutto, devi analizzare la richiesta che desideri forzare la vittima a fare. Per fare ciò, hai bisogno di Burp Suite o un altro proxy configurato nel browser:

1. Accedi a Bodgeit come utente e fai clic sul nome utente per andare al profilo.
2. Apportare una modifica della password. Guarda come appare la richiesta nel proxy:

   Quindi, è un INVIARE richiesta a http: // 192.168.56.11/Bodgeit/password.JSP, e ha solo la password e la sua conferma nel corpo.

3. Prova a creare una pagina HTML molto semplice che replica questa richiesta. Crea un file (nominalo CSRF-CHANGE-PASWORD.html) con i seguenti contenuti:
   
   
   
   
   
   
   
   
   
   
4. Ora caricano questo file nello stesso browser della sessione di accesso:
5. Fare clic su Invia e verrai reindirizzato alla pagina del profilo dell'utente. Ti dirà che la password è stata aggiornata correttamente.
6. Sebbene questo dimostri il punto, un sito esterno (o una pagina HTML locale come in questo caso) può eseguire una richiesta di modifica della password sull'applicazione. È ancora improbabile che un utente faccia clic su Invia Puoi automatizzarlo e nascondere i campi di input in modo che il contenuto dannoso sia nascosto. Ora, crea una nuova pagina basata sulla precedente; chiamalo CSRF-CHANGE-PASSWORD SCRIED.html:
   
   
   

   Una pagina completamente innocua

   
   Puoi fidarti di questa pagina.
   Non succederà niente di male a te o al tuo account Bodgeit.
   
   
   
   
   
   
   
   

   Questa volta, il modulo ha un parametro ID e c'è uno script nella pagina che invierà il suo contenuto quando la pagina viene caricata completamente.

7. Se si carica questa pagina nello stesso browser in cui hai avviato una sessione Bodgeit, invierà automaticamente la richiesta e la pagina del profilo dell'utente verrà visualizzata successivamente. Nella seguente screenshot, il browser DebuggerImposta un punto di interruzione poco prima che fosse presentata la richiesta:
8. Quest'ultimo tentativo sembra migliore dal punto di vista dell'attaccante. Hai solo bisogno che la vittima carichi la pagina e la richiesta verrà inviata automaticamente, ma la vittima vedrà il La tua password è stata modificatamessaggio, e questo aumenterà sicuramente un avviso.
9. È possibile migliorare ulteriormente la pagina di attacco facendola caricare la risposta in una cornice invisibile all'interno della stessa pagina. Ci sono molti modi per farlo; Uno rapido e sporco è impostare una taglia 0 per il frame. Il tuo file sembrerebbe così:
   
   
   

   Una pagina completamente innocua

   
   Puoi fidarti di questa pagina.
   Non succederà niente di male a te o al tuo account Bodgeit.
   
   Target = "Target_Frame">
   
   
   
   
   
   
   

   Notare come la proprietà target del modulo è l'iframe definito appena sotto di esso e che tale frame ha altezza e larghezza dello 0%.

10. Carica la nuova pagina nel browser in cui è stata avviata la sessione. Questo screenshot mostra come appare la pagina quando viene ispezionata con il browser Strumenti di sviluppo: Nota che l'oggetto iFrame è solo una linea nera sulla pagina e, in ispettore, puoi vedere che contiene la pagina del profilo dell'utente di Bodgeit.
11. Se analizzi le comunicazioni di rete intraprese dalla tua pagina CSRF, puoi vedere che effettivamente fa richieste di modificare la password BodGEIT:

Come funziona…

Quando si invia una richiesta da un browser e hai già un cookie appartenente al dominio target memorizzato, il browser collegherà il cookie alla richiesta prima che venga inviato. Questo è ciò che rende i cookie così convenienti come identificatori di sessione, ma questa caratteristica di come funziona HTTP è anche ciò che lo rende vulnerabile a un attacco come quello che hai visto in questo articolo.

Quando si carica una pagina nello stesso browser, in cui si dispone di una sessione attiva in un'applicazione, il browser collegherà automaticamente il cookie di sessione a tale richiesta. Questo accade anche se è una scheda o una finestra diversa e questa pagina fa una richiesta al dominio in cui viene avviata la sessione.

Se il server non verifica che le richieste che riceve effettivamente originate dall'applicazione, consente a un sito dannoso di effettuare chiamate per conto di utenti legittimi e attivi che visitano questo sito dannoso mentre sono autenticati nel dominio target.

In un test di penetrazione dell'applicazione Web, il primo codice utilizzato, quello con i due campi di testo e il Invia pulsante, potrebbe essere sufficiente per dimostrare la presenza di un difetto di sicurezza. Tuttavia, il test di penetrazione dell'applicazione può far parte di un altro impegno, come un ingegneria sociale o un esercizio di squadra rossa. In questo caso, saranno necessari qualche sforzo extra per impedire all'utente della vittima di sospettare che qualcosa stia accadendo.

In questo articolo, hai utilizzato JavaScript per automatizzare l'invio della richiesta impostando l'evento Onload sulla pagina ed eseguendo il metodo di invio del modulo nella funzione Handler Event. Hai anche usato un IFRAME nascosto per caricare la risposta della modifica della password, quindi la vittima non vede mai il messaggio che la sua password è cambiata.

Se hai trovato questo articolo interessante, puoi esplorare Libro di cottura di Kali Linux Web Penetration Test - Seconda edizione Scoprire le vulnerabilità del web più comuni e impedire loro di diventare una minaccia per la sicurezza del tuo sito. Libro di cottura di Kali Linux Web Penetration Test - Seconda edizione ti dà le competenze necessarie per coprire ogni fase di un test di penetrazione - dalla raccolta di informazioni sul sistema e sull'applicazione all'identificazione delle vulnerabilità attraverso i test manuali.