[whatwg] some thoughts on sandboxed IFRAMEs

[Ian Hickson]

On Mon, 25 Jan 2010, Michal Zalewski wrote:
> > 
> > This has been proposed before. The concern is that many authors would 
> > be likely to make mistakes in their selection of "random" tokens that 
> > would lead to significant flaws in the deployment of the feature.
> >
> > srcdoc="" is less prone to errors. Only " and & characters need to be 
> > escaped. If the " character is not escaped, then a single " character 
> > in the input will cause the comment to break.
> 
> My counterargument, as stated later in the thread, is quite simple: the 
> former *forces* you to implement a security mechanism, else the 
> functionality will break. You can still use a bad token, but you are 
> required to make the effort.
> 
> In that regard, the comparison to XSRF is probably not valid; a vast 
> majority of XSRF bugs occurs not because people pick poor tokens (in 
> fact, that's really a majority), but because they don't use them at all. 
> From that perspectiv, srcdoc="..." is very similar to XSRF - people will 
> mess it up simply by not thinking about the correct escaping.

Not escaping " is so easily and quickly discovered that I really don't 
think that's a problem. The difference between that and XSRF is that in 
the XSRF case, things usually work pretty well (better than well, in fact, 
even HTML is supported!). It's only if an attacker makes use of the hole 
that the side-effect is highlighted.

The idea here is to align what is needed for correctness and what is 
needed for security, rather than having them be separate. In that way it's 
quite similar to the token idea, except I think it's far more likely to be 
done securely -- actually picking a truly unpredictable token is a 
non-trivial exercise.


> That said, I am not really arguing against srcdoc="..."; I think it's an 
> OK feature. My point is simply that I would love to see less 
> fragmentation when it comes to XSS defenses and the granularity of 
> security controls. The initial proposal of <iframe> sandboxes solved a 
> very narrow use case, and other, unrelated designs started to spring up 
> elsewhere. This wouldn't be bad by itself, but while the security 
> controls on <iframes> were pretty great (with some tweaks, such as 
> text/html-sandboxed), they would not be reflected in other APIs, which I 
> thought is unfortunate.
> 
> If we extend sandboxed iframes with srcdoc, seamless frames, 
> text/html-sandboxed, and <iframe> rendering performance improvements, it 
> actually becomes close to a comprehensive solution, and I am happy with 
> this (other than a vague feeling that we just repurposed <iframe> to be 
> some sort of a <span> ;-).

Well, it's different from <span> because it has its own browsing context 
-- which is basically exactly what <iframe> is.


> > I've introduced text/html-sandboxed for this purpose.
> 
> 1) Some other security mechanisms (CORS, anti-clickjacking controls, XSS 
> filter controls) rely on separate HTTP headers instead. Is there a 
> compelling reason not to follow that lead - or better yet, to unify all 
> security headers to conserve space?

We need something that breaks legacy UAs.


> 2) People may conceivably want to sandbox other document types (e.g., 
> SVG, RSS, or other XML-based formats rendered natively, and offering 
> scripting capabilities). Do we want to create "-sandboxed" MIME types 
> for each? The header approach would fix this, too.

If people really use XML, we can add an equivalent MIME type for XML. 
However, we should only do so if that's really required.


> >> 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.
> >
> > Good point. Should we make sandbox="" disable off-origin network 
> > requests?
> 
> That would be great. I think Adam proposed we have a separate 
> sandbox="..." toggle for this. Whether it's on or off by default 
> probably doesn't matter much.

Adam's feedback (not quoted here, but in the same thread as the e-mail to 
which this is a reply) suggests that this is actually a bad idea, so I've 
not changed this.


> >> 2.2) The ability to disable HTML parsing. [...]
> 
> One use case is a web forum or a web mail interface where you want to 
> display a message, but specifically don't want HTML formatting. Or, 
> performance permitting, the same could be used for any text-only entry 
> fields displayed on a page.

If there's no HTML, there's no need for a sandbox, so the simplest 
solution is just to escape the <s and &s. That's even easier than 
srcdoc="" (since there you have to have the <iframe>, and also have to 
escape "s).


> > Do people get CSRF right more often than simply escaping characters? 
> > It seems implausible that authors get complex cryptographic properties 
> > right more often than a simple set of substitutions, but I suppose 
> > stranger things are true on the Web.
> 
> Keep in mind that pretty much every web application already needs to 
> safely generate unique, unpredictable tokens - for session identifiers 
> that guard authenticated sessions. If they can't get it right, they are 
> hosed anyway - but problems here are not horribly common, in my 
> experience at least, and web app frameworks do a decent job of helping 
> developers by providing token-generating facilities.

Pretty much the same can be said of escaping text.

Also, based on Adam's comments, it seems that things aren't really as rosy 
as all that for token generators.


> As noted earlier, the vast majority of issues with XSS and XSRF defenses 
> is that you explicitly need to think about them, and a failure to do so 
> has no obvious side effects. From that perspective, any solution that 
> requires a security mechanism to be used is far better.

Well you can't use sandbox="" without thinking about it a little! :-)


On Mon, 25 Jan 2010, Tab Atkins Jr. wrote:
>
> Adam Barth rightfully points out that this only stops certain classes
> of data exfiltration attacks, and so probably isn't worthwhile as a
> solution to that matter.  However, I think this would also be very
> useful for general comments, to prevent, for example, shock trolls
> from putting goatse images in your comment threads.  It would also
> prevent <video> and <audio> embeds from working.
> 
> However, it would still allow the site owner to allow particular files
> to be embedded with <img>, <audio>, or <video>, if they just host them
> on their own origin and set allow-same-origin in the sandbox flags.
> This is already a relatively normal practice, but it's accomplished
> through attempts at filtering.
> 
> Note that this would also prevent resource embeds using data urls, as
> they have a unique origin.

It seems like if you want to control what markup is shown, the way to do 
that is to to parse the input and remove the elements you want to block. 
Just blocking off-domain images is a pretty poor way of blocking images if 
that's what you want to do. Consider that the commentor could just use 
<table> and <td bgcolor> to embed an "image" if that's what he wants to 
do. On many large sites, users can upload images to one part of the site 
-- those wouldn't be blocked either.


> I think it's pretty common for certain areas of a comment form, such
> as username, email, or title, to be meant as ordinary plaintext
> without any special formatting allowed.  Right now that means you have
> to run html escapes over the content, which isn't difficult.  Would it
> be appropriate to move this into sandbox as well, though, to make it
> even easier?

It wouldn't make it easier; you'd still have to escape &s and "s. (You 
just wouldn't have to escape the &s twice.)


> Sorry, the title is unclear - I mainly intend this as preventing
> <audio autoplay> and the like.  Any sort of action that could be both
> annoying and would take place without the user's consent.  This is
> inherently ill-defined, which may be a problem, but it could be
> tightened up to say precisely which features should be shut down.  It
> might need to be revised as new features get added, though.

Yeah, maybe we should do this. Are there any other than autoplay, 
autofocus, <meta refresh>, and <script>?


> Shelley Powers states that she disallows SVG in the comments on her
> blog because of the risk of someone DOSing her users by writing highly
> resource-intensive SVG.  This could be fixed in a general sense by
> having the ability to opt into very strict resource limits per iframe
> - it the limit is exceeded, the browser would simply bail and end
> processing in that iframe.  I'm not certain how practical this is from
> an engineering standpoint, however.  There's no need to set precise
> limits on this - each browser should understand the platform it's
> running on well enough to know what an 'appropriate' resource amount
> is for this sort of thing.  Phones would cut off iframes much sooner
> than a desktop, a browser might take advantage of system load
> information to dynamically alter its cutoff point, etc.

The spec already allows arbitrary limits. I dunno what else we could 
really do.


> Are there other reasonable improvements that could be made to <iframe 
> sandbox> to make it more suitable for wrapping things such as blog 
> comments?  Ideally, production-level sites with relatively normal 
> requirements should be able to use *solely* <iframe sandbox> to protect 
> their users from untrusted content.  (Though, of course, it would be 
> only a part of the site's defenses until the userbase with 
> non-supporting browsers drops low enough to ignore.)  Do others believe 
> this is an achievable goal, or conversely believe it is not?

sandbox="" is only meant as an extra defence-in-depth, it's really not 
meant as a self-contained comprehensive security mechanism.


On Mon, 25 Jan 2010, Alex Russell wrote:
> >
> > srcdoc="" is less prone to errors. Only " and & characters need to be 
> > escaped. If the " character is not escaped, then a single " character 
> > in the input will cause the comment to break. This is likely to be 
> > caught early. If the & character is not escaped, correctness and 
> > fidelity will suffer, but it will not lead to security errors.
> 
> Sorry I'm late to this discussion. Would like to add my objection to 
> using attribute string escaping as a security "feature" in any way. I 
> strongly prefer required nonces attached to opening and closing of 
> sections.

Are there any arguments that haven't been considered? Nonces have a real 
risk of not being unpredicatable enough, with a very bad failure mode (it 
only fails once you're attacked); escaping "s and &s on the other hand is 
really easy to do (two lines of code in most languages) and fails in the 
common case, so it's easy to test.


On Mon, 25 Jan 2010, Alex Russell wrote:
>
> AFAICT, the objections fall into several buckets:
> 
>   1.) Users might pick badly or may re-use nonces when they shouldn't.
>   2.) Escaping " is believed to be more secure because it's likely to
> break more often, raising developer awareness
>   3.) The fix to correct escaping problems is believed to be more reliable
> 
> I'm interested in 2 and 3. Users will do dumb things, and both 2 and 3
> assumes a similar baseline scenario as 1; a developer did something
> dumb. Nonces need not be cryptographically strong for most apps, so
> the big problem is re-use. UA's have broad leeway here to prevent
> re-use on origins and deny sandboxing to containers that re-use the
> same nonces on a single page. They can even help by keeping a list of
> recently used nonces and denying reuse.

Could you elaborate on how one could avoid reuse? That seems like a bad 
idea, since it would prevent any non-client caching mechanism from 
working. The problem is not nonce re-use, it's that the token has to be 
either unpredictable or unspoofable. (It could be predictable and 
unspoofable if it was constructed using a diagonal of the user's text.)


> What concerns me about the " escaping option is that it's harder to
> implement by default.

Quote escaping is not harder to implement than unpredictable token 
creation in any language I've used recently. Could you elaborate on why 
you think it is?


> [...] Getting users to use -- and then secure -- such a container seems 
> to me to be significantly easier sell if the opening discussion doesn't 
> begin with "first, take your document fragment and do the moral 
> equiavlent of base64 encoding".

> In fact, I'd argue that base64 with a length header might be a simpler 
> and easier way to handle arbitrary content in attributes. Violations of 
> the length would make parsing problems even more visible than in the 
> escaped " case while the default amount of work to do it right would 
> remain unchanged.

> If the security of the system depends on users correctly pre-processing 
> their content, then I'd like to suggest that we should be more explicit 
> about it and not accept the "-escaping half measure.

> The other option (which I favor) is to not pretend that we can have it 
> both ways and give users who explictly opt into security features enough 
> credit to have thought about their use for even a moment.

I don't follow any of the above points.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'