Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) induce il browser di un utente autenticato a inviare richieste non autorizzate a un'applicazione web. Il browser invia automaticamente i cookie insieme alle richieste, quindi senza misure aggiuntive il server non può distinguere le richieste legittime da quelle contraffatte.

Scenario:

1. La vittima ha effettuato l'accesso a bank.com (cookie di sessione nel browser)
2. La vittima visita la pagina dell'attaccante contenente: <img src="https://bank.com/transfer?to=attacker&amount=1000">
3. Il browser invia la richiesta GET allegando il cookie di bank.com
4. La banca elabora il trasferimento

Il CSRF tramite POST richiede un modulo:

La difesa principale consiste in un token CSRF: un valore casuale e segreto, specifico per sessione o per richiesta, incorporato nei moduli. Il server convalida il token per ogni richiesta che modifica lo stato. Un attaccante su un altro dominio non può leggere il token, in base alla politica della stessa origine.

SameSite=Strict: il cookie non viene mai inviato con richieste cross-site. SameSite=Lax: il cookie viene inviato con navigazioni di primo livello sicure, come i link, ma non con richieste POST provenienti da altri siti. I browser moderni utilizzano per impostazione predefinita Lax, riducendo significativamente il rischio di CSRF.

Un'alternativa all'archiviazione del token lato server: imposti un cookie CSRF casuale e richieda che venga inviato anche come parametro della richiesta. Un attaccante non può leggere il cookie, poiché è soggetto alla stessa origine, quindi non può inserirne un valore corrispondente nei dati del modulo.

Per le richieste AJAX, richiedere un'intestazione personalizzata, ad esempio X-Requested-With: XMLHttpRequest, offre protezione contro il CSRF perché i browser impediscono agli script cross-origin di impostare intestazioni arbitrarie: è CORS a imporlo.

I token CSRF non sono efficaci se:

• è presente XSS: l'attaccante può leggere il token tramite JavaScript
• il token viene divulgato nell'URL, tramite l'intestazione Referer
• il token è prevedibile o riutilizzato
• CORS è configurato in modo errato per consentire l'origine dell'attaccante

Procedura di test:

1. Individui le richieste che modificano lo stato (POST, PUT, DELETE)
2. Rimuova o modifichi il token CSRF e invii nuovamente la richiesta
3. Crei un invio di modulo cross-origin e verifichi se ha esito positivo
4. Verifichi l'attributo SameSite sui cookie di sessione

Le API REST che utilizzano JSON sono spesso esenti dal CSRF se:

• richiedono Content-Type: application/json (i moduli HTML non possono impostarlo)
• utilizzano un'autenticazione basata su token (intestazione Authorization, non cookie)

Tuttavia, le API che accettano cookie devono comunque implementare la protezione CSRF.

Poiché SameSite=Lax è l'impostazione predefinita in Chrome, Firefox e Safari, molti attacchi CSRF tradizionali vengono bloccati. Tuttavia, gli attacchi ai sottodomini e determinati schemi di navigazione possono ancora aggirare Lax. Combini SameSite con i token CSRF per una difesa solida.

Qual è la difesa principale contro gli attacchi CSRF nelle applicazioni web?

Il CSRF sfrutta l'aggiunta automatica dei cookie da parte del browser per contraffare richieste autenticate provenienti da siti dannosi. Difesa principale: token CSRF convalidati lato server. Difesa secondaria: attributo cookie SameSite=Strict/Lax. Le API che utilizzano l'autenticazione tramite token nelle intestazioni, e non tramite cookie, sono naturalmente resistenti al CSRF. Combini le difese: l'XSS può aggirare i token CSRF, se presenti.