CSRF Oggi: Tecniche, Mitigazioni e Bypass

Jan 21 2023

Ciao gente, spero che stiate tutti bene! Questo è il mio secondo post sul blog ed è piuttosto lungo. Il motivo è la profondità che ho approfondito con l'argomento, per includere tutte le informazioni rilevanti il più possibile in un blog. Spero che vi piaccia e impariate qualcosa di nuovo. Vorrei anche aggiungere che questo blog è più dal punto di vista degli aggressori piuttosto che dal punto di vista degli sviluppatori; tuttavia, ho cercato di rendere questo blog il più semplice possibile in modo da aiutare il massimo pubblico appartenente a diversi campi. Cominciamo!

Cross-Site Request Forgery (CSRF) è un attacco in cui un utente malintenzionato costringe un utente a eseguire azioni indesiderate su un'applicazione Web in cui è attualmente autenticato, all'insaputa dell'utente (ad es. trasferimento di denaro, modifica della password, commenti su un post, eccetera). Gli attacchi CSRF sono noti anche con una serie di altri nomi, tra cui XSRF, "Sea Surf", Session Riding, ecc.

Come fa un utente malintenzionato a raggiungere questo obiettivo?

Una panoramica di come un utente malintenzionato può eseguire con successo questo tipo di attacco è la seguente:
1) L'utente vittima si autentica sull'applicazione vulnerabile utilizzando le proprie credenziali.
2) L'aggressore induce l'utente vittima a visitare un sito dannoso. (Utilizzando lo stesso browser su cui la vittima è autenticata sull'applicazione vulnerabile)
3) L'utente vittima visita il sito dannoso.
4) Il sito presenta un pulsante “Clicca qui”. Non appena l'utente vittima fa clic sul pulsante, il sito dannoso invia una richiesta all'applicazione vulnerabile per eseguire un'azione critica per conto dell'utente vittima (ad esempio, una transazione monetaria o un cambio di password).
5) Poiché il browser Web è progettato per allegare automaticamente i cookie dell'utente insieme a ogni richiesta autenticata, per facilità d'uso, il browser invierà direttamente la richiesta al sito vulnerabile insieme ai cookie della sessione dell'utente, rendendola quindi una richiesta autenticata.
6) L'applicazione vulnerabile riceve questa richiesta che contiene i cookie di sessione dell'utente vittima e la elabora come una richiesta autentica. L'utente vittima è completamente all'oscuro di qualsiasi azione da lui eseguita in questo processo.

Zine CSRF creata da sec_r0

Il codice utilizzato dall'attaccante per inviare una richiesta autenticata al sito vulnerabile dal dominio controllato dall'attaccante può essere simile a questo codice menzionato qui:

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://www.vulnerbale-site.com/index.php?page=transfer-amount.html" method="POST">
      <input type="hidden" name="amount" value="5000" />
      <input type="hidden" name="to" value="attacker -account-id"/>
<input type="hidden" name="send" value="send" />
<input type="submit" value="Click Here" />
    </form>
  </body>
</html>

La vittima apre CSRF POC nel suo browser

Nel momento in cui la vittima fa clic su "Fai clic qui", una richiesta inviata nel back-end dal browser della vittima contenente i suoi cookie di sessione.

Richiesta inviata dal browser delle vittime al server delle applicazioni

Questa richiesta viene accettata dal server e BOOM! Attacco riuscito. La vittima non ha la minima idea di aver appena trasferito 5000 di valuta sul conto dell'aggressore.

Nota: per sfruttare con successo questo tipo di attacco, non è necessario che la vittima faccia clic su qualcosa sul sito dannoso, come il pulsante "Fai clic qui" nell'esempio precedente. L'aggressore può altrettanto facilmente creare un codice HTML che invia automaticamente la richiesta al sito vulnerabile non appena l'utente vittima apre la pagina Web dannosa nel suo browser. L'impatto di questa vulnerabilità dipende dalla funzionalità dell'applicazione vulnerabile. Questo attacco può anche essere intensificato fino all'acquisizione del controllo dell'account della vittima a seconda della funzionalità dell'applicazione.

Come può un utente evitare di essere vittima di tali attacchi?

Un utente dovrebbe evitare completamente di visitare qualsiasi sito Web non attendibile nel suo browser. Si dovrebbe anche evitare di aprire qualsiasi tipo di codice HTML non attendibile nel proprio browser per prevenire tali attacchi.
Disconnettersi sempre dall'applicazione corrente e chiudere la sessione del browser prima di aprire qualsiasi altro sito Web nello stesso browser. Evita di aprire più schede con diversi siti Web aperti in ognuna quando utilizzi un'applicazione critica.

Nel complesso, questa vulnerabilità può essere semplicemente mitigata disponendo di un meccanismo che differenzia una richiesta autentica da una non autentica sul lato server.

Ciò può essere ottenuto utilizzando:

Token Anti-CSRF
Cookie di doppio invio
Convalida del referrer e dell'origine della richiesta
Invio dati in formato JSON/XML
Invio di alcuni dati nelle intestazioni della richiesta che violano la stessa politica di origine del browser se la richiesta viene inviata tra domini. (Ad es. Intestazione di autorizzazione utilizzata per autorizzare un utente sull'applicazione, utilizzata anche per l'autenticazione in determinate applicazioni)
Attributo cookie SameSite
Captcha
Stato di visualizzazione

1) L'applicazione ha implementato il token Anti-CSRF:

Un token univoco, non indovinabile e sufficientemente lungo che viene inviato insieme a ogni richiesta autenticata in cui l'utente esegue un'azione sul sito vulnerabile.

Ad esempio, osserva la richiesta di seguito in cui un utente aggiunge una nuova voce al suo blog

POST /index.php?page=add-to-your-blog.php
Host HTTP/1.1: testsite.com
Agente utente: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/ 89.0
Accetta: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accetta-Language: en-US,en;q=0.5 Accetta-Codifica
:
gzip , deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 78
Origine: http://testsite.com
Connessione: close
Cookie: showhints=1; PHPSESSID=tr7qoooe0ifkb93s59jsjel1u4
Richieste di aggiornamento non sicure: 1

Anti-Csrf-token=jhGHU12HJUJJSKfb1CKPOEGDCNDMFKGHSSgh&blog_entry=test&aggiungi-al-tuo-blog-php-submit-button=Salva+Blog+Voce

Questo tipo di configurazione, se implementato correttamente, è una delle migliori mitigazioni disponibili contro CSRF. Poiché il token è lungo, unico per sessione e non indovinabile, un utente malintenzionato non può indovinare il valore del token Anti-CSRF inviato nella richiesta di cui sopra per l'utente vittima e quindi non sarà in grado di attaccare l'utente vittima.

Tuttavia, un utente malintenzionato può tentare i metodi indicati di seguito per cercare di aggirare la protezione:

-Si può provare a rimuovere completamente il TOKEN Anti-CSRF dalla richiesta

blog_entry=test&aggiungi-al-tuo-blog-php-submit-button=Salva+Blog+Voce

-O semplicemente omettere il valore del token Anti-CSRF

Anti-Csrf-token=&blog_entry=test&add-to-your-blog-php-submit-button=Salva+Blog+Voce

-Se l'attaccante ha due account sull'applicazione vulnerabile, può provare a utilizzare un token CSRF destinato a uno degli account nella richiesta del secondo account. Se questo viene accettato, significa che l'applicazione non sta convalidando il token CSRF rispetto alla sessione per la quale è valido sul lato server.

-Un utente malintenzionato può anche provare a inviare nuovamente un vecchio token CSRF valido nella sessione corrente e verificare se l'applicazione accetta questo vecchio token.

2) L'applicazione utilizza il cookie Double Submit

Un cookie Double Submit si verifica quando l'applicazione invia un token Anti-CSRF nel cookie e nel corpo della richiesta.

Double Submit Cookie inviato nella richiesta

Sul lato server, l'applicazione verifica se il token inviato nel cookie corrisponde al token inviato nel corpo della richiesta. Se c'è una mancata corrispondenza, l'applicazione scarta la richiesta, in caso contrario, l'applicazione elaborerà ulteriormente la richiesta.
Certe volte in questo tipo di configurazione, lo sviluppatore non sente la necessità di convalidare il token inviato nella richiesta rispetto alla sessione attiva. Ciò potrebbe aprire la strada per aggirare il meccanismo di protezione, nel caso in cui l'attaccante riesca a trovare un modo per manipolare i cookie dell'applicazione (in particolare il valore del token Anti-CSRF inviato nel cookie) utilizzando la vulnerabilità Session Fixation .

L'attacco può essere dimostrato come di seguito;
1) L'attaccante scopre che l'applicazione sta utilizzando Double Submit Cookie per impedire CSRF.
2) L'attaccante cerca una vulnerabilità di correzione della sessione nell'applicazione e scopre che l'applicazione è vulnerabile ad essa.
3) L'attaccante ora trova un modo per correggere la sessione per l'utente vittima e manipola il cookie token anti-CSRF della vittima sul proprio valore token anti-CSRF. Ad esempio; se l'applicazione ha impostato ' Anti-CSRF-Token= jhGHU12HJUJJSKfb1CKPOEGDCNDMFKGHSSgh ' come cookie per la vittima, l'attaccante manipolerà questo cookie in ' Anti-CSRF-Token=Manipulated CSRF Token' nel browser della vittima sfruttando la vulnerabilità di Session Fixation che ha trovato .
4) L'attaccante genera un CSRF POC con questo valore cookie manipolato ( Anti-CSRF-Token=Manipulated CSRF Token ) nel corpo CSRF e ospita questo codice su 'attacker.com/csrf.html'

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://www.vulnerbale-site.com/index.php?page=add-to-your-blog.php" method="POST">
      <input type="hidden" name="blog_entry" value="test" />
      <input type="hidden" name="CSRFToken" value="Manipulated CSRF Token"/>
<input type="hidden" name="add-to-your-blog-php-submit-button" value="Save+Blog+Entry" />
<input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Manipulated Double Submit Cookie inviato nella richiesta

7) Il server riceve questa richiesta e controlla i valori del token Anti-CSRF nel cookie e nel corpo. Conferma che i valori sono gli stessi e accetta la richiesta come valida poiché non convalida il token rispetto alla sessione di accesso.
8) L'aggressore ha eseguito con successo un attacco CSRF.

3) L'Applicazione convalida il Referente o l'Origine della richiesta ricevuta

L'intestazione Referrer e Origin in una richiesta indica al server la pagina da cui ha avuto origine la richiesta.

Una richiesta inviata da attacker.com avrà una richiesta in quanto tale

Richiesta inviata da attacker.com a vulnerabilisite.com

Un'applicazione che convalida l'origine e il referrer di una richiesta ricevuta può prevenire possibili attacchi CSRF. Possibili bypass per questo tipo di protezione possono essere

-Limitazione al POC CSRF di inviare l'intestazione Referrer utilizzando
<head>
<meta name=”referrer” content=”no-referrer”>
</head>
-Si può anche tentare di aggirare il meccanismo di whitelisting/blacklisting utilizzato dall'applicazione.
Se un'applicazione convalida l'intestazione Referrer per contenere vulnerabili-site.com, l'aggressore può registrare un dominio come vulnerabili-site.com.attacker.com e caricare qui il POC CSRF. Altri possibili scenari di bypass sono;
Utilizzo del carattere @ nel dominio. Ad esempio : https://[email protected] Utilizzo
del carattere # per indicare un frammento di URL. Ad esempio; https://attacker.com#vulnerable-site.com -
Si può persino cercare una vulnerabilità di caricamento di file dannosi sull'applicazione in cui si può provare a caricare il POC CSRF nell'applicazione stessa o in uno qualsiasi dei suoi sottodomini. Ora, può condividere l'URL di questo POC CSRF caricato (se accessibile pubblicamente) con la vittima. Poiché la richiesta viene generata dall'applicazione stessa, il referrer e l'origine conterranno il dominio dell'applicazione valido e quindi l'attacco può essere eseguito con successo. Un altro modo per raggiungere questo obiettivo è trovare una vulnerabilità di Cross-Site Scripting sfruttabile nell'applicazione o in un sottodominio. Il Cross-Site Scripting può anche essere utilizzato per rubare un token CSRF valido appartenente alla vittima.