Friday, June 4, 2010

html5 sandbox tag - good defense against clickjacking

Before diving into the sandbox tag, a quick two question quiz.

iframe (the source of clickjacking attacks) was invented by?
  1. Thomas Edison
  2. Microsoft
  3. Apple, it's their new name for a digital photo frame
Where can you use markup like <iframe security="restricted">?
  1. CERN
  2. IE Browser
  3. Everywhere today.
(2) is the correct answer for both.

The SECURITY=restricted tag is something only IE supports, and adoption has been very low among website developers (4 sites out of 10,000 surveyed apparently)

The most high profile clickjacking technique currently, is a Facebook trick, whereby the baddie uses a cleverly crafted iframe to trick you into 'liking' something.

The result can be considered a social hack, whereby other users might feel more trusting of something, based on your (bogus) recommendation.

If you care about your online reputation, then you should at least have an awareness of such techniques.

Rather than singling out Facebook, it might be proper to report that Twitter had the "Don't click" annoyance which is documented in detail here. Twitter responded to this issue and it quickly disappeared.

html5 iframe tag extended to sandbox with src attribute:

<iframe sandbox="allow-same-origin" src=""><iframe>

<iframe sandbox="allow-same-origin allow-scripts" src=""><iframe>

A new Mime type text/html-sandboxed
has been specified which is used in partnership with the sandbox attribute so that:

  • The sandbox attribute tells you what type of secure browser environment should be created before rendering the content
  • The  text/html-sandboxed type indicates that this content being delivered from the server is  subject to some sandboxing.
  • The  text/html-sandboxed type indicates that the content is other than regular unsandboxed html, and should not be served directly, but only within a sandboxed iframe.

Here I quote directly from Eitan Adler article ( )
So it’s a security feature. You could restrict an advertising iframe to have no privileges whatsoever, but you could give a widget iframe privileges to execute its own scripts or embed its own forms.

You could argue that this sandbox marker in html5 is not too different to the (IE only) security=restricted thing. The important thing, is that, being part of a formal, company independent standard, should encourage website developers to feel that they are more likely to get some return from their time, in implementing it on their site.

There is much more to the html5 proposal than a 'restricted' equivalent and many more details are shown at the links below.

iframe sandbox - current and planned implementations:

Chrome and Safari have taken the lead here as being webkit based, they
both have rendering engines with a sandbox implementation.

Some details on the Chromium blog

sandbox tag support status - Opera


Mozilla seem to have dropped the ball a bit here. They are so busy implementing 64 bit versions of their software and other priorities that they seem to have missed the boat.
Mozilla Firefox is my preferred browser, but I feel it is being held back at the moment by:

  • The fact that the NoScript plugin is so effective.
  • Confusion by having the term sandbox already applied to isolation of plugins. ( I think of that sandbox as a stability feature but the two are sometimes confused )

( Whilst NoScript is a convenient solution right now, it would be good to have official inbuilt support commitment from Mozilla folks regarding sandbox attribute of iframe )

I think it will be a mistake if Mozilla decide to ship Firefox 3.7 without support for iframe sandbox tag.

There is a test script here to report on whether you browser supports html5 sandbox tag.

I ran the test script for my system (Debian Squeeze) and both Midori and Epiphany report success \o/

Opera on my system has just been updated but reports a fail (Opera version

The test script link (above) returns this message from Opera:

Alternative approaches that involve headers:

My personal opinion here is that these are a mistake, it is a nonsense approach to have a webserver header to fix this problem. Better to remove iframes altogether from the html standard, rather than be prescriptive about which web server software is 'good' and 'bad' based on out of the box ability to serve these headers.

There are millions and millions of websites out there that pay for shared hosting setups. Suggesting these servers are all reviewed to protect a bit of reputation on Facebook is backward.

Yes, most of these servers (54%) run the same software (Apache) but it would take years to effect the change.

( It is my personal opinion that using meta headers in web site pages to 'simulate' http headers, is something that should be disabled on servers that are proactive about security. )

If Twitter can fix "Don't click" by making some intelligent changes to their site, then Facebook, who are arguably much better funded, can be expected to do the same.

For completeness here are some links to approaches that involve server headers:
A further argument against the server headers approach is that it is all or nothing, which could cause problems with existing users of NoScript plugin (see last paragraph). This would mean that in order to solve one problem (clickjacking), you remove the defenses (NoScript) against another problem.

There are some who suggest there is little to consider and suggest implementing X-FRAME-OPTIONS on the server side, like the views in this article.

Having worked in ISP and hosting environments where thousands of small business host on the same web server, I think the blanket rewriting/header insertion suggestion is naive at best, and the trigger for a disruption to business lawsuit at worst.
( Many businesses rely on their sites being accessible cross browser, and some like the ability to publish their own embeddable content (documents, whatever) on sites they pay hosting for. If removed or affected, without notice this might cause some consternation )

( Should a business themselves choose to move a business site to their own servers, and activate some global http headers, then that is their choice, and their would be no legal repercussions on shared hosting providers. )

With regard to marking their embeddable content with new mime type  text/html-sandboxed , this is something the business themselves could do over a period of time. It would be their choice, and configuring virtual hosts to allow mime type overriding for certain directories, might cause much fewer issues in a shared hosting environment.

In the process, the ISP or hosting company would learn a bit about which of their customers are really taking advantage of the ability to publish embeddable content, and this might help them tailor future service to this new distinction that sandbox in html5 will bring.

Minor annoyances "Are you sure you want to leave this page YES/NO":

Using javascript techniques it is easy to be tricked into leaving a
site for some other (unwanted) destination.

What you should do is ignore the text in the box (if you feel it is suspect) and always reply in the negative (Cancel or No)

If in doubt close your browser.

Installing NoScript plugin for Firefox will help avoid these javascript annoyances.

If you want an indepth discussion about how iframes, can, and have been exploited in the past year then there are a few in depth studies by (links below)
The studies by Gustav Rydstedt give good coverage to the techniques, but fail to survey fully the solution proposals. In particular, making no mention of the Html5 enhancements, in a paper dated only last week, seems to be a unfortunate omission.

Thanks is due to Gustav for making these papers available at all, as they do describe the problem clearly, and I found them very readable.

I want my online documents to be embeddable in my other site:

These type of queries have been cropping up frequently this year.

Should your documents be embeddable by default?
I have my own opinion about this, but I suspect a survey would give mixed results.

googledocs sends X-FRAME-OPTIONS headers in an attempt to indicate to some browsers that they should ignore the document in certain iframe circumstances.
Practical effect today: This blog does not function as it did some months back when viewed from within IE8 :(

Zoho does not implement any server side headers, so should produce similar results in all browsers.

(Unsurprisingly) All documents hosted on a sharepoint server will come with X-FRAME-OPTIONS headers so again the mixed results at the client end.

There are several sharepoint queries floating around in forums, and here are some solutions:

Query: My sharepoint [hosted] document cannot be included my site, is there a way round this?

Answer: If you want your documents to be embeddable then make copies on Zoho and embed the zoho links in your pages at

Lazy Answer: Do nothing. Only IE8 users are affected, whilst 75% of internet users would see the embedded document just fine.

Rolling back the web - who needs iframes anyway:

There are lots of websites that use iframes, however, that does not mean that
you have to allow them in your browser:

Here is another option you might want to tick in the Options:

and for those not familiar with NoScript extension here is some introductory text from the AddOn description:

NoScript is a free AddOn and is very powerful. It really does offer protection against existing and emerging threats (the developer seems quite quick to respond to new internet exploit reports).

However, there is a whole range of options in NoScript, and it will take you a few hours and some experimentation to get your setup as you want it.

If any of the following apply then getting comfortable with NoScript might prove a challenge:
  • It is your first year of using the internet 
  • You have very little knowledge of the terminology (perhaps not knowing the difference between Java and JavaScript might be an indication)
  • You do not value your online reputation enough to spend a couple of hours trying out NoScript and whitelisting your favourite (non-Facebook) sites*
*You will need all the protection of NoScript until Facebook themselves become more security conscious in how they program the 'like' feature (the thing being exploited right now).
( The knowledge is there for Facebook to mitigate the threat already, but whether they are willing to take some resource away from new online games and Yahoo integration, to fix the issue with 'liked this' hijacking is the real question )

Further reading and links:

No comments: