who's that guy?
>But, most sites don't protect against CJ at all.
This is definitely truth. Sad truth.
>Of the sites that do, as many use XFO (the HTTP Header that denies reframing) as use JS framebusters.
do you have statistics or something? Because I am not sure about this. IMHO, for now, framebreakers are more popular. XFO is still for well educated developers, framebreakers are old-school.
> But that's a red herring in this case; what browser supports H5 Sandboxes but not XFO?
I believe all do support.
> rendering them on a page without losing control of Javascript
can you elaborate this please? Because most people say 'something bad with JS'. SOmething what? What exactly bad is going to happen, besides prompt(1)?
> CJ is an inherently less scary problem than XSS
obviously, but XSS is unrelated threat here (or i missed something)
> Oughtn't we just encourage everyone to set XFO, instead?
I agree with you. NOW there is no way back, but 3 years ago people should have been more careful about security compatibility, IMO
I think this is the best point in your argument. If you're going to half-assedly block framing (via JS, not using XFO), you will have problems. Either through sandboxed frames, or using XSSAuditor against it, it will break.
Besides this minor issue, there really is no other serious flaw with sandbox framing.
and regards flaws - sandbox could be more tightly coupled with Content security policy. Not a big deal, but posts look really misleading telling "put it in sandbox, well done"
Luckily, this one is still a draft...
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...