Who framed Roger Badbit?

I recently blogged how to mitigate the clickjacking vulnerability with the X-Frames-Options HTTP header. Then XSS-track came to my attention, so I figured it would be a good idea to blog more in general about attacks employing frames. A general post mandates a general and catchy title (you have to agree that it is).

First, a few comments on the idea behind XSS-Track. In general, an XSS vulnerability lets you inject script into a particular webpage. If the user navigates away from this page, you've "lost" her. XSS-track injects script to load the attacked website in an iframe, which then becomes the user's view of the website. The user is left navigating the website in the iframe, which means that the XSS script survives in the parent page — a very elegant trick. By owning one vulnerable page, the clever attacker can gain access to all pages the user visits during a session on the targeted website.

Now to more general considerations on attacks that load your site in an iframe, and how the X-Frames-Options HTTP header can help.

Browser security
The same origin policy is a fundamental building block in client side web security — a browser will completely isolate content and scripts downloaded from one domain from content fetched from other domains. At least, this is the general idea. There are some subtle implementation differences across browsers, but by and large they act the same. If you're able to circumvent this protection you have an attack and should tell the world about it! Remember, tell the browser vendors first.

Frame based attacks
Here are the different categories of attacks using frames, ordered by how effectively they circumvent the same origin policy:

1. The least severe attack is when someone frames your website and tracks the user's movements from a domain different than yours. This is a privacy issue, the attacker (usually) cannot perform any actions on behalf of the user, nor can she extract any personal information from the webpages themselves. This is not a circumvention of the same origin policy.
2. Next we have the clickjacking attack, which is a client side attack to lure the user into generating one or more clicks on a webpage. This is a WYSINWYT (What You See Is Not What You Think) attack capitalizing on the user to work around the same origin policy.
3. Finally, the XSS-track approach is not bound by the same origin policy as the script is served from the attacked page itself. This gives you full programmatic freedom. Consequently, attacks can be performed without user intervention on a webpage.

The cure
To reduce risk, you should set up your site to be secure by default. This essentially means to completely disable framing of your pages, mitigating all three categories of attacks:

X-Frames-Options: deny

If you have certain pages that need to be framed on your site, try to configure only these pages to run with:

X-Frames-Options: sameorigin

This is a security/functionality tradeoff. The sameorigin setting will mitigate the first two categories of attacks but not the third and most powerful category.

You'll find examples on how to enable the X-Frames-Options header globally for your website in my previous blog post.

So, don't be Roger Badbit. Enable X-Frames-Options for your site now — or you might end up as Roger Badbeat.*

* I had to follow up on the title. I'm sorry.