[whatwg] some thoughts on sandboxed IFRAMEs

[Tab Atkins Jr.]

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

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

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

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

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

~TJ