Clickjacking: A Common Implementation Mistake Can Put Your Websites in Danger

The X-Frame-Options HTTP response header is a common method to protect against the clickjacking vulnerability since it is easy to implement and configure, and all modern browsers support it. As awareness of clickjacking has grown in the past several years, I have seen more and more Qualys customers adopt X-Frame-Options to improve the security of their web applications.

However, I have also noticed there is a common implementation mistake that causes some web applications to be vulnerable to clickjacking attack even though they have X-Frame-Options configured. In this article, I describe the implementation mistake and show how to check your web applications to ensure X-Frame-Options is implemented correctly.

Hide the remainder of this articleAbout Clickjacking and X-Frame-Options

As I wrote in my previous article, clickjacking is an attack that tricks a web user into clicking a button, a link or a picture, etc. that the web user didn't intend to click, typically by overlaying the web page with a (typically transparent) iframe. The user thinks he is clicking the link on the legitimate page, but actually clicks an unseen overlaid link or button. This malicious technique can potentially expose confidential information or, less commonly, take control of the user's computer. For example, on Facebook, a clickjack can lead to an unauthorized user spamming your entire network of friends from your account. We've known about clickjacking, also called "UI redress attacks," for years now, which Robert Hansen and Jeremiah Grossman originally described in 2008.

So, how do X-Frame Options work? The X-Frame-Options HTTP response header can be used to specify whether or not the browser should be allowed to render content in a <frame> or <iframe>. If an iframe can't be loaded in the browser and overlaid on the legitimate page, then a clickjacking attack is not possible.

Multiple X-Frame-Options in the Response Header

I have seen claims by Qualys customers that Qualys Web Application Scanning (WAS) flagged false positives of the Clickjacking vulnerability during scanning, even though they had deployed X-Frame-Options countermeasures in their web applications. These typically turn out to be true positives because of a common implementation error: more than one X-Frame-Options item presented in the response headers.

To understand the error, imagine making a request to http://foo.org and getting the following response headers with two X-Frame-Options fields:

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-FRAME-OPTIONS: SAMEORIGIN

Set-Cookie: JSESSIONID=E0BF8BA2829148A9D3C5370FB2A03820; Path=/; HttpOnly

X-FRAME-OPTIONS: SAMEORIGIN

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

When more than one X-Frame-Options item is used, browser engines will combine the multiple header fields into one by appending each subsequent field-value to the first when multiple message-headers fields with the same field name according to the HTTP RFC 2616 section 4. It means browser engines will modify the previous response header into the following format.

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Set-Cookie: JSESSIONID=E0BF8BA2829148A9D3C5370FB2A03820; Path=/; HttpOnly

X-FRAME-OPTIONS: SAMEORIGIN, SAMEORIGIN

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

According to RFC7034, only these three values, DENY, SAMEORIGIN and ALLOW FROM are valid values and they are mutually exclusive; that is, the header field must be set to exactly one of these three values. Some browsers will take the header item "X-Frame-Options: SAMEORIGIN, SAMEORIGIN" as invalid because the field value "SAMEORIGIN, SAMEORIGIN" is not any of the three values. As a consequence, the X-Frame-Options feature will not be effective in some browsers, such as Safari browser (6.0.5) and an attacker could launch clickjacking attacks against the victim when they are using an older version Safari browser to view the website. I have tested this with Safari (5.1.7) on a Windows machine and Safari 6.0.5 on Mac. Although Safari 7 (tested with Safari 7.1.7) has fixed this issue, it still imposes a danger if the user is using old Safari browsers.

How Common Are X-Frame-Options Implementation Errors?

I did some extra research on the Alexa Top 20 after deciding to write this article in order to check whether this kind of implementation error could also happen to some popular and big websites or if this is just a small issue caused by inexperienced developers. The result was surprising. I found out that several domains from one website in the Alexa Top 20 suffered from this error.

After some investigation, I found I could launch an attack using this vulnerability, and I am sure damage could be done if an attacker combined an attack against this vulnerability with some social engineering work. I've informed the owners of the vulnerable website, and they are working on mitigations.

Root Cause of the Implementation Error

Multiple reasons could lead to this kind of implementation errors. From the feedback of our customers that are suffering from these mistakes and my own developing experience, these two conditions will cause the more than one X-Frame-Options in the response header:

Condition 1: X-Frame-Options header is added in the source code and got deployed again in apache, IIS server

Condition 2: X-Frame-Options header is added in the source code or configure in apache/IIS server, meanwhile, load balance set "x-frame-options" again in its policy

For those in charge, I would advise them to check whether the response headers contain more than one X-Frame-Options headers if they are deploying X-Frame-Options to protect against a clickjacking attack.