[whatwg] some thoughts on sandboxed IFRAMEs

[Michal Zalewski]

> 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.

That doesn't strike me as a robust way to prevent XSS - the primary
reason why we need sandboxing to begin with is that people have a
difficulty properly parsing, serializing, or escaping HTML; so
replacing this with a mechanism that still requires escaping is
perhaps suboptimal.

> Nah, token-guarding is no good.  For one it's completely unusable in
> the XML serialization without edits to the XML spec.

This seems valid.

> 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.

People already  need to do this well for XSRF defenses to work, and
I'd wager it's a much simpler and better-defined problem than
real-world HTML parsing and escaping could realistically be. It is
also very easy to delegate this task to existing functions in common
web frameworks.

Also, a single token on a returned page, as long as it's unpredictable
across user sessions, should not be a significant issue.

>> 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?

The specific scenario given in the spec is:

<p>We're not scared of you! Here is your content, unedited:</p>
<iframe sandbox src="getusercontent.cgi?id=12193"></iframe>

Let's say this is on example.com. What prevents evil.com from calling
http://example.com/getusercontent.cgi?id=12193 in an IFRAME? Assuming
that the author of evil.com is also the author of example.com "user
content 12193", this renders all the benefits of using sandboxed
frames on example.com moot.

The only two cases where this threat is mitigated is when non-SOP
domains are used to serve user content (but in this case, if you're
doing it right, you don't really need iframe sandboxes that much); or
if id= is unpredictable (which in your own words, people are going to
mess up). And neither of these seem to be the case for the example
given.

>> 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.

Well, indeed =) But xssed.com has 61,000 data points to the contrary.
The easier we make it for people to achieve exactly the result they
want, whilst avoiding security issues, the better. One of the common
tasks they fail at is rendering limited (neutered) HTML without any JS
in. This is not an unsolved task - quite a few implementations exist
to do it pretty well - but they still fail. The other, arguably more
common task - and the most common source of XSS flaws - is to display
user input without any HTML at all. So this fits in nicely, even if
simple to implement by other means.

/mz