Why am I anxious about Clickjacking?

Oh – Whoa! My web application is secured from OWASP top ten exploits (XSS, SQLI, and HTTP Request are secure etc.). Uh, should I worry about how my website reacts to user clicks? Nah, I assume my website is secured. So no need to worry. Hey Mr. Bob – this is your in force myth.

What is Clickjacking?
Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages (OWASP Wiki).
There is one popular attack – cross-site request forgeries (CSRF) that can interact with functions on other websites. Unknown HTTP requests are raised and successfully executed at other website operation. Like Attacker.com is able to ‘Like’ or ‘Share’ post on yourfavoritesocialnetwork.com.
The principal defense against CSRF is to create one-time tokens that are placed on the request and validated before perform business logic operation. This ensures that the browser doesn’t pick up the ‘Invalid Request’ using a random token. There is also a same origin policy which forbids any other domain from performing the CSRF attack.
Clickjacking is bypassing the same origin policy with UI redness. The malicious site tricks a user into clicking on a masked element of another site which they have loaded in a hidden iframe – and BOOM!

An example of Clickjacking
Suppose a social networking website has a page where a logged in user can click ‘Like’ or ‘Share’ post for liking or sharing the post.
The user has chosen to stay logged-in to the social website all the time for convenience. An attacker site might create a ‘Win an IPhone’ button on one of their own pages, and load the social networking website’s page in a transparent iframe such that the ‘Like’ or ‘Share’ button is invisibly overlaid on the ‘Win an IPhone’ button. If the user visits the attacker’s site, clicking on ‘Win an IPhone’ will cause an inadvertent click on the ‘Like’ or ‘Share’ button and an unknowingly sharing or liking of the social media post.
With clickjacking, attackers can trick logged-in Facebook users to arbitrarily like fan pages, links or groups.

Screen 1:-

ClickJacking1
Freebies are always welcome, so usually people click on the big button and there you go! You’ve just been clickjacked. You see, whilst you think you just clicked on a ‘WIN’ link, in reality you just clicked on this instead:

Screen 2:- ‘Like’ or ‘Share’ Post
ClickJacking2
And this apparently is posted on your social media profile and to your social network.
When you are logged-in, your social media profile provides a vulnerable option to ‘Like’ or ‘Share’ posts with a single click. But, of course, you don’t know that you’ve just liked and shared some nasty stuff – Bang.
Below are very sample POC of a clickjacking attacks:-

ClickJacking3

Code: – <iframe src= https://testingcircus.com> </iframe>
Live Demo: – http://goo.gl/6gEq2I
Clickjacking Testing tool: – http://goo.gl/27VgQb

Issue resolution
Developers should always review the application functions that are generating a response, and determine whether they can be used by application users to perform any sensitive actions within the application. If so, then a framing attack targeting this response may result in unauthorized actions.
Modern browsers support the X-Frame-Options HTTP header that indicates whether or not a resource is allowed to load within a frame or not. If the response contains the header with a value of SAMEORIGIN, then the browser will only load the resource in a frame if the request originated from the same site. If the header is set to DENY, then the browser will block the resource from loading in a frame, no matter which site made the request.

X_FRAME_OPTIONS = ‘DENY’ E.G.:-Google / Facebook / Twitter does the same.
ClickJacking4
Or simple JS Code:-
<Script>
If (top != window)
top.location = window.location
</script>
This JS snippet isn’t a reliable solution as this can be bypassed by disabling JavaScript.

Summary
Clickjacking is easy to implement, if there is an action on your site that can be done with a single click – it may be clickjacked. This redressing is a serious attack that can have awful effect. This attack can Bypass CSRF protection, but can only inject Clicks, not Data.
An attacker can ensure that the visitor is logged-in to your site by social engineering. Or on some sites, it is possible to send a message to a user with the “Happy Link”. The user will open the mail and click on it, and be landed at clickjacked webpage.
Many scenarios are possible for clickjacking. That’s why it’s recommended that you use the X-Frame-Options at web pages which are not meant to run into a frame.

Glossary
OWASP – The Open Web Application Security Project
SQLI – SQL Injection attack
XSS – Cross side scripting exploit
CSRF – Cross Side Request forgery

 

 

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/ClickJacking.png?fit=505%2C306&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/ClickJacking.png?resize=150%2C150&ssl=1Abhinav SejpalArticlesArticles,ClickjackingWhy am I anxious about Clickjacking? Oh – Whoa! My web application is secured from OWASP top ten exploits (XSS, SQLI, and HTTP Request are secure etc.). Uh, should I worry about how my website reacts to user clicks? Nah, I assume my website is secured. So no need to...