A very common issue seen in vulnerability scan reports and to an extent, on Penetration Tests. The risk posed by clickjacking varies by who you talk to. For example, Hacker1 say it isn’t important at all and can be ignored. We believe that as a vulnerability, it is simply stupid to ignore it. Especially as the fix is a single line in a configuration file.
So what exactly is clickjacking? Clickjacking is an attack that occurs when an attacker uses a transparent iframe in a window to trick a user into clicking on a CTA, such as a button or link, to another server in which they have an identical looking window. The attacker in a sense hijacks the clicks meant for the original server and sends them to the other server. This is an attack on both the visitor themselves and on the server.
Here are a couple of possible known exploits or uses for clickjacking.
- Tricking users into making their social networking profile information public
Sharing or liking links on Facebook
- Clicking Google Adsense ads to generate pay per click revenue
- Making users follow someone on Twitter or Facebook
- Downloading and running a malware (malicious software) allowing to a remote attacker to take control of others’ computers
- Getting likes on Facebook fan page or 1 on Google Plus
- Playing YouTube videos to gain views
Clickjacking is easy to implement, and if your site has actions that can be done with a single click, then most likely it can be clickjacked. It might not be as common as cross-site scripting or code injection attacks, but it is still another vulnerability that exists. Sometimes it helps to see a visual. Below is a clickjacking demo using both transparent and non-transparent iframes.
Here is another good live example in which you can see a demonstration of clickjacking.
The X-Frame-Options header has three different directives from which you can choose. These must be sent as an HTTP header, as the browser will ignore them if found in a META tag. It is also important to note that certain directives are only supported in certain browsers. See browser support further below in this post. While it is not required to send this response header across your entire site, it is best practice to at least enable it on pages that need it.
The deny directive completely disables the loading of the page in a frame, regardless of what site is trying. Below is what the header request will look like if this is enabled.
This might be a great way to lock down your site, but it will also break a lot of functionality. The following two directives below are more common use cases for a typical website.
Examples of sites currently using the deny directive:
The sameorigin directive allows the page to be loaded in a frame on the same origin as the page itself. Below is what the header request will look like if this is enabled.
We have the sameorigin directive enabled on this website. With this directive enabled, only our website is allowed to embed an iframe of one of our pages. This is probably the most commonly used directive out of the three. It is a good balance between functionality and security.
It is also important to note that if a browser or plugin can not reliably determine whether the origin of the content and the frame have the same origin, this must be treated as denied.
Examples of sites currently using the sameorigin directive:
ALLOW-FROM URI directive
The allow-from URI directive allows the page to only be loaded in a frame on the specified origin and or domain. Below is what the header request will look like if this is enabled.
X-Frame-Options: allow-from https://www.example.com/
This allows you to lock down your site to only trusted origins. But be careful with this directive. If you apply it and the browser does not support it, then you will have NO clickjacking defence in place.
Enabling X-FRAME-OPTIONS header
The X-Frame-Options header is easy to implement and only requires a slight web server configuration change. You might also want to check to make sure you don’t already have the header enabled. Here are a couple of easy ways to quickly check.
Open up the Network panel in Chrome DevTools and if your site is using a security header it will show up on the Headers tab.
x-frame-options google chrome
Another quick way to check your security headers is to quickly scan your site with a free tool, securityheaders.io, created by Scott Helme. This gives you a grade based on all of your security headers and you can see what you might be missing.
Enable on Nginx
To enable the X-Frame-Options header on Nginx simply add it to your server block config.