So come un tag form è incline a CSRF che non usa alcun token (o qualsiasi altro meccanismo di challenge-response) ma mi chiedevo come un iFrame possa essere usato per causare l'attacco XSRF e quali sarebbero le tecniche di mitigazione? Di seguito è riportato l'esempio di codice:
document.write('<IFRAME SRC="https://somedomain/abcde;src=;type=;cat=;ord=;num='+ a + '?" WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>');
L'esempio di codice che hai fornito è una vulnerabilità cross site scripting , perché consente l'esecuzione di JavaScript arbitrario , supponendo che "a" non sia attendibile:
a = "\"); evil(); document.write(\""
Un sito dannoso può utilizzare un IFrame per sfruttare un sito vulnerabile tramite CSRF :
In un tipico attacco CSRF, il browser viene ingannato da un sito dannoso per inviare una richiesta a un sito vulnerabile. Il browser includerà i cookie per quel sito, quindi la richiesta verrà autenticata dal punto di vista del sito vulnerabile.
Sebbene esistano numerosi modi per attivare la richiesta GET, la richiesta POST cross site viene generalmente creata inviando un modulo. Mentre JavaScript può essere utilizzato per attivare automaticamente l'invio, non può essere utilizzato per nascondere la pagina dei risultati . Quindi, con un semplice attacco CSRF basato su POST, l'utente verrà avvisato dopo il fatto.
Quindi il trucco consiste nel mettere il modulo di invio automatico malevolo in un IFrame invisibile . Pertanto, l'utente non vedrà la pagina web che mostra il risultato della presentazione.
Un attacco correlato è click-jacking : il sito vulnerabile (ad es. pulsante) viene caricato in un Iframe trasparente e JavaScript viene utilizzato per spostarlo nella posizione appropriata e tenerlo posizionato sul cursore del mouse. Se l'utente si sforza di cliccare su qualsiasi cosa sul sito malevolo, farà invece clic sullo Iframe trasparente.
Un iframe non può presentare una vulnerabilità di Cross Site Request Forgery o Cross Site Scripting. Un iframe non è in grado di influenzare un'applicazione in questo modo a causa delle regole di ereditarietà degli iframe .
Gli iframe vengono utilizzati dall'hacker in un attacco UI di riparazione . Dovresti anche leggere il foglio trucchi sulla prevenzione CSRF . Soprattutto la parte su come l'XSS può essere usato per minare i sistemi di protezione CSRF.
Se l'applicazione vulnerabile CSRF si lascia incorporare in un Iframe, allora sì. In che modo aiuta l'aggressore?
Gli iframe possono essere resi invisibili impostando la dimensione a zero. Quindi, contrariamente al normale csrf in cui la vittima potrebbe avere un'idea di qualcosa di sospetto, in caso di iframe invisibile, non vedrà nulla.
L'attaccante invierà il modulo per conto della vittima dove il modulo verrà incorporato all'interno di iframe. Questo è bello.
Infatti c'è un altro inganno che può essere utilizzato se l'applicazione utilizza un token per impedire CSRF ma si lascia comunque incorniciare.
Usando il metodo falso captcha può indurre l'utente a inviare il token usando alcuni social engineering e javascript. Nota che questo funziona solo in Firefox, sorpresa !!
Leggi altre domande sui tag source-code web-application penetration-test attack-prevention csrf