maty Reporter
	Description • 11 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36

Steps to reproduce:

When a page hosts a sandboxed-iframe with allow-same-origin and allow-scripts tags, the hosted frame can access its parent's dom, locate itself (the iframe) and add the allow-top-navigation capability, followed by parent navigation.
Although this is specifically forbidden by the RFC, both chrome and IE protect against that. Namely, although they do add that capability, the actual browsing fails.
The following code on Firefox redirects the parent to google. On IE and Chrome it raises a security exception.
Many site give their 3rd party code the allow-script and same-origin capabilities, like office365 extensions.

Parent.html:
<iframe id="myframe" sandbox="allow-same-origin allow-scripts" src="children.html"/>

Children.html:
<script>
parent.document.getElementById("myframe").sandbox="allow-script allow-top-navigation allow-same-origin";
parent.document.location = "http://www.google.com";
</script>


Actual results:

The code browses to google


Expected results:

Well, this is not described by the RFC, but since IE and chrome treat it as a security issue, you might to do so as well...

	maty Reporter
	Comment 1 • 11 years ago

sentence editing:
Although this is *NOT* specifically forbidden by the RFC, both chrome and IE protect against that. Namely, although they do add that capability, the actual browsing fails.

	maty Reporter
	Comment 2 • 11 years ago

Related to #785310

	Ian Melven :imelven
	Comment 3 • 11 years ago

What RFC are you talking about ?

The WHATWG spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element) specifically calls out this case :

Setting both the allow-scripts and allow-same-origin keywords together when the embedded page has the same origin as the page containing the iframe allows the embedded page to simply remove the sandbox attribute and then reload itself, effectively breaking out of the sandbox altogether.

The flags aren't supposed to take effect until the navigation happens - so I wonder if you are hitting bug 785310. It looks like you are using Firefox 26 to test - can you try in Nightly ? 785310 was fixed in Firefox 29, it looks like.

	Al Billings [:abillings - ex-MoCo]
	Comment 4 • 11 years ago

Can you propose a security rating here?

	Ian Melven :imelven
	Comment 5 • 11 years ago

(In reply to Al Billings [:abillings] from comment #4)
> Can you propose a security rating here?

If this is a dupe of 785310, that's a sec-low. If it's not, it's probably still a sec-low since it's essentially the same issue - top navigation shouldn't be allowed and is. I don't have time to test to see if this is fixed in Nightly right now.

	Bob Owen (:bobowen)
	Comment 6 • 11 years ago

The navigation would currently be allowed even without the adding of allow-top-navigation.
This is fixed by bug 785310.

However with allow-same-origin allow-scripts, you could add allow-top-navigation or remove the sandbox completely and then reload yourself within the iframe and the navigation would work.
You have to reload because the change to the sandbox attribute doesn't affect the document within the sandbox until it is navigated.

This is a limitation of sandboxing and would work in IE and chrome as well.