Gli attacchi CSRF sono davvero ciechi

La Politica Same-Origin rende impossibile per JavaScript su A.com leggere i contenuti di B .com. Tuttavia, la politica Same-Origin non impedisce a JavaScript o HTML su A.com di inviare una richiesta arbitraria a B.com. Per evitare ciò, è necessario un metodo di Prevenzione CSRF , ad esempio un token segreto che non funzionerebbe se il sistema non fosse cieco.

Il punto di CSRF è che incorre in un utile effetto collaterale, come cambiare la password di un utente o aggiungere un account amministrativo. Anche se CSRF non fosse cieco, (a causa di qualche magia, o forse una CORS mal configurata o un insieme di regole crossdomain.xml) non avrebbe importanza poiché la risposta verrebbe probabilmente scartata, tutto ciò che conta è un utile effetto collaterale.

È molto facile inviare richieste GET e POST su più domini, se una richiesta GET comporta un effetto collaterale, allora è vulnerabile a CSRF. Un buon esempio di ciò è un'applicazione PHP che utilizza $_REQUEST per tutti gli input.

Sì, sono ciechi. La politica di origine identica impedisce alle pagine ospitate in un dominio di utilizzare un protocollo [e talvolta anche una porta] per effettuare richieste arbitrarie su un dominio / protocollo diverso. Pertanto, un utente malintenzionato non sarebbe in grado di effettuare una "richiesta Ajax CSRF" a meno che il server non supporti CORS . Ciò che rende possibili gli attacchi CSRF sono le eccezioni per la politica della stessa origine, ovvero i tipi di richiesta che qualsiasi sito Web è autorizzato a rendere a qualsiasi host.

La maggior parte delle eccezioni alla politica della stessa origine tuttavia non ti permette di fare nulla di utile (compresa la lettura) con la risposta:

• Puoi impostare src di un'immagine su un altro dominio, ma la risposta verrà riprodotta correttamente come immagine affinché l'utente possa vedere o non visualizzare nulla;
• Puoi impostare src di uno script su un altro dominio, ma verrà eseguito o causerà un errore di sintassi o simile;
• Puoi collegarti a un foglio di stile esterno, ma non puoi accedere al suo contenuto in modo programmatico;
• Puoi includere un'altra pagina in frame ou iframe , ma non puoi accedere ai suoi contenuti DOM a causa della politica della stessa origine; ecc.

Ecco perché, come già sottolineato da altri, la risposta non è ciò che è interessante per un utente malintenzionato, ma gli effetti collaterali che la richiesta può avere.

Prima di tutto, gli attacchi CSRF non richiedono alcun JavaScript. È possibile creare richieste arbitrarie con puro HTML per inviare richieste GET o POST arbitrarie tramite immagini semplici o moduli semplici.

JavaScript sarebbe utile solo per inviare automaticamente i moduli di quest'ultimo come non vengono inviati automaticamente come farebbe una richiesta per un'immagine. Ma puoi anche modificare il pulsante di invio del modulo per estendere l'intera pagina e renderlo trasparente in modo che non venga visualizzato dall'utente, ma se fa clic in qualche punto della pagina, il modulo verrà inviato.

Nella maggior parte dei casi, l'invio della richiesta falsificata è sufficiente per l'aggressore poiché l'intenzione è semplicemente di attivare un'azione in nome e contesto della sessione della vittima. Per questo è sufficiente un semplice modulo HTML.

Ma con JavaScript, la Politica Same-Origin entra in gioco, il che rende molto più difficile. L'origine viene determinata sull'URI del documento (ad esempio, lo schema, l'host e la porta). Solo se l'origine di due documenti o risorse è identica, i due documenti / risorse sono di origine identica. Se non sono di origine identica, la politica Same-Origin sostanzialmente non consente alcuna richiesta XHR o accesso diretto tramite DOM (ad esempio frame).

Con la seconda versione di XMLHttpRequest (XHR) , la tecnologia utilizzata con Ajax, le richieste di origine incrociata erano consentite in determinate circostanze definite in Condivisione delle risorse tra origini . Le regole di base sono che le richieste incrociate semplici sono consentite mentre altre richiedono una richiesta di preflight prima della richiesta effettiva . Tale preflight viene utilizzato per determinare se il server accetterà la richiesta effettiva. Solo se la richiesta di verifica preliminare ha esito positivo, viene inviata la richiesta effettiva.

Tuttavia, anche se è solo una semplice richiesta e la richiesta ha esito positivo, il server potrebbe ancora non consentire al browser di rendere la risposta disponibile per JavaScript, sempre tramite determinati campi di intestazione di risposta definiti in CORS.

Per quanto riguarda gli attacchi CSRF, in particolare l'ultimo tipo di richieste cross-origin sono meritevoli in quanto contengono le credenziali dell'utente come le informazioni di autenticazione HTTP, i cookie, ecc., che sarebbero necessari per attivare azioni privilegiate sul server. Tuttavia, a meno che la risorsa consenta tali richieste di origine incrociata , il browser non consentirà JavaScript invia questi.

Quindi la conclusione è:

• CSRF non richiede JavaScript, tuttavia rende molto più semplice lo sfruttamento automatico.
• La falsificazione di richieste basate su HTML semplice è molto più promettente a causa della mancanza di conformità con la politica Same-Origin, richiesta da JavaScript.
• La lettura della risposta è possibile solo con JavaScript ma richiede che la risorsa lo consenta, soprattutto se sono richieste le credenziali dell'utente.