[whatwg] some thoughts on sandboxed IFRAMEs

[Ian Hickson]

On Thu, 4 Feb 2010, Tab Atkins Jr. wrote:
> On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson <ian at hixie.ch> wrote:
> > 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.
> 
> Heh, if someone goes to the trouble of constructing a pixelmap out of a 
> table, they deserve to have it up until I find it and delete it. Note as 
> well that this sort of thing wouldn't be stopped by the suggested "parse 
> and sanitize" method either, unless you just want to strip *all* tables.  
> And pretty much all other HTML (using div/span with display:table-* 
> would accomplish the same thing, or just putting explicit heights/widths 
> on them to make the 'cells' line up.)

Indeed. If you want to block any of these things, you're much better off 
doing real filtering rather than relying on coarse feature blocking or 
cross-site blocking in the sandboxing feature, IMHO.


> > On many large sites, users can upload images to one part of the site 
> > -- those wouldn't be blocked either.
> 
> That's the point - one wouldn't want those blocked (or if one did, one 
> could indeed filter all images out).  They can perhaps be more subject 
> to moderation (submit the image, and have to wait for it to be approved 
> before you can use it), or just be a built-in set of images that you're 
> allowed to use, like the large sets of smilies that most forums have.

This use case is seeming very obscure for a first version of the feature. 
Are there sites that try to do this today?


> >> 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>?
> 
> That's all I can think of from a quick scan of the list of elements.

I've blocked those.


> >> 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.
> 
> Eh, once we can rely on it being implemented, it seems like it *could* 
> be a fairly self-contained security mechanism.  At the very least, it 
> could shut down the most worrying of attacks, and allow manual 
> moderation to take care of the rest.  Filling in a last few holes would 
> finish this out.

You're always going to need things like the text/html-sandboxed type, 
etc, as far as I can tell.


> >> 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.
> 
> Allows them, yes, but browsers often don't cut things off as quickly as 
> one would like, likely out of a reasonable thought that authors know 
> roughly what they're doing, and blocking something big would stop too 
> many legitimate resource-heavy usecases.
> 
> This is intended to give browsers an indication that, yes, they really 
> *should* cut things off early, and it won't screw up my page to do so. 
> It's similar in spirit to the @autobuffer attribute, in that it gives a 
> suggestion to the browser about what to do, even though the browser is 
> allowed to decide either way on its own, because it can degrade user 
> experience if the browser makes the wrong choice.
> 
> (I'm not sure, though, how feasible this would be, technically.  I'll 
> ask around a bit.)

This is not an area I feel we can easily set limits for. I don't know what 
we would set the limit on, to start with. So it seems like something that 
will have to remain UA-specific. Naturally UAs can be more aggressive in 
sandboxed iframes.


On Thu, 4 Feb 2010, Michal Zalewski wrote:
> >
> > Not escaping " is so easily and quickly discovered that I really don't 
> > think that's a problem.
> 
> The same argument could be made for not escaping <, but I don't think 
> it's valid in practice - particularly for (hypothetically) constrained 
> input fields.

No, not escaping "<" leads to the page appearing to have extra features, 
generally without breakage. Not escaping '"' in this context is much more 
severe in its effect.


> >> 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.
> 
> There are obvious, existing usage cases where sites struggle to prevent 
> automated resource loading across domains - e.g., almost every 
> HTML-supporting mail client; so it strikes me that if we go along with 
> this reasoning because a perfect solution may not exist, we're also 
> effectively saying that what they are doing should not be attempted at 
> all

That's probably not an unreasonable position.


> (then what's the alternative? one should probably be a part of HTML5).

text/plain e-mail?


> > If there's no HTML, there's no need for a sandbox, so the simplest 
> > solution is just to escape the <s and &s.
> 
> Which people fail at, big time. There are 50,000+ entries on xssed.com, 
> many of them against big sites presumably developed by skilled 
> developers with the help of sophisticated frameworks - microsoft.com, 
> google.com, amazon.com, ebay.com, etc. It is a really low-effort tweak 
> to accommodate it here, and it may offer a very significant security 
> benefit, so...?

Using <iframe sandbox srcdoc=""> is more complicated than just escaping <s 
and &s. If the author can't do the latter for plain-text content, then the 
former isn't going to solve the problem, regardless of what we provide.


> >> 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.
> 
> I think the difference is huge; in a typical web framework, you need to 
> explicitly escape every single piece of potentially dangerous 
> attacker-controlled input to stay safe - and because people tend to do 
> some validation at input stage, it's very difficult to audit for it. 
> Escaping also needs to be very different depending on the context (URLs 
> need to be encoded differently than HTML parameters, and differently 
> than standalone text).
> 
> So even though your framework may provide several escape() functions, 
> it's very easy to get it wrong, and people constantly do. OTOH, if your 
> framework provides a get_token() function, there's really not that much 
> to using it properly.
> 
> I'm coming from a background of doing lots of security reviews for 
> existing applications, so while I appreciate that the difference may be 
> subtle, the real-world error patterns speak to me pretty strongly; and I 
> do think that insufficient escaping is drastically more common than 
> used, but insufficiently unpredictable XSRF tokens.

I think that assuming that frameworks get the crypto for tokens right is 
optimistic. In practice, it's very hard to get this kind of thing right. 
Escaping, however, is trivial to get right, and is (in the case of <iframe 
sandbox srcdoc>) quick to fail if done wrong, since it'll fail quite badly 
if anyone uses a quote mark.

That's not to say that people won't screw this up too; I have no doubt 
they will. But they can fix it far more easily than a token approach, and 
one can review it for correctness far more easily than a token approach.


On Thu, 4 Feb 2010, Aryeh Gregor wrote:
> On Thu, Feb 4, 2010 at 12:44 PM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
> > The same argument could be made for not escaping <, but I don't think 
> > it's valid in practice - particularly for (hypothetically) constrained 
> > input fields.
> 
> The use-cases for srcdoc are only where you expect HTML input.  HTML 
> input is very likely to contain " or '.  By contrast, ordinary XSS 
> usually occurs when < is unlikely to occur in legitimate input, so you 
> won't spot it right away -- as you say, constrained input fields.  Why 
> would anyone, even someone who's extremely confused and/or ignorant, 
> even *attempt* to use srcdoc to contain anything other than HTML?

Indeed.


On Fri, 5 Feb 2010, Kornel Lesinski wrote:
> 
> The problem comes from lack of escaping of any kind, so change in 
> escaping method will not fix the problem, i.e.,
> 
> Hello $unescaped_name
> 
> is as vulnerable as:
> 
> Hello <iframe sandbox srcdoc="$unescaped_name">

Indeed. The latter is a whole lot harder to get right, too, because of 
styling.


On Fri, 5 Feb 2010, Philip Taylor wrote:
> On Thu, Feb 4, 2010 at 11:12 AM, Ian Hickson <ian at hixie.ch> wrote:
> > 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.)
> 
> Seems like it should be easy to get secure tokens by doing:
> 
>   $token = sha512_hex($input);
>   print "<sandbox token=$token>$input</sandbox token=$token>";
> 
> (or whatever the sandbox syntax is), so there's no need to worry about
> cryptographically secure RNGs or nonces or reuse or caching problems.
> Is this what you meant by "a diagonal of the user's text"?

Is it possible to generate a string "$a$b$c" where

   sha512_hex("$a$b$c") == $b

...given that $c can contain a completely arbitrary string? Is that easier 
to do than most attacks on hash functions? I honestly have no idea.

I do know how to review the safety of escaping a string.

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