su CSRF sul modulo invia [duplicato]

Il motivo per cui i siti sono in grado di impersonare gli utenti che eseguono azioni è perché i browser invieranno volentieri un HTML <form> a qualsiasi altro dominio specificato utilizzando l'attributo action senza preoccuparsi che le origini siano le stesse o altre restrizioni fornite dal dominio di destinazione. Il dominio originale non ha modo di leggere ciò che è stato ricevuto dall'utente o se la richiesta ha avuto successo. Il dominio originale sta semplicemente inviando l'utente al dominio di destinazione per eseguire un'azione specifica. *

Il motivo per cui questo attacco CSRF non funziona quando si utilizza un token è perché l'utente invia anche cookie pertinenti al dominio di destinazione con ogni richiesta. Il dominio originale non ha modo di leggerli perché i cookie non funzionano nel dominio incrociato tranne in alcuni casi in cui il dominio di destinazione mostra relazioni con l'altro. Pertanto, non dovrebbe essere in grado di prevedere in modo affidabile quale sia il token sul dominio di destinazione.

Tutto ciò che il dominio di destinazione deve fare è verificare che il valore inviato nella richiesta corrisponda al cookie inviato.

<sup>* dominio originale - dominio che obbliga un utente a inviare la richiesta POST / GET
* dominio di destinazione : il dominio riceve la richiesta e "possiede" il cookie del token CSRF.</sup>

Il dominio originale non ha modo di visualizzare il token perché qualsiasi richiesta per esso fallirebbe:

1. Se il dominio originale lo richiedeva tramite PHP, il dominio di destinazione dovrebbe mostrare un cookie totalmente irrilevante destinato a quello specifico "utente" (il server di dominio originale, non l'utente attaccato).
2. Se il dominio originale tenta di leggere il cookie, il browser dovrebbe mostrare solo i cookie relativi al dominio originale, eliminando la possibilità di leggere un cookie da un altro dominio.
3. Se il dominio originale richiede una pagina utilizzando JavaScript, il browser deve respingerlo perché le richieste di ajax tra domini non sono consentite (supponendo che il dominio di destinazione non lo consenta esplicitamente).

If the attacker is good enough to make me submit a form (as mentioned by OWASP) what would prevent him from getting the token before submitting?

L'unica abilità che un utente malintenzionato deve avere è la capacità di scrivere HTML e javascript e sapere a cosa assomiglia la richiesta che stanno tentando di attaccare. Queste sono tutte cose facilmente accessibili e non segrete in alcun modo.

Quindi la tua ipotesi che la possibilità di creare un modulo in qualche modo significa che possono prevedere i token casuali non è corretto.

Ogni token è univoco per un utente autenticato e, a meno che non vi sia un'altra vulnerabilità, non esiste un modo per capire che cos'è quel token.

In base a come la tua domanda è formulata non sono sicuro di avere una conoscenza completa di come funziona CSRF. Questo non è inteso come un insulto - può essere un concetto difficile da afferrare inizialmente.

Il mio suggerimento sarebbe di creare un modulo che sia vulnerabile a questo tipo di attacco e quindi di eseguire un attacco contro di esso. Questo è un modo eccellente per avere una comprensione completa di come funziona questo attacco. Una volta che lo fai, sospetto che capirai meglio questa risposta.

Cheers!

UPDATE:

Sembra che si possa presumere che CSRF e XSS siano la stessa cosa. Giusto per chiarire: in un sito con solo una vulnerabilità CSRF, un utente malintenzionato non può inserire javascript. Quindi non c'è modo di usare javascript per ottenere il token. Se un sito ha una vulnerabilità XSS, allora non è necessario eseguire un attacco CSRF, perché sarebbe molto più semplice semplicemente iniettare javascript che fa ciò che vuoi. Inoltre, un CSRF è un attacco "a senso unico", il che significa che puoi inviare una richiesta come qualcuno, ma non puoi leggere il risultato. Ha senso?

UPDATE 2:

riguardo al tuo commento:

Thanks for clarifying, I was looking at the OWASP page linked in the question, section POST scenario, the submit onload, isn't that a CSRF attack with javascript injection?

Ahh - vedo la tua confusione. No, la javascript che stanno visualizzando è sul sito controllato dall'attaccante. Quindi, se l'utente malintenzionato controlla evil.com , il javascript si troverà lì e verrà semplicemente utilizzato per avviare una richiesta HTTP su targetSite.com utilizzando una sessione esistente degli utenti. CSRF è un attacco alle sessioni esistenti che si svolge a livello di richiesta HTTP. Potrebbe usare javascript per lanciare questo attacco, ma l'attacco è ancora una richiesta HTTP.

Non sono un esperto di CSRF (per favore commenta se ho idee sbagliate), ma da wikipedia :

Under the [same-origin policy], a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number.

Un esempio semplificato è: supponiamo tu abbia 3 schede aperte nel tuo browser che hanno caricato script da tre fonti: 1.aaa.com , 2.aaa.com e www.bbb.com . Il tuo browser, in base alla stessa politica di origine (SOP), consentirà agli script di 1.aaa.com e 2.aaa.com di leggere e scrivere dati i reciproci dati. Questo è il modo in cui Facebook rimane connesso a tutte le tue schede (anche su pagine non facebook, perché gli script di Facebook incorporati sono caricati in modo dinamico da *.facebook.com , e quindi hanno la stessa origine).

Tuttavia, un browser che implementa SOP impedirà agli script di www.bbb.com di essere in grado di leggere i dati destinati agli script *.aaa.com . Ciò impedisce a uno script dannoso di vedere quel token casuale che è stato assegnato un altro script. SOP non blocca le scritture, quindi uno script dannoso può ancora inviare richieste che pretendono di essere un altro script, ma a meno che non possa indovinare il token casuale, tale richiesta verrà ignorata.

Sono d'accordo sul fatto che il sistema sia un po 'stizzito, ma funziona.

Senza il controllo token, l'utente malintenzionato non avrebbe nemmeno bisogno di per iniettare javascript.

Ad esempio, creano un modulo su link che invia a un'azione link . Invece di iniettare javascript sul sito di destinazione, possono semplicemente posizionarlo direttamente sul sito che controllano e indurti a visitarlo. La richiesta POST includerà comunque i cookie target.example. Se non controlla un token, l'invio del modulo sarà accettato come se provenisse direttamente da target.example stesso.

Tuttavia, se è presente un controllo token, evil.example non può ottenere il token a causa della politica della stessa origine. Quindi avrebbero bisogno di un'ulteriore vulnerabilità sul sito di destinazione. Ad esempio, XSS consentirebbe all'utente malintenzionato di recuperare il token tramite AJAX.