<iframe@sandbox> does more than expected.

Hi everybody, I hope anyone can help me understanding more.
This is what the spec says about @sandbox. It seems strange.
Note: I tend to be verbose. So, here's a summary for my request:
 - it is not logical to state that sandbox is removed when scripts and
same-origin policy are allowed
 - sandbox cannot be removed allowing everything, because sandboxed
content has no access to plugins, until the attribute is forcibly
removed.

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."
(http://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-sandbox)

Even not taking into account any other aspect of the possible
attributes, this looks a bit restrictive. Sandboxed content, even with
allow-scripts and allow-same-origin, misses some points in order to be
100% de-sandboxed. 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. (Latest
versions of Chrome/Opera/Firefox; IE doesn't even allow to navigate
those links in a new tab when right-clicking on them.) And I suppose
it can't even allow sending forms. So what does it mean that those 2
values alone effectively break out of the sandbox?

But there is more.
This not only accords with specs, but also with my personal experience
with Chrome (I could work it around in my project, so I didn't check
other UAs, but I suppose it's the same). Again from the spec:

"When the attribute is set, the content is treated as being from a
unique origin, forms, scripts, and various potentially annoying APIs
are disabled, links are prevented from targeting other browsing
contexts, and plugins are secured."
"The allow-same-origin keyword causes the content to be treated as
being from its real origin instead of forcing it into a unique origin;
the allow-top-navigation keyword allows the content to navigate its
top-level browsing context; and the allow-forms, allow-pointer-lock,
allow-popups and allow-scripts keywords re-enable forms, the pointer
lock API, popups, and scripts respectively. "
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: plugins. Those are always secured when
sandboxing.

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. Please help me solve this. It is important.
Thank you (for patience too).
Andrea

Received on Thursday, 13 November 2014 02:44:38 UTC