HTML5 Sandbox - a bad idea

http://homakov.blogspot.com/2013/04/html5-sandbox-bad-idea.html

by homakov • 13 years ago

63 46 13 years ago

homakov.blogspot.com

chickopozo2• 13 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.

chickopozo2• 13 years ago

TL;DR Author is wrong about clickjacking and sandboxing is a good thing.

kevingadd• 13 years ago

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.

homakov19• 13 years ago

how 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• 13 years ago

I 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.

tptacek5• 13 years ago

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.

homakov19• 13 years ago

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.

tantalor• 13 years ago

I don't think it's reasonable for anybody to setup a JavaScript playground like "SITE/playground?code=alert(1)". That's asking for trouble.

homakov19• 13 years ago

I don't think it's reasonable for anybody to setup a JavaScript playground (same origin) at all. Not a use case for sandbox then

bluetooth4• 13 years ago

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.

homakov19• 13 years ago

Yes, 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.

bluetooth4• 13 years ago

Ah 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.

homakov19• 13 years ago

I have added the link, there are even more interesting stuff in the talk. thanks

gluxon• 13 years ago

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

tptacek5• 13 years ago

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...

ary• 13 years ago

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.

bluetooth4• 13 years ago

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.

Luckily, this one is still a draft...

bluetooth4• 13 years ago

> 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.

homakov19• 13 years ago

alright, let's blame developers! :)

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"

homakov19• 13 years ago

>Homokov

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

derefr• 13 years ago

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.

camus• 13 years ago

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.

homakov19• 13 years ago

i should borrow this text and put it in my blog tagline. as TL;DR.

PommeDeTerre• 13 years ago

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.

A1kmm2• 13 years ago

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.

homakov19• 13 years 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.

A1kmm2• 13 years ago

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.

tptacek5• 13 years ago

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?

acdha• 13 years ago

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.

adamsaleh• 13 years ago

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...

homakov19• 13 years ago

is there TL;DW (too long didnt watch)

HTML5 Sandbox - a bad idea

Related Stories