[whatwg] some thoughts on sandboxed IFRAMEs

Michal Zalewski brings up several good suggestions for improvements to
@sandbox that would make it more useful for embedding general
untrusted user content.  As well, Shelley Powers brought up a few
common uses that I think could fit into this model and prove useful.

1) Prevent cross-origin resource loads
--------------------------------------
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.

2) Prevent all HTML parsing (rendering as text/plain)
-----------------------------------------------------
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?

3) Prevent no-input actions
---------------------------
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.

4) Stricter resource limits
---------------------------
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.


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?

~TJ

Received on Monday, 25 January 2010 12:52:28 UTC