
HTML5 Sandbox - a bad idea - homakov
http://homakov.blogspot.com/2013/04/html5-sandbox-bad-idea.html
======
tptacek
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...](http://crypto.stanford.edu/~dabo/pubs/abstracts/framebust.html)

~~~
homakov
>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

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

~~~
homakov
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

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

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

~~~
tptacek
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?

~~~
homakov
yes it does. VK migrates "gracefully" and Like/friend/comment buttons work w/o
JS.

I'm sure you know that most of the Rails forms will work w/o JS as well.

------
bluetooth
This is old news.

[http://media.blackhat.com/bh-ad-11/Lundeen/bh-
ad-11-Lundeen-...](http://media.blackhat.com/bh-ad-11/Lundeen/bh-
ad-11-Lundeen-New_Ways_Hack_WebApp-WP.pdf)

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

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

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

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

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

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

~~~
shardling
I'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
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?

------
derefr
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...](http://developer.chrome.com/trunk/apps/app_external.html#webview_element))
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.

------
adamsaleh
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...](https://www.usenix.org/conference/usenixsecurity12/privilege-
separation-html5-applications)

~~~
homakov
is there TL;DW (too long didnt watch)

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

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

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

