[whatwg] some thoughts on sandboxed IFRAMEs

[Adam Barth]

On Sun, Dec 13, 2009 at 11:02 AM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
>> 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.

People screw up CSRF tokens all the time.  The closing tag nonce
design has been floating around for years.  The earliest variant I
could find is Brendan's <jail> tag.

The @sandbox seems like a better fit for the advertising use case.  In
fact, many people have told me how happy they are that WebKit is
implementing @sandbox.  These folks tend to already be using iframes
to contain ads or gadgets and wish that they could turn off more
features, like frame-busting and plugins.  They're not worried about
the sandboxed content being loaded in the main frame because they're
interested in limiting the attacker's introduction to the user.  Once
the user has visited attacker.com, the issue is out of their hands.

I agree that we need something to help with content received by
cross-site XMLHttpRequest and postMessage.  For those use cases, we're
already running script, so a design like toStaticHTML seems better
than <jail>.

Adam