Somebody has to be first

Recently Microsoft came up with a solution, supported natively in IE8, to protect against clickjacking attempts. Apparently some folks have decided that because Microsoft has a history of implementing proprietary solutions that this one, too, must be proprietary. These same folks must also have very little understanding of today’s web application architectures, as they declared the solution pretty much useless based on some pretty poor assumptions regarding the implementation of said solution. 

As noted in the Register, “some critics have contended the protection [X-FRAME-OPTIONS custom HTTP header] will be ineffective because it will require millions of websites to update their pages with proprietary code.” 

Where to start, oh where to start…

Proprietary implies usable only by a certain subset of products: those endorsed by the creator of the “proprietary” solution. Proprietary implies peculiar to a specific technology. Proprietary implies closed. Proprietary means things like ActiveX, which only work properly on a Windows platform. Proprietary means keeping the implementation secret so no one else can implement it. Microsoft implemented a solution based on a custom HTTP header. A header, I might add, that anyone using any browser running on any platform is quite capable of seeing. A header that  can be easily handled by any other browser developer, if they so choose, to implement similar behavior. A header based on accepted standards.

A custom HTTP header can be interpreted by any browser if it so chooses as well as intermediaries capable of intelligently handling HTTP. The speedy support via NoScript for X-FRAME-OPTIONS proves the solution is hardly “proprietary” and not applicable to just Microsoft’s solution.

The term proprietary is often considered synonymous with Microsoft but in this case calling the solution proprietary is simply the result of a bad habit apparently difficult for some to break.

Unlike the use of other truly proprietary solutions in the browser – like XMLHTTPRequest object before it was widely adopted as a “standard” – custom HTTP headers are about as innocuous as you can get. Their existence neither hinders nor helps browsers that don’t support it and it does absolutely no harm to applications or the user-experience to carry it along even to clients that will see no benefit from it. And if the developers of those browsers/clients decide to support it, the existence of such headers will immediately provide a benefit.

“…it will require millions of websites to update their pages with proprietary code.” 

Excuse me while I decide whether to laugh or have a conniption fit at this one.

This assumption shows a decided lack of understanding of architecture. While it’s certainly true that one way to support the use of X-FRAME-OPTIONS is to update web applications (let us not fall into the trap of digressing into an argument over the use of the term “pages” and “code” to describe an application…) there are are other, less disruptive, solutions.

The organizations that are most likely to be the subject of a clickjacking attack are financial institutions, retailers, and perhaps social networking sites. It seems likely that these folks have built out an architecture capable of scaling and assuring availability of their sites. If you think not true, consider how often you’ve attempted to visit one of those sites and not been able to do so. Exactly. They’re smart people; they’ve built out an environment that almost certainly involves intermediaries (load balancers, application firewalls, application switches, application delivery controllers, proxies, etc…) that do other forms of application layer inspection and, perhaps, manipulation. They have other things to worry about, after all, like data leak prevention and content filtering and stopping SQLi and other nasty attacks from destroying their critical applications. So they’ve likely already got an intermediary in place that’s capable of easily adding a custom HTTP header on the way out the door.

As I previously noted in Clickjacking Protection Using X-FRAME-OPTIONS Available for Firefox folks can use network-side scripting solutions to effortlessly insert the custom header as necessary without modifying code. If an application is comprised of say, an average of ten pages (I’m low-balling the estimate, I know that, but you can do the math on your own applications yourself), then this solution is 10 times more efficient than modifying the associated code. And network-side scripting solutions are likely already in place at most organizations that are likely to be targeted by clickjacking attacks. So all they have to do is write a little script and voila! This “proprietary, ineffective” solution starts working. Then they encourage customers to upgrade to IE8 or install the proper version of NoScript and, well, the Internet is safe again (at least for about 2.71828182845904523536 or “e” seconds).

Just because an organization comes out with a solution first doesn’t automatically make it proprietary, unless they’ve already patented it and in that case, well it’s a whole different ball game. Microsoft saw a problem, decided on a solution, and implemented it.

What should be noted is that they did it in a way that made it possible for other browser vendors to take advantage of the same constructs to implement a similar solution. They used a custom HTTP header that’s portable and browser and operating system agnostic when they could have found any number of other, truly proprietary ways to solve this problem.

I’ve been down on Microsoft and its products in the past but in this case the software giant doesn’t deserve the negativity involved with calling this a proprietary solution. This is a far sight better than the framekiller options available today and it certainly doesn’t require the amount of work implied by these “critics” to leverage the solution.

Related blogs & articles:

• Clickjacking Protection Using X-FRAME-OPTIONS Available for Firefox
• Hypertext Transfer Protocol – HTTP/1.1 RFC 2616
• Picard and Dathon at El-Adrel
• Jedi Mind Tricks: HTTP Request Smuggling
• Why not network-side pre-fetching?
• How to brandalize your content with network-side scripting
• I am in your HTTP headers, attacking your application