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.

Defeating Clickjacking

The clickjacking vulnerability is receiving an increasing amount of attention. There has been some interesting advances in exploitation techniques, as explained in this video: Next generation clickjacking by Paul Stone at the Blackhat Europe 2010 security conference.

Let's first summarize the basic properties of a clickjacking attack:

1. The attacker can load a page from your website in an iframe
2. The attacker can have the user perform mouse operations on your webpage, i.e. clicking buttons, dragging and dropping content etc.

If we can prevent a webpage from being embedded in an iFrame, the clickjacking vulnerability will be mitigated. Framebusting is the traditional approach to prevent clickjacking attacks — a javascript embedded in a webpage to detect framing and try to "bust out" of the frame.  However, a recent study by researchers at Stanford summarizes common framebusting efforts and concludes that framebusting fails to mitigate the risk.

Lesson learned: HTTP modules can also affect WebResource.axd

HTTP modules can be very useful. In fact, I love them. The scope of this post is unfortunately not to explain what they are or what they do. If you're not familiar with what a HTTP module is, get an overview here and see how to create one here.

ASP.NET features some built in handlers: WebResource.axd and ScriptResource.axd. You'll see requests to these in any ASP.NET application, as they're used to serve builtin scripts for e.g. postback or client side form validation. By default, the ASP.NET application will configure these to expire from cache after a year.

Today I discovered a side effect I had not thought about. HTTP modules are loaded by the application, and are hooked into the event pipeline for each and every request handled by the ASP.NET application. In fact, this also includes requests to the WebResource.axd and ScriptResource.axd handlers!

How to secure ASP.NET cookies

The release of Firesheep a week ago brought a lot of attention to a problem that has been known for many, many years: cookies sent over both secure and insecure connections to the same site. Why all the fuzz now? Well, first of all, "regular" people (as in non-geeks) can install Firesheep and start stealing Facebook sessions. With such a demonstration, people realize just how easy it is to "hack" another user's account. Secondly, we're all on Facebook, so we all feel that this affects us personally. We can relate to the risk, and it stirs our emotions. Thirdly, the media loves these kinds of demonstrations and can capitalize on the fear factor. This hack was simple enough and scaled nicely, which made it a good sell.

Now the debate goes on about Firesheep, here's a good blog post on the ethical aspects. In this post I also found a link to Microsoft's Malware center, their antivirus software apparently detects Firesheep as a hacktool. Like it really matters. Firesheep clones will pop up all over the Internet. The only viable path forward is to build websites not vulnerable to trivial eavesdropping attacks.

Firesheep has raised the bar for baseline security in web applications. Before Firesheep, you would be regarded as sloppy or lazy not to have secured your website's cookies. After the release of Firesheep, you're essentially committing a crime against your users — because now you (and they) know that cookies can easily be stolen.

If you need a basic introduction to what cookies are, check out the cookie article on Wikipedia.  The rest of this post discusses more technical aspects of cookie security.