0

I know of a website, lets call it website.com, that has these vulnerabilities:

  1. iframe injection: I can inject an iframe with a src attribute, but cannot inject any script directly. Lets say that this is on website.com/iframeinjection.

  2. uncontrolled redirect vulnerability: website.com/link?path=google.com redirects to google.com.

Chaining these two vulnerabilities together, I used the iframe injection to insert something like this on website.com/iframeinjection:

<iframe src="website.com/link?path=evil.com/index.html"></iframe>

This bypasses the same origin policy, since the base-url is website.com, and this script from evil.com/index.html is executed in website.com/iframeinjection: 

<!DOCTYPE html>
<html>
<head></head>
<body>
  <script>
    alert(1);
    alert(document.cookie);
  </script
</body>
</html>

When visiting website.com/iframeinjection though, the alert(1) alerts 1, as usual, but the alert(document.cookie) cannot access the cookie from website.com even though the javascript is being executed on the outside of the iframe. Why is this? Is this a legitimate vulnerability? Is there any way this could be used to steal cookies?

Improve this question
1
  • @RaymondNijland Thanks for the clarification. How would a vulnerability like this help in a session riding attack if CSRF tokens are used?
    – Michael Hoefler
    Aug 25, 2019 at 18:22

1 Answer 1

Reset to default
4

This bypasses the same origin policy, since the base-url is website.com, and script from evil.com is executed in website.com/iframeinjection.

This is not correct. The open redirect vulnerability means that website.com redirects to evil.com. That means that the origin changes. The script is hosted on evil.com, and that is also the origin it will run in. So you are trying to read cookies from evil.com and not website.com. If you don't believe me, do what tim suggests in the comments: Add an alert(document.location) and you'll see where you are.

This does not mean there is no vulnerability here, though. Open redirects are bad in and of themself. Not sure exactly how the "iframe injection" works, but maybe that is exploitable too, but not in this particular way.

At the very least, it would be easy to do some sort of impersonation attack with the iframe, e.g. tricking a visitor into entering their password on evil.com.

Improve this answer
5
  • So is this not a true vulnerability then? The script IS executed in the website.com window...
    – Michael Hoefler
    Aug 25, 2019 at 0:57
  • 1
    @MichaelHoefler See my edit. Perhaps not the clearest answer to the question, sorry.
    – Anders
    Aug 25, 2019 at 1:01
  • 2
    @MichaelHoefler You can use alert(document.location) to see which origin the script is executed on. For your example, it will say evil.com. For an iframe, not the origin of the framing site matters, but the origin of the framed site (the redirect doesn't change this).
    – tim
    Aug 25, 2019 at 9:39
  • @tim Since there is js execution in the page though, is there any way to add an element to website.com from evil.com, (like an image tag), that leaks the cookies (or is that still breaking the SOP)? Is it normal that the js is executing in the top window? Does that have anything to do with the redirect?
    – Michael Hoefler
    Aug 25, 2019 at 13:36
  • 1
    @MichaelHoefler If you can somehow insert (XSS) or upload JS to website.com, you can leak the cookie. But that would a completely different expoit that has nothing to do with your redirect of iframe issue.
    – Anders
    Aug 25, 2019 at 13:58

You must log in to answer this question.

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