I’m sure you’ve heard about the new IE8.0 Clickjacking protection here, here and probably most importantly here on the IE blog. It’s probably time I explain exactly what the pros and cons are of this technology as I see it. It’s a complicated problem for those who aren’t entirely initiated so bear with me.
1) It will protect against clickjacking if the header is present.
2) It has some usability improvements over the original idea I heard which is that it can allow same-domain iframes.
3) It doesn’t require a plugin which makes it useful by default for any users of IE8.0. That’s a good thing - now if we could just get Noscript built into the browser too! Firefox currently has no default equivalent and I don’t know of any viable projects underway to create a better fix in any other browser by default. That gives IE an edge in the market for default users, once the browser reaches the user’s desktop.
1) It’s proprietary to Microsoft - which means that other browsers aren’t protected on the same site that tries to protect itself. That dramatically reduces the percentage of coverage - but that’s a reasonable issue in my mind because we have to start somewhere and other browsers can adopt it if it’s a good idea. There is precedence for this - HTTPOnly. HTTPOnly was a Microsoft proprietary tag on the end of cookies. They invented that concept many years ago and here we are years later and relatively few sites have adopted it and almost no browsers have adopted the standard, even though I think most security people would agree it has a lot of advantages over normal cookies. So if it took years for developers to add a few bytes of text to a cookie that they were already setting, how much longer is it going to take for them to understand how to set an entirely new HTTP header? If your bet is years, you and I are in agreement.
2) No one uses IE8.0, yet. You wouldn’t believe how many times I’ve gone to a customer’s site and realized that everyone in the company is still on IE6.0! Yes, you heard me, not even 7! It’ll be a long time until we see companies getting with the times (and by the times I mean this century’s tech).
3) Since it’s an HTTP X-header it will severely limit who can protect themselves and in what circumstances they can protect themselves. That’s not altogether a bad thing, because most of the big sites can probably muddle their way through this problem. But it’s not nearly as easy as it would be if the browsers just worked securely by default.
4) There is no way for an average user to know that a site is protected (this was Giorgio’s point). Even more advanced IE users would find it a pain to check every single function on every site to make sure it was sending the proper header. This isn’t that big of a deal in my mind simply because there are tons of things average consumers can’t do. It doesn’t bring any peace of mind though, like an SSL lock does - for whatever real security good that does. But this header isn’t even a public relations win unlike whizbang green EV certs.
5) It doesn’t work for all companies in all situations. Companies like banner advertizers, who need people to be able to click on their sites from other domains, can’t protect themselves because it would break their functionality. Similarly mashups and widgets present a real technical challenge.
If you’re a company and you really want to go through the trouble of implementing this as a short term stop gap for the very few IE8.0 users that visit your website, there may be some shortcuts. For instance, if you have an HTTP gateway (like a F5 load balancer or any sort of HTTP proxy for instance) you may be able to send this header on every request without touching your application logic. Not ideal, of course, but it’s possible and probably a lot cheaper than re-writing a lot of application code to protect those very few users who would be protected. All in all I think this is interesting tech from Microsoft and I’m glad they’re thinking about it. But it’s not a panacea, and you shouldn’t rest easy if you’re an IE8.0 user.
I’ve been promoting the concept of opt-in security for years now. I was the one who first came up with content restrictions for instance and pushed it heavily for the last 4-5 years now (and we still don’t have it). So this is one of the first very good examples of that philosophy - which is that sites should be able to protect themselves without having to interfere with anyone else’s tech anywhere else on the internet. It’s a good model in the case of content restrictions because the amount of sites that take rich HTML and need to allow script and objects and whatever else (think MySpace), still shouldn’t be forced to allow their end users to steal cookies as a price of doing business.
The amount of sites and types of sites that intentionally allow rich HTML to be posted by any user are extremely small in comparison to the global scope of all websites everywhere. So the opt in content restrictions model makes sense in that case. X-FRAME-OPTIONS on the other hand applies to a surface area that effects nearly all dynamic websites on the entire Internet. Clickjacking is closer to CSRF than it is to sites that are vulnerable to persistent XSS worms. So while the opt in security model made sense in one sense, I think it’s improper to think about these two problems as being similar enough to warrant the same model. I’m not trying to beat up on MS here, I just want to explain my opinion!
It will be years at the earliest before enough companies adopt Microsoft’s solution to make any real difference in the clickjacking surface area that is the Internet. The really pragmatic question is why bother creating a partial fix for a problem that no one has actually maliciously exploited yet? I’m still waiting for an actual exploit to hit the wild before I start sounding the alarm bell. Sure, there’s tons of workable exploits out there. But like a lot of things this all might be premature - there’s still a lot of easier ways to exploit websites and consumers out there.