At a presentation a few weeks ago someone asked me about capturing session details during authentication at an STS by way of frames and JavaScript. To paraphrase the question: “What prevents a malicious developer from sticking an RP within an iframe, cause a redirect to an STS, get some user to log in, and then capture the details through JavaScript from the parent page?” There are a couple of ways this problem can be solved. It’s a defense-in-depth problem where on their own, each piece won’t close every attack vector, but when used together you end up with a pretty solid solution.
- First, a lot of new browsers will actually prevent cross-frame JavaScript calls when SSL is involved. Depending on the browser, the JavaScript will throw the equivalent of an Access Denied exception. This is not the case with all browser versions though. Older browsers may not do this.
- Second, some browsers will not allow you to host an SSL page in a frame if the parent page is not using SSL. The easy fix for the malicious developer is to simply use SSL for the parent site, but that could be problematic as the CA’s theoretically verify the sites requesting certificates.
- Third, you could write some JavaScript for the STS to bust out of the frame. It would look something like this:
if (top != self)
{
try
{
top.location.replace(self.location.href);
}
catch (e)
{
}
}
The problem with this is that it wouldn’t work if the browser has JavaScript disabled.
- Fourth, there is a new HTTP header that Microsoft introduced in IE 8 that tells the browser that if the requested page is hosted in a frame to simply stop processing the request. Safari and Chrome support it natively, and Firefox supports it with the NoScript add on. The header is called X-Frame-Options and it can have two values: “DENY” which prevents all requests, and “SAMEORIGIN” which allows a page to be rendered if the parent page is the same page. E.g. the parent is somesite.com/page and the framed page is somesite.com/page.
There are a couple of ways to add this header to your page. First you can add it via ASP.NET:
Context.Response.AddHeader("x-frame-options", "DENY");
Or you could add it to all pages via IIS. To do this open the IIS Manager and select the site in question. Then select the Feature “HTTP Response Headers”:
Select Add… and then set the name to x-frame-options and the value to DENY:
By keeping in mind these options you can do a lot to prevent any exploits that use frames.