Advanced Clickjacking Attacks

Date: 2016-12-08 10:43:15

It is often assumed that allowing a site to be framed only has minor security implications. Clickjacking in particular is often associated with low-impact issues such as stealing Facebook likes.

This article will show that allowing a site to be framed may be a more potent attack vector than often assumed. Framing makes some vulnerabilities easier or more realistic to exploit. Clickjacking can be used for more than just stealing likes, and in some contexts Clickjacking can gain the full power of CSRF - albeit with more user interaction.

1. Basic Information on Clickjacking

When performing a Clickjacking attack, an attacker frames the vulnerable application in an iframe. The goal is to get a victim to click on elements of the application that is loaded in the frame, thus performing actions in the context of the vulnerable application without the victims knowledge.

To get a user to click, an attacker would overlay the framed content with their own content which would deceive the user into clicking on the overlay, resulting in clicks on the framed application.

2. Clickjacking: Not just for stealing likes

While the stealing of likes is a good example to explain Clickjacking, there are many other possible attack vectors. Everything that can be managed by just clicking is affected if the application is vulnerable.

All elements that can be operated solely via mouse are affected, which may include drop-downs as well as checkboxes and radiobuttons.

For example, changing the status of a user - eg normal user, moderator, or admin - may only require three clicks: Opening a drop-down menu, selecting the appropriate status, and finally submitting a form.

Permission management may also be implemented via simple checkboxes which can be used to add or revoke permissions and which do not require any further interaction.

3. Exploitation of other vulnerabilities via Framing

Allowing framing isn't just a vulnerability by itself as it enables Clickjacking, it also makes exploitation of other vulnerabilities easier.

By allowing a page to be framed, it is possible to perform multiple POST requests to an application across origins, which can for example be used in multi-stage CSRF attacks or in the exploitation of CSS injections .

4. Submitting Text via Clickjacking

Some browsers allow dragging and dropping content into a framed website, thus making it possible to submit text via Clickjacking. This means that Clickjacking now has the full power of CSRF. It is therefore possible to exploit self-XSS vulnerabilities, or to submit arbitrary content as the targeted user - for example adding a new admin user if the victim is able to perform this action.

Performing actions via Clickjacking does require more user interaction than a simple CSRF attack. For each text field that needs to be filled, it generally requires two to three clicks to highlight the text, a drag and drop to place the text into the framed vulnerable application, and a final click to submit the form.

Firefox is an example of a browser that is affected by this, while Chrome is not. It should be noted that while Firefox allows dragging text into frames, it does not allow dragging text out of frames, thus making it impossible to steal secret information from a framed site.

Attacking a vulnerable site is easy. An attacker simply places the text they wish the user to submit on their website in addition to the framed vulnerable page. In a real world attack, the text as well as the frame would be hidden under an overlay that leads a victim to perform the desired actions. This may be a simple game, or an application that pretends to require these clicks.

5. Defenses against Clickjacking

There are currently three different approaches to defend against Clickjacking:

1. Content Security Policy (CSP)
2. X-Frame-Options (HTTP Header)
3. Frame-Breaker Script (JavaScript)

Currently, the best defense is to use the X-Frame-Options header. While this is an experimental header, it is supported by current versions of all major browsers. The header can either be set to DENY to deny all framing, or to SAMEORIGIN to allow framing from the same origin. The ALLOW-FROM header which allows one specific origin to frame the page is not supported by all browsers.

As X-Frame-Options was never a formally defined standard, it is recommended to additionally use the Content Security Policy (CSP) header to provide protection in the future and to gain more fine-grained control over which sites are and are not allowed to frame a page. It should be noted that CSP level 2 which contains the required frame-ancestors property is not currently supported by all common browsers. Internet Explorer for example does not support it. Because of this it is strongly recommended to not solely rely on CSP to defend against Clickjacking.

If older browsers that do not implement the CSP or X-Frame-Options header need to be supported - for example Internet Explorer 7 - it is recommended to use a frame-breaking script which prevents the framing of a page.