[whatwg] Comments on @sandbox

[Adam Barth]

As some of you know, WebKit is reviewing a patch to add the sandbox
attribute to frames, as specced in HTML5.  I'm hoping this will
motivate various folks to review @sandbox and give their feedback.

== allow-same-origin + allow-script ==

It's clear that adding both allow-same-origin and allow-script to
@sandbox at the same time make the sandbox useless because the
sandboxed content can simply reach outside the frame and remove the
sandbox attribute.  Should we disallow setting these values at the
same time?  If an author does set both, maybe we should only pay
attention to one?

== Mutability ==

One interesting feature of @sandbox is that the hosting page can
change the value of the sandbox attribute.  Even though it's clear
that having both allow-same-origin and allow-script at the *same* time
lets the sandboxed content escape, it's probably less clear to folks
that first setting allow-same-origin and then removing it and adding
allow-script is also very dangerous.

The reason is slightly subtle.  Essentially, when the frame is in the
allow-same-origin mode, it is very easy for the outer document to leak
a JavaScript object into the DOM of the inner document.  Then, when
the frame enters the allow-script phase, the document can abuse the
leaked object to XSS the outer page, as described in
http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf>.

The reverse sequence is also dangerous because the inner page could
use the techniques in this paper
<http://www.adambarth.com/papers/2009/adida-barth-jackson.pdf> to
build a fake DOM during the allow-scripts phase and confuse the outer
page into XSSing itself in the allow-same-origin phase.

To avoid these subtle traps for developers, I recommend to freezing
the privileges of a sandboxed document at the time the document is
loaded into the frame.

== X-Sandbox ==

If a page contains a sandboxed frame, the document contained in the
frame is only sandboxed because the user encountered the document via
the frame.  If the use encounters the same document directly (e.g., in
a top-level browsing context), then the document will not be
sandboxed.

I recommend letting servers deliver the sandbox policy both via the
sandbox attribute and via an HTTP header.  The value of the HTTP
header approach is that the document will be sandboxed in whatever
context the user agent loads the document.  For various esoteric
reasons, I wrote up a description of how this might work on Mozilla's
Wiki: <https://wiki.mozilla.org/Security/CSP/Sandbox>.

In general, I think @sandbox is a useful primitive and I'm glad to see
browser vendors starting to adopt it.

Adam