Clickjacking and Phishing with help from the HTML5 JavaScript Sandbox

HTML5 has some nice new features one of which is JavaScript Sandboxing using iframes. Chrome is currently the only browser to support this but you can be sure others will soon follow. The sandbox allows control over what can be executed within an iframe, it provides the following options.

  • allow-same-origin allows iframe content only from the same domain.
  • allow-top-navigation allows the iframe to change the URI of the parent.
  • allow-forms allows the use of forms inside the iframe.
  • allow-scripts allows JavaScript to run inside the iframe.

If no options are specified for the sandbox then the iframe can only display basic HTML. It can be implemented using the iframe sandbox property as follows:

<iframe src="page.php" sandbox="allow-forms allow-scripts">
</iframe>

The feature is great for an attacker as it allows them to now include pages inside an iframe that previously had some Javascript iframe breakout code in place. This is great for Clickjacking or Phishing attacks. Lets take a look the most popular way of breaking out of an iframe and show how by simply sandboxing the iframe we can prevent the JavaScript breakout code from working.

<script type="text/javascript">
	if (top.location!= self.location) {
		top.location = self.location.href
	}
</script>

And this method works great unless the script has been loaded in a sandboxed iframe that doesn’t have the sandboxing options “allow-top-navigation” and “allow-scripts” enabled.

Without either of these options the script just wont work. The great thing is we have some level of granular control, you can have “allow-scripts” on your iframe (which will allow all the JavaScript found in the iframe to run) but you can omit the “allow-top-navigation” which will stop the JavaScript iframe breakout.

There is an elegant solution to prevent this type of attack – the HTTP header “X-Frame-Options” – which is now supported in the latest versions of IE, Firefox, Safari and Chrome. It allows the server to specify if it should allow its content to be loaded from within an iframe by either pages from the same domain (SAMEORIGIN), or not at all (DENY). Surprisingly there aren’t many sites using it.

If your running apache with mod_headers installed you can automatically add this header to all of your pages by adding the following lines to your apache.conf

Header always append X-Frame-Options SAMEORIGIN

Don’t forget, X-Frame-Options isn’t supported in older browsers so its still worth keeping your existing JavaScript iframe breakout code in place.

This entry was posted in HTML5 and tagged , , , , . Bookmark the permalink.

6 Responses to Clickjacking and Phishing with help from the HTML5 JavaScript Sandbox

  1. Bob Novell says:

    You say:

    There is an elegant solution to prevent this type of attack – the HTTP header “X-Frame-Options”

    Sorry, that is not an elegant solution in that it does not allow you to break out of the frame and get the user to your page.

    It merely prevents the display of the page in the frame. From what I’ve seen, IE8 will display a message saying that the page cannot be displayed in the frame and FF just presents about:blank

    Neither one breaks you out of the frame.

    If the X-Frame implementation had provided some way to redirect the request to a page on your web site, then it would be an elegant solution. But, as it stands, it has no elegance at all.

    Right now all that you can specify is either DENY or SAMEORIGIN

    How about adding REDIRECT as an additional option, to be used with either DENY or SAMEORIGIN.

    If REDIRECT is specified, and the page is being framed in violation of the DENY/SAMEORIGN options, the browser would redirect to the “framed” page.

    Thus if someone tries to put the page http://an-example-of-a-domain-name/index.html

    Instead of the browser just display about:blank or an message in the frame, the browser will load http://an-example-of-a-domain-name/index.html in “top” thus breaking the page out of the frame.

    It could be further extended to all the specification of a page to which the browser should redirect, rather than to the page that is being framed.

    Sandboxed frames are more of a danger than a help of any sort.

    Who thought them up – clickjackers?

    As though we don’t have enough troubles preventing our pages being framed, now we have to contend with someone being able to nullify our Javascsript frame-breaker code in yet another way – by sandboxing the frame. That’s really smart!

    Again, who thought this up – the clickjackers or some very stupid people? It has to be one or the other and, sadly, I think it is the latter — stupid people!

    I do not understand why you would want to put dangerous material into a frame on one of your pages. What do you gain by giving people that ability?

    The only people who gain from sandboxed frames are the “bad” guys.

    The “good” guys will be screwed.

    Sandboxed frames are going to create more problems than they are worth.

    The entire idea should be dropped and all support for it removed from the specifications and all browsers.

    When someone puts one of my pages in a frame, I want to break out of it and take the user to my page – not simply prevent it being displayed in the frame.

    Bob Novell

    • Phil says:

      Lol, yeah, point taken, it’d be nice to have a redirect option. I really don’t think the sandboxes are going to cause more trouble than their worth – I can see them being useful in situations such as placing more robust restrictions on the functionality of user generated content.

      • Stephen says:

        I initially had the same reactionas you, but having a REDIRECT option for X-Frame-Options is it’s own kind of security threat.

        Imagine you need to use an iframe in order to display a widget from a social media site. (Often you’ll just suck in a piece of javascript from their site, but that javascript can create an iframe on your page in order to display something from their site) Now imagines said social media site gets hacked, and uses an X-Frame-Option to set the top-level browser location to another site which exploits a browser security hole or something else.

        The user comes to your site, but your Twitter widget has taken control and is punting them to a porn site. :/

  2. james says:

    Hi nice tut

  3. jackl007 says:

    How can I redirect when my web is in a frame with sandbox=”allow-top-navigation” ?

    I was using the break out code for Google Images in order to redirect to my site instead of only showing my image in google frame.

    • Phil says:

      I tried breaking out using target=”_top” but it appears (in Chrome at least) that the you need allow-scripts to use the target attribute. Looks like theres no real solution to breaking out of allow-top-navigation.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>