2

Consider a user that has an open session to a legitimate site with a password on it. This page has no anti-CSRF token.

A hacker creates a webpage with 2 hidden iframes. 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.

Via phishing attack, the hacker entices user with open session to click on the link for his webpage having these 2 iframes and steals the password.

Is this attack possible?

  • How is the http get to the attacker's web service generated? If the IFrames are hidden, what does the victim see when they arrive at the attacker's website? In any case, the attacker's web page would not be able to read anything the victim types in to the legitimate web page, so "sends this password via html5" would not work. – mcgyver5 Apr 14 '15 at 18:39
  • Well, it would just be a GET via AJAX, perhaps called when page loads, which parses the webpage for the password and sends it to the 2nd iframe which in turn sends pwd somewhere else. Maybe the victim sees nothing and, in the end, the whole document window just gets redirected back to the website. – Jason Weden Apr 15 '15 at 11:23
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 is done with Javascript. This means one can not force a postMessage with just a CSRF attack unless the victim page is explicitly designed in a way, that arbitrary postMessage calls to cross-origin pages can be triggered by a simple POST or GET request. Instead the attacker would need the ability to inject script to trigger a postMessage, i.e. it needs Cross-Site-Scripting (XSS). But if XSS is possible there is usually no need to make it overly complex by using postMessage.

| improve this answer | |
  • Thanks for the reply. I was thinking the javascript functions containing the GETs and postMessage() could be triggered automatically on page load requiring no action on part of user(victim). – Jason Weden Apr 15 '15 at 11:58
0

No - window.postMessage triggers a JavaScript event, not a HTTP request.

The target window needs to be listening for the message. As noted on 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.

Therefore, this is not a design flaw with postMessage - there are however some past implementation flaws with postMessage, like this one 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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.