metodi CSRF: img vs iframe vs form / javascript

Question

metodi CSRF: img vs iframe vs form / javascript

#1 da (1 voti)
#2 da (1 voti)

2

Ho delle domande sui metodi per eseguire CSRF. Ho fatto la lezione di bypass del CSRF in WebGoat (Lessons - > Cross-site Scripting - > By-pass prompt CSRF). La lezione richiede di creare un messaggio e-mail che invia due richieste malevoli a un'app Web a cui il destinatario ha effettuato l'accesso. La prima richiesta imposta un importo di trasferimento di denaro. Il secondo è una richiesta di conferma inviata quando l'utente fa clic su "conferma" su una pagina di conferma.

Ho risolto l'attività utilizzando il codice JavaScript che invia le richieste come richieste HTTP Post. Suppongo che un'altra opzione potrebbe utilizzare moduli e JavaScript per inviare automaticamente i moduli.

La mia domanda è: perché la maggior parte delle persone sembra risolvere la lezione usando i tag img o iframe con src impostato sull'URL di destinazione con i parametri necessari? Mi aspetto che venga effettuato un trasferimento di denaro usando Richieste POST HTTP, non GET. C'è un aspetto che renderebbe l'utilizzo del codice JavaScript o forma un metodo non valido o problematico per CSRF? C'è una differenza pratica rispetto ai compiti sopra citati? Credo che l'autorizzazione non lo è perché puoi avere i cookie inviati al recupero di JavaScript e al momento dell'invio di un modulo.

xss csrf webgoat

posta hubbabubba 17.12.2018 - 10:16

fonte

2 risposte

Leggi altre domande sui tag xss csrf webgoat

Cosa devo fare per sviluppare una nota sicura con l'app in Android 8.0? Quanto è sicuro consentire l'accesso SSH basato su chiave all'interno della LAN?

score 1 · Answer 1

Posso pensare a due motivi principali per cui si potrebbe preferire l'utilizzo di img e iframe su una prova di concetto JavaScript per lo scenario che hai descritto sopra.

C'è questa mentalità comune che vedo tra i membri dell'industria della sicurezza che la semplicità è la chiave quando si tratta di costruire una dimostrazione di concetti. Incontrerai spesso persone che cercano di costruire i payload più brevi per sfruttare problemi specifici. Sulla base dell'esperienza personale, la tua dimostrazione di concetti tende ad essere più facile da capire e da condividere con altri ricercatori di sicurezza (questo non è sempre il caso però come vediamo con i poliglotti XSS [1] ). Inoltre, è anche divertente provare a ridurre il payload (vedi " Code golf ").
Quando si tratta di sfruttare il problema, un avversario probabilmente vorrà coprire quanti più casi limite. Alcuni utenti disabilitano JavaScript nel loro browser che renderebbe il tuo exploit innocuo. Un exploit non basato su JS risolverebbe questo potenziale problema.

score 1 · Answer 2

I motivi per cui le persone usano questi tag invece di usare JavaScript, IMO, sono:
- Esempi di primi articoli / pubblicazioni
- Applicazioni che consentono agli utenti di pubblicare immagini / iframe (BBCode, Markdown, ecc.) - HTML puro e amp; facilità di dimostrazione

Gli esempi precedenti utilizzavano tag img o iframe perché JavaScript XHR non erano già disponibili e probabilmente non tutti i browser consentirebbero l'esecuzione di script. E a causa delle differenze di implementazione nei browser, gli script potrebbero essere stati suddivisi facilmente.
In secondo luogo, non è raro trovare applicazioni che consentano agli utenti di pubblicare immagini tramite tag Markg o HTML img. Tuttavia, non consentono alcun snippet o gestore di eventi JavaScript. Questi sono già stati utilizzati per raggiungere un pubblico più vasto in passato.
In terzo luogo, non richiede l'inserimento di JavaScript o il blocco di NoScript o simili. È breve e facile dimostrare l'attacco.

Questi sono solo i miei ragionamenti. La vera ragione potrebbe essere diversa e potrebbe entrare in conflitto con la mia. Apprezzerei qualsiasi correzione.