Stephen Sclafani

Clickjacking & OAuth

May 4th, 2009

This post details clickjacking and how it poses a serious security threat to OAuth service providers.


Clickjacking is when a visitor to a web page is tricked into clicking on an element that they believe to be harmless when in reality they are clicking on an element on a different website that exposes protected data or grants an attacker access. There are a number of ways to implement a clickjacking attack, but the most common way is to load the target website in a transparent iframe. The iframe is then positioned so that the target element that the attacker wishes a visitor to click on is positioned over a dummy element on the page that the iframe is contained on. Because the iframe is given a higher stack order than the dummy element, when a visitor clicks on the dummy element they are actually clicking on the hidden transparent element.

You can read more on clickjacking from Robert Hansen and Jeremiah Grossman here.


In 3-legged OAuth as the result of an action taken by a User a Consumer requests a Request Token from the Service Provider and then passes that Request Token to the Service Provider’s Authorization URL through redirection. The Service Provider then displays a page prompting the User to approve or deny the Consumer access.


In this example Faji is the Service Provider and Beppa is the Consumer. If Beppa’s developers were malicious they could use a clickjacking attack against Faji’s approval page to trick users into granting their application access.



From the user’s perspective the link appears to be harmless, but in reality when clicked on will grant Beppa access.

This is a basic example, however with a little social engineering it becomes trivial to get a user to click on the dummy element and have the attack go undetected.


There are two solutions to protect against clickjacking each with its own issues.

Service providers can use frame busting scripts to prevent their approval page from being framed. However, due to Internet Explorer’s support of a security=”restricted” attribute on frames they can be disabled in IE. For IE8 Microsoft has announced the support of a X-Frame-Options HTTP response header which can be used by service providers to deny their approval page from rendering in a frame. However IE8 is not yet widely used. One workaround is to require that Internet Explorer users have javascript enabled, however this comes with its own set of issues.

Service providers can require that users authenticate themselves before being shown the approval page, even if they are already signed in to the service. By doing so it becomes impossible for their approval page to be framed since a user’s credentials are not known to Consumers. This can be an inconvenience for some users, however, but more importantly by conditioning users to enter their credentials each time they are redirected from a Consumer it can increase the potential of phishing attacks. Service providers that choose this solution should educate their users about phishing attacks and should provide mechanisms that make it easier for users to confirm the authenticity of their site.


At the time of this post all service providers had been notified.