7 ms·
HTML5 Sandbox - a bad idea
- camus 14y agoa 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.
- homakov 14y agoi should borrow this text and put it in my blog tagline. as TL;DR.
- PommeDeTerre 14y agoFrames 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.
- chickopozo 14y agoI 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.
- chickopozo 14y agoTL;DR Author is wrong about clickjacking and sandboxing is a good thing.
- kevingadd 14y agoYou 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.
- shardling 14y agoI'm not sure what you mean -- how can the browser possibly break the sites security? I understand that English is not everyone's first language, but I honestly had a hard time parsing the linked post.
- homakov 14y agoObviously 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?
- deleted 14y ago[deleted]
- moonboots 14y agoSandbox 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. [1] http://en.wikipedia.org/wiki/Framekiller http://en.wikipedia.org/wiki/Framekiller
- homakov 14y agohow can i be wrong about clickjacking? I use XFO. I pointed out obvious thing - not everyone uses XFO. Sandbox COULD be a good thing. Eventually it's evil
- sitharus 14y agoI left the page more confused than when I started. The argument seems to string together a bunch of things that don't seem quite related. 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.
- tptacek 14y agoThe 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.
- homakov 14y agoexactly, and vk.com (biggest social network in europe) is a showcase. They use such framebreaker: if (parent && parent != window && (browser.msie || browser.opera || browser.mozilla || browser.chrome || browser.safari || browser.iphone)) { document.getElementsByTagName('body')[0].innerHTML = ''; } It cannot be bypassed with NoContent trick by the way. Because it removes body, not navigates the parent
- homakov 14y agoIn 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.
- bluetooth 14y agoThis is old news. http://media.blackhat.com/bh-ad-11/Lundeen/bh-ad-11-Lundeen-New_Ways_Hack_WebApp-WP.pdf 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.
- homakov 14y agoYes, of course! I know about it since I first read about sandbox. In my spare time I write how broken web is. This is my hobby.
- bluetooth 14y agoAh okay, I didn't mean to belittle your work (I actually think it's quite great) I was just hoping you knew this wasn't exactly new material.
- homakov 14y agoI have added the link, there are even more interesting stuff in the talk. thanks
- gluxon 14y agoHey. I like JavaScript. It makes Node.js work.
- tptacek 14y agoI'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.html http://crypto.stanford.edu/~dabo/pubs/abstracts/framebust.ht...
- ary 14y agoAs 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.
- derefr 14y agoA 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#webview_element 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.
- A1kmm 14y agoThe 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.
- homakov 14y ago> 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.
- A1kmm 14y agoA 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.
- homakov 14y agoand nobody will use it. because in fact NOBODY wants to run their pages w/o JS. And this is why sandbox is a bad idea.
- adamsaleh 14y agoWhile 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-separation-html5-applications https://www.usenix.org/conference/usenixsecurity12/privilege...
- homakov 14y agois there TL;DW (too long didnt watch)