You failed to address his realistic criticism that many websites are not yet using X-Frame-Options. Browsers that introduce the sandbox feature have now broken those sites' security.
Obviously he meant turning of JS made clickjacking feasible again for many websites. Why u pretend to not understand that? Are u kind of html5 moralist?
Sandbox iframes allow disabling javascript in a frame, which disables framebusting protection [1] used by sites like vk.com. The better way to framebust is to add the header 'x-frame-options: deny', which isn't broken by html5 sandboxes.
The problem is that some sites, either because they were designed before XFO or because they made the mistake of assuming they had to do either JS or XFO but not both, rely entirely on JS to prevent reframing.
So there is a scenario in which browser support for sandboxed frames could cause problems for preexisting websites.
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.
As a side note the thing I find most puzzling about RFC 6797 is that the 'max-age' field can be set to 0 to invalidate the HSTS flag for the domain, but can't be set to an indefinite value. The inability to deal with stripping before reception of the 'Strict-Transport-Security' header is understandable, but lack of indefinite retention of the HSTS flag is hard to comprehend.
Some of the new HTTP headers are just a mess. Did you know that X-Frame-Options' Allow-From option only allows you to whitelist one URL? Not a domain - a URL. The RFC actually expects you to communicate via another channel to determine whether or not a URL will be allowed to frame your page.
> 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.
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"
>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
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.
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.
Frames go back to the 1990s. Like a lot of the web technologies dating to that time period, the security implications of such functionality either weren't very well understood at the time, or weren't considered.
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.
> One protocol fix that might get the best of both worlds
it would be good unless following fact - many developers DONT follow HTML5 tricks, and vk.com is an example. They rely on framebreakers because it worked once and they DONT expect it to get broken someday.
A protocol fix that meant that the server serving the content needed to opt in to no-script through a new X-Frame-Options header would mean that legacy content like vk.com wouldn't send a X-Frame-Options header, and so wouldn't be able to be framed in a no-script iframe.
The parent comment raises a very good point. Does the supposed VK.com CJ vector work at all with Javascript disabled? Disabling JS stops the framebreaker; does the site UI still work when you do that?
Why is the answer not “HTML5 sandbox cannot compensate for non-security-minded developers”? After reading this and the discussion, the only thing which seems certain is that the vk.com developers need to set XFO.
48 comments
[ 3.0 ms ] story [ 112 ms ] threadYou 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.
I understand that English is not everyone's first language, but I honestly had a hard time parsing the linked post.
[1] http://en.wikipedia.org/wiki/Framekiller
Sandbox COULD be a good thing. Eventually it's evil
Sure, a one new thing without the other new things it expects is bad, but older browsers won't support any of them and the old thing will still work.
So there is a scenario in which browser support for sandboxed frames could cause problems for preexisting websites.
we consider following tricks:
document.write('')
setTimeout(function(){document.body.innerHTML='';},1);
window.self.onload = function(evt){document.body.innerHTML='';}
None of them was bypassed further in the paper. (I used Ctrl+F)
Anyway I like people telling me I'm wrong, and enjoy conversations with them.
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.
In my spare time I write how broken web is. This is my hobby.
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...
Luckily, this one is still a draft...
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"
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
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.
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.
it would be good unless following fact - many developers DONT follow HTML5 tricks, and vk.com is an example. They rely on framebreakers because it worked once and they DONT expect it to get broken someday.
I'm sure you know that most of the Rails forms will work w/o JS as well.
framebreaker worked well until it sandbox was invented. If we should blame someone - it is rather W3C, not VK.
https://www.usenix.org/conference/usenixsecurity12/privilege...