Birth of a Security Feature: ClickJacking Defense

[Guest NewsBot]

Hi, my name is Kymberlee Price, and I recently joined the Internet Explorer team as a Security Program Manager for IE8, working with Eric Lawrence. Prior to this I spent five years in Microsoft's Security Engineering & Communications team (MSEC) where I founded the Security Researcher Community Outreach team in 2003 and drove the first three BlueHat events. I joined IE at the perfect time to watch a new security feature be created, and thought customers and security researchers might be interested to learn more about how that happened.

 

In September, I moved into my new office, the sun was shining (even in Seattle), and Robert Hansen and Jeremiah Grossman were preparing to deliver a talk at an OWASP meeting in New York on a new security threat that they called ClickJacking. As details started coming in over the next few weeks, so did the meeting requests. I attended a number of brainstorming meetings with web security experts Billy Rios, Bryan Sullivan, David Ross, Eric Lawrence, Spencer Low, and members of Microsoft Research such as Helen Wang. The highlights of those meetings:

 

Frame-breaking Javascript is often presented as an anti-ClickJack mechanism, but it is a flawed solution as there are methods to circumvent frame-breaking Javascript. And fundamentally frame breakers were never meant to be ClickJacking mitigations. If you don’t design something to prevent a security vulnerability, odds are that it doesn’t do a very good job of doing it accidentally.

 

Browser configuration options are limited.Short of using Security Zones or add-ons to disable frames and script (massively impairing browser utility), browser users are very vulnerable to this type of attack.

 

So we found ourselves in a situation where IE didn't have a workable mitigation for end-users to protect themselves, and we knew of ways to circumvent virtually everything that a server could try to do to prevent ClickJacking without additional help from the browser platform. The “unbeatable†mechanisms would require extensive changes to web application code and it would be difficult to get such recommendations taken seriously.

 

It was time to look at developing a new solution. David Ross prototyped a tool that on cursor hover would delay the user's ability to click through for 5 seconds while showing the user what site/domain they were ACTUALLY about to click on. While this would certainly let the user make an informed decision before clicking, it would also create a significant user impact to web browsing. ClickJacking is actually a fairly narrow attack that represents a subset of the significantly larger cross-site-request-forgery problem. If a website doesn’t protect itself from CSRF threats, attackers need not bother with ClickJacking at all. Given the nature of the threat, creating a defense mechanism that puts a heavy burden on the browsing experience for users is unacceptable.

 

Ultimately, we concluded that the best ClickJacking defense feature we could add to IE8 during product development would be to allow the content owner to decide if their content should be framed or not, and for the browser to enforce that. This solution was also proposed by Michael Zalewski on the WHATWG forum.

 

Eric and I started discussing potential ClickJacking defenses with security researchers at conferences and consistently got feedback that the 'don't frame me' opt-in solution was reasonable as opt-out options all came with significant compatibility and usability issues. But we still wanted to get more feedback from web security experts so we communicated with several browser vendors in early December, creating an open forum to discuss the problem and propose solutions. We shared our plans, asked for feedback, and encouraged other browsers to adopt a similar model in the near term—we want all users to be protected, regardless of browser!

 

Now that RC1 is out and the ClickJacking defense feature is public, our work is not done. As an opt-in protection measure, web developers need to make a change to their code to activate this defense for users. That means educating our field consultants and account managers. I'll be presenting at TechReady 8 next week, and my first Call To Action bullet point is for our front line field employees to help developers understand how to opt in and take advantage of this. My second bullet point is to help developers create a migration plan to get off legacy browser platforms - the architectural changes and security investments we have made in recent browsers are significant.

 

-Kymberlee Price

Program Manager

 

 

More...