HTML5 Sandbox - a bad idea

I'll venture that this is overblown.

Homokov is saying, HTML5 sandbox frames (which allow you to render subsets of a page with JS disabled) break security features that require JS, most notably the framebusters that some sites use to prevent Clickjacking (CJ).†

But, most sites don't protect against CJ at all.

Of the sites that do, as many use XFO (the HTTP Header that denies reframing) as use JS framebusters.

Meanwhile, JS framebusters are extremely fraught. Rydstedt &al published a really good paper†† back in '10 about this. Most JS framebusters don't work in the first place.

For 99.9% of sites, JS is an unsound place from which to defend against Clickjacking. Most sites can either safely be reframed as designed, or (vastly more likely) are never intended to be rendered in frames. For the same reason that we don't call out to JS to require HTTPS but rather use HSTS, XFO is right way to block CJ.

The problem with XFO was browser support. But that's a red herring in this case; what browser supports H5 Sandboxes but not XFO?

Apart from a possible incompatibility with a bad compat hack for XFO, what is the problem with sandbox frames? You'd want an answer to that, because otherwise, they address an extremely common, extremely painful problem for developers: accepting rich content, either from users or third parties, and rendering them on a page without losing control of Javascript.

We have much more to fear from sites that can't get output filtering or rich text right than we do from all of CJ on any site, I think. CJ is an inherently less scary problem than XSS.

Finally, if the feature isn't going anywhere (this issue came up during H5 standardization, and the reaction on Hixie's list seemed more or less to be, "pfft"), isn't it a waste of our time to be "considering it harmful"? Oughtn't we just encourage everyone to set XFO, instead?

It is very possible that I'm wrong about this; I'd just like to know how, if so.

† If you weren't aware: Clickjacking is when an attacker reframes your site "underneath" theirs, which then presents an interface to victims that when clicked passes events to your site; the net effect is similar to but more cumbersome than CSRF.

†† http://crypto.stanford.edu/~dabo/pubs/abstracts/framebust.ht...

In fact I didn't want this to be on the front page, because the topic is specific/argueable.

Anyway I like people telling me I'm wrong, and enjoy conversations with them.

The circumstances under which a clickjacking attack could be introduced to an otherwise secure site are quite narrow:

  1. Attacked site use Javascript anti-framing protection 
     (otherwise there is no benefit to the attacker in 
     disabling Javascript).

  2. Attacked site doesn't use X-Frame-Options to prevent 
     framing (probably rare for the bigger sites these 
     days).

  3. Attacked site allows the functionality under attack to 
     work even when Javascript is turned off. Many common 
     clickjack targets (e.g. Facebook Like buttons) don't 
     work at all with Javascript disabled.

  4. Attacked form has effective CSRF protection tokens 
     placed in it server-side (otherwise it would be easier 
     to do a CSRF attack rather than CJ and get the same 
     result).

I think that the circumstances under which the attack would be possible might be quite rare compared to those in which the sandbox feature would be a benefit.

One protocol fix that might get the best of both worlds would be to add a new X-Frame-Options token that indicates that the sender of content 'consents' to it being framed in a no-script sandbox provided it is consistent with the other X-Frame-Options. If the embedding frame requests a sandbox, and the embedded content doesn't have the appropriate X-Frame-Options header allowing no-script embedding, the frame just displays a browser error.

This is old news.

http://media.blackhat.com/bh-ad-11/Lundeen/bh-ad-11-Lundeen-...

These guys used html5 sandbox to break facebook's javascript frame breaker. Two years ago.

I commented on the page why the author should not give security advice.

You should use a different domain as there are tricks to leverage arbitrary js on a subdomain.

Sandboxing is to help protect the client from arbitrary crap. It was never intended to protect the server.

And as for UI Redressing (aka ClickJacking) browsers that support the sandbox attribute must support X-Frame-Options.

A bit of a tangent: it might be a really particular use-case, but I kind of wish that Chrome's <webview> (http://developer.chrome.com/trunk/apps/app_external.html#web...) was a universal HTML5 feature for secure rendering contexts (extensions; file:// URLs; node-webkit, AppJS, and other HTML5 "platforms"; etc.)

It would be great if, in those use-cases (where clickjacking isn't a problem), there was a guaranteed way to have a page load in an iframe-like context, but with a separate renderer, separate JS state, asset(window.top == window.self) passing, X-Frame-Options passing, etc.

While reading this, it reminded me of interesting paper on javascript privilege separation, what do you think about it?

https://www.usenix.org/conference/usenixsecurity12/privilege...

a question to iframe spec writters, why didnt they make everything secure by default? if i want to allow javascript in a iframe ,let me explicitly write it for instance. if i want my content to be embedded in an iframe , let me explicitly allow it in my headers , etc ... wouldnt it make more sense ? rather than introducing more security holes and attack vectors ? third parties should have my explicit permission to embed my content into their site.

Hey. I like JavaScript. It makes Node.js work.