[whatwg] some thoughts on sandboxed IFRAMEs

[Tab Atkins Jr.]

On Fri, Dec 11, 2009 at 10:18 PM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
> 1) IFRAME semantics make it exceedingly cumbersome to sandbox short
> snippets of text, and this task is perhaps the most common and
> pressing XSS-related challenge. Unless the document is constructed on
> client side by JavaScript, sites would need to use opaque data: URLs,
> or put up with a lot of additional HTTP roundtrips, to utilize
> sandboxed IFRAMEs for this purpose. [ There is also the problem of
> formatting and positioning IFRAME content, although the seamless
> attribute would fix this. ]

I believe that the @doc attribute, discussed in the original threads
about @sandbox, will be introduced to deal with that.  It'll take
plain html as a string, avoiding the opaqueness and larger escaping
requirements of a data:// url, as the only thing you'll have to escape
is whichever quote you're using to surround the value.


> The ability to sandbox SPANs or DIVs using a token-guarded approach
> (<span sandbox="random_token"></span sandbox="same_token">) is, on the
> other hand, considerably easier on the developer, and probably has a
> very similar implementation complexity.

Nah, token-guarding is no good.  For one it's completely unusable in
the XML serialization without edits to the XML spec.  More
importantly, though, it puts a significant burden on authors to
generate unpredictable tokens.  Is this difficult?  No, of course not.
 But people *will* do it badly, copypasting a single token in all
their <iframe>s or similar.  It's pretty much guaranteed that this
will happen, and as it has no visible bad effects until an attacker
gets through, I think it'll be reasonably common.


> 1) The utility of the SOP sandboxing behavior outlined in the spec is
> diminished if we have no way to actually *enforce* that the IFRAMEd
> resource would only be rendered in such a context. If I am serving
> user-supplied, unsanitized HTML, it is obviously safe to do <iframe
> sandbox src="show.cgi?id=1234"></iframe> - but where do we prevent the
> attacker from calling http://my_site/show.cgi?id=1234 directly, and
> bypassing the filter? There are two cases where the mechanism still
> offers some protection:

You mean, if the attacker controls their own website on the same
origin and <iframe>s it for themselves?  Sure, that's no protection.
Do you *need* protection then?  They're not on your site; if they can
get visitors onto their own site, they already have tons of more
effective ways to screw with users.  Unless I'm missing something
about this attack scenario, there's really nothing here.

Do you perhaps mean that the attacker puts an <iframe> in their own
comment or whatever, producing an <iframe> inside of an <iframe
sandbox>?  The outermost @sandbox should subdue the inner <iframe>'s
power in the same way.


> It strikes me that this mechanism would make a whole lot more sense if
> supported on HTTP header level, instead: "X-SOP-Sandbox: 1"; in its
> current shape, it is defensible perhaps if aided by Mozilla's CSP.
> Otherwise, it's an error-prone detail, and we should at the very least
> outline why it's very difficult to get it right in the spec.

Again, I must admit some ignorance of the significance of this attack
scenario.  Surely if the attacker is pointing to an <iframe> in their
own code, they are either doing so within an <iframe sandbox> or are
doing so on their own site.  The former shouldn't be a problem, the
latter means that the attacker has full control over the contents
anyway, and can strip the header if they so choose.


> 2.1) The ability to disable loading of external resources (images,
> scripts, etc) in the sandboxed document. The common usage scenario is
> when you do not want the displayed document to "phone home" for
> privacy reasons, for example in a web mail system.

I agree that this would be useful, especially for images.


> 2.2) The ability to disable HTML parsing. On IFRAMEs, this can
> actually be approximated with the excommunicated <plaintext> tag, or
> with Content-Type: text/plain / data:text/plain,. On token-guarded
> SPANs or DIVs, however, it would be pretty damn useful for displaying
> text content without the need to escape &, <, >, etc. "Pure" security
> benefit is limited, but as a phishing prevention and display
> correctness measure, it makes sense.

Why not just run an escape function over the content before sending
it?  All web languages have one specifically for escaping the
html-significant characters.  There's only five of them, after all.

~TJ