Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different to what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous webpages.
Simply put, don’t believe on whatever you click now-a-days in any unknown or malicious sites. I(along with Aditya Gupta and Subho Halder) have found some interesting clickjacking attacks in Google itself. Well they have now corrected the User Interface and also added the necessary header to avoid clickjacking.Cheers to our efforts :P
Well the question is WHAT IS CLICKJACKING?
A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers load another page over it in a transparent layer. The users think that they are clicking visible buttons, while they are actually performing actions on the hidden page. The hidden page may be an authentic page, therefore the attackers can trick users into performing actions which the users never intended. There is no way of tracing such actions to the attackers later, as the users would have been genuinely authenticated on the hidden page.
So how to AVOID it?
The first possible solution which comes to our mind is how to disable other sites from “iframing” your content, now there are different possible solutions for that
Solution 1:
Using a javascript framebusting code, which checks if the page is loaded inside a frame or not, if it is loaded, it quietly redirects to the parent page, an example code :
if (top != self) { top.location.replace(self.location.href); }
Excellent! Now you “bust” or break out of any containing iframe automatically. Except for one small problem.
As it turns out, your frame-busting code can be busted :
This code does the following:
increments a counter every time the browser attempts to navigate away from the current page, via the window.onbeforeonload event handler
sets up a timer that fires every millisecond via setInterval(), and if it sees the counter incremented, changes the current location to a server of the attacker’s control
that server serves up a page with HTTP status code 204, which does not cause the browser to navigate anywhere
Well lets look at other options
Solution 2:
One of the more viable solution is the X-FRAME-OPTIONS header that allow a site to control whether its content can be within a frame. There are two settings to this header, DENY blocks the content from being in a frame and SAMEORIGIN only allows the content to be framed by pages within the same origin. While it is not the end all and be all of clickjacking solution and won’t work in some sites that extensively use frames across multiple sites, it is considered as a more reasonable approach for sites to protect their own content.
What is it good for?
Originally is was intended as a way to prevent clickjacking.
To understand clickjacking, let’s first look at Cross Site Request Forgery (CSRF). CSRF is abusing the ability of browsers to interact with multiple servers at the same time. So you’re logged in into your bank and the attacker tricks you in clicking on a link that send him some money.
good websites protect themselves from this by e.g. using request tokens to make sure the request being received is intentional.
Many websites are vulnerable to various forms of CSRF, some even argue the majority of websites that interact with users are vulnerable somewhere.
Clickjacking is a way to trick visitors into interacting with a victim website without the user knowing he’s doing it by e.g. overlaying other things such as images over the elements.
Framebusting is a common technique to prevent clickjacking, sadly framebusting can be defeated.
x-frame-options was introduced in a beta release of IE8 as an alternative.
So what is x-frame-options?
It’s a HTTP response header.
HTTP, not HTML!
It can be used to prevent framing of the pages that are delivered to browsers in the browser: the browser simply refuses to render the page in a frame if the header is present dependign on the set value.
Values are
DENY: Stops all framing
SAMEORIGIN: Stops framing except for the same website that delivered the page itself. (Allowing http://www.example.com/ to frame pages served from http://www.example.com/ with x-frame-options set to this value)
What does it not do?
It doesn’t protect your web site from being a victim from clickjacking as by far not all browsers support it. E.g. Microsoft neglected to backport it to still widely popular IE6 and IE7 browsers.
So you still need all the other measures too.
Note that it’s something that doesn’t need javascript, has little odds of being defeated by smart attackers as long as the browser supports it, so it’s not without merit.
Alternative to framebusting ?
Since the x-frame-options is in the security world an additional measure somewhat similar to where framebustng could be used, isn’t it also an alternative to framebusting in other web master areas ?
Sure it is: just remember that instead of taking over the entire tab, the browser will not render it at all. And your regular framebusting javascript has no chance as it’ll not get loaded if the browser support this.
Browsers that support it
IE8
Safari
Chrome
Firefox with the NoScript addon
It’s not backported to IE6 and IE7
How to send out the header using IIS?
Open the Internet Service Manager
HTTP headers tab
in the Custom headers section: Add…
Custom header Name: x-frame-options Custom header Value: "DENY" or "SAMEORIGIN" (without the quotes).
Can anybody confirm/correct this (I don’t run IIS) ?
How to send out the header using apache
Add this to your httpd.conf:
header always append x-frame-options SAMEORIGIN
So we get a fair idea about what does it mean when someone shouts out, “I Clickjacked You ”
