Iframe frode postmessage

Question

Iframe frode postmessage

#1 da (1 voti)

1

Ho esaminato del materiale qui e in altri siti relativi all'utilizzo sicuro di Window.postMessage. C'è un sacco di materiale riguardante le migliori pratiche, ma una delle mie domande è rimasta senza risposta.

Da ciò che sono stato in grado di capire, le informazioni vengono scambiate tra gli iframe utilizzando le API del browser interno, senza alcuna comunicazione di rete. In altre parole, anche se i due iframe che scambiano informazioni tra di loro sono ospitati in due server diversi provenienti da due domini diversi, non vedrò alcun traffico scambiato tra questi due server quando i messaggi vengono pubblicati. Prima di implementarlo sul mio sito web, voglio solo essere sicuro - In che modo il browser convalida l'origine del messaggio inviato? C'è un modo in cui un utente malintenzionato può "falsificare" un messaggio e farlo apparire come se fosse originato da un iframe legittimo? Immagino che la risposta sia no perché ciò richiederebbe il reverse engineering del browser e l'esposizione delle sue API interne, ma voglio solo assicurarmi che la mia comprensione sia corretta.

Grazie in anticipo

web-application appsec crossdomain html-5

posta user3074662 21.12.2014 - 21:25

fonte

1 risposta

Leggi altre domande sui tag web-application appsec crossdomain html-5

Adeguata prevenzione degli attacchi brute force distribuiti? ARP - inoltro o rilascio con IPtables

score 1 · Accepted Answer

Se origin è stato spoofed in questo contesto, questo sarebbe dovuto a un difetto nel particolare browser che era stato sfruttato. Ci sono stati tali difetti in passato, come questo su Safari .

Quindi, supponendo che l'utente stia utilizzando un browser completamente aggiornato e non esistano difetti di giorno zero (!), allora il metodo di verifica di origin non può essere falsificato nel browser quando si ricevono% eventi dipostMessage.

Alla fine della giornata devi essere sicuro che il browser si sta comportando come previsto per mantenere la fine della sicurezza lato client. Sì, un utente malintenzionato potrebbe causare il contraffazione del origin del suo browser, tuttavia se non possono attaccare altri utenti o il tuo sistema in questo modo e potrebbero attaccare se stessi, si dovrebbe essere al sicuro. Ovviamente non si dovrebbe usare il valore origin per verificare cose in cui un utente malintenzionato può avvantaggiarsi spoofandolo: si dovrebbe usare questo valore solo per verificare che una sessione utente non venga attaccata e non come mezzo di convalida le azioni dell'utente. Questa è la stessa ragione per cui non dovresti avere la convalida sul lato client solo per i webform, poiché l'utente stesso può ignorarlo.

Per riassumere, nel tuo scenario dovresti essere in grado di fidarti del origin dell'evento postMessage .