Re: <iframe@sandbox> does more than expected.

On 11/12/14, 9:44 PM, Andrea Rendine wrote:
> Content:
> "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."

This is just a note warning people about the danger of using both 
allow-scripts and allow-same-origin, correct?

> Even not taking into account any other aspect of the possible
> attributes, this looks a bit restrictive.

Restrictive in what sense?  This is just describing what the behavior is 
if you set both those keywords at the same time.

> Sandboxed content, even with
> allow-scripts and allow-same-origin, misses some points in order to be
> 100% de-sandboxed.

Sure.  The point is that allow-scripts + allow-same-origin gives the 
sandboxed page enough permissions to modify the DOM of its parent, which 
means it can removeAttribute("sandbox") and then reload itself.  And if 
it does that, then it's not sandboxed at all.

> I tested it on a project of mine. A page inside an
> iframe, even from the same origin cannot open new tabs or navigate its
> top-level browing context when those attribute values are set, but
> allow-top-navigation and allow-popups are not specified.

Sure.  The point is that it can escape from those restrictions if it 
wants to.

> So what does it mean that those 2
> values alone effectively break out of the sandbox?

See above.

> I checked the relatively scarce literature around, but it confirmed
> what I thought. Even allowing whatever can be allowed, there's
> something that, once sandboxed, can be restored only by removing the
> attribute completely

The point is that if you have allow-scripts and allow-same-origin and 
are loaded from the same origin, you can remove the attribute completely.

> Either the implementation were more careful about security than spec
> authors, or specs simply state something that is at best confusing and
> at worst wrong.

Let's say "confusing", since you clearly got confused.  How would you 
prefer this were stated?

-Boris

Received on Thursday, 13 November 2014 02:58:26 UTC