È possibile utilizzare postMessage per inoltrare i dati agli iframe degli hacker nell'attacco CSRF?

Question

È possibile utilizzare postMessage per inoltrare i dati agli iframe degli hacker nell'attacco CSRF?

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

2

Considera un utente che ha una sessione aperta su un sito legittimo con una password. Questa pagina non ha token anti-CSRF.

Un hacker crea una pagina web con 2 iframe nascosti. Un iframe esegue un GET sulla pagina con la password e invia questa password tramite html5 windows.postMessage () a un altro iframe (che identifica il sito dell'aggressore) che accetta questa password e la invia al sito dell'hacker tramite un parametro di query in un http accedi al servizio web di un hacker.

Tramite un attacco di phishing, l'hacker attira l'utente con la sessione aperta per fare clic sul link della sua pagina web con questi 2 iframe e ruba la password.

Questo attacco è possibile?

csrf same-origin-policy html-5

posta Jason Weden 14.04.2015 - 18:31

fonte

2 risposte

Leggi altre domande sui tag csrf same-origin-policy html-5

Testamento digitale È sicuro registrare più applicazioni con Facebook?

score 1 · Answer 1

One iframe does a GET on the page with the password and sends this password via html5 windows.postMessage() to another iframe (sourcing the attacker's site) which takes this password and sends it off to the hacker's site via a query parameter in an http get to a hacker's web service.

postMessage è fatto con Javascript. Ciò significa che non è possibile forzare un messaggio post con un solo attacco CSRF a meno che la pagina della vittima non sia progettata in modo esplicito, che le chiamate arbitrarie postMessage alle pagine di origine incrociata possano essere attivate da una semplice richiesta POST o GET. Invece l'aggressore avrebbe bisogno della capacità di iniettare script per attivare un messaggio post, cioè necessita di Cross-Site-Scripting (XSS). Ma se XSS è possibile, di solito non è necessario renderlo eccessivamente complesso usando postMessage.

score 0 · Answer 2

No - window.postMessage attiva un evento JavaScript, non un HTTP richiesta.

La finestra di destinazione deve essere in ascolto per il messaggio. Come indicato su MDN:

If you do not expect to receive messages from other sites, do not add any event listeners for message events. This is a completely foolproof way to avoid security problems.

If you do expect to receive messages from other sites, always verify the sender's identity using the origin.

Pertanto, questo non è un difetto di progettazione con postMessage - ci sono tuttavia alcuni difetti di implementazione con postMessage , come questo in WebKit :

If an HTML document contains a tag, the value of its href attribute overwrites the value of document.documentURI. This is inconsistent with the other two browsers that implement documentURI, Firefox and Opera. Also, JavaScript should not be able to overwrite the value of document.documentURI.

This bug has some security consequences. For example, an attacker can set the uri parameter of postMessage to an arbitrary URI, defeating any security checks using uri. The uri parameter is important for distinguishing between HTTP and HTTPS as well as determining whether the sender's host is different from its document.domain value.