How does just putting a site link in an iframe (and when opens in iframe) indicate that the site is vulnerable to a click jacking attack? I have also read that if the site is a forum base, then the vulnerability could be critical. Why? please provide some examples if possible.
4 Answers
Yes, you're right to question this.
A site being vulnerable to clickjacking and the vulnerability actually being exploitable are two different things.
Bhuvanesh discusses a small subset of clickjacking attacks in their answer. This type of clickjacking is mentioned in the OWASP article:
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.
This type of clickjacking may apply for sites that employ 3-D Secure or Verified By Visa to ask for your secret banking password within an IFrame. The outer website could carefully position their own textboxes in order to capture your password. However, this is not what is normally meant by a clickjacking attack or vulnerability.
Bhuvanesh's answer is correct in that the Same Origin Policy would stop an IFrame being generated in your own site from another origin. However, it would not stop another site from framing your site in its own webpage. It is this use case where most sites are vulnerable to clickjacking. This is essentially what a clickjacking attack is. The attacker loads your page on your domain in an IFrame, but uses CSS to make your page invisible. The attacker positions their own buttons under your page. When these buttons are clicked by the victim, the browser actually sends the clicks to your site.
An example - your site is example.com
:
- Say you had a page called
confirmDeleteAccount.php
with a button in the middle. - The attacker makes an IFrame on their site to yours:
<iframe src="http://example.com/confirmDeleteAccount.php"></iframe>
- CSS is used to size and position the IFrame, and to make it invisible.
- The attacker's code positions a button on their own page, right under the
I confirm I want to delete my Example.com account
button on your page loaded in the IFrame. Because the IFrame is invisible, the attacker's button appears to the victim to be the only one visible. - The attacker's code sets makes their button say
Click here to claim your free holiday
. - The victim clicks what she thinks is the attacker's button, however as the page has the IFrame containing your site above the button, the victim is really clicking your button to delete their account.
Setting X-Frame-Options
appropriately will prevent your site being framed (note this has now been replaced by CSP's frame-ancestors
, however both are advisable for now as not all browsers yet support frame-ancestors
).
Do I need to set X-Frame-Options
/ frame-ancestors
?
The above example shows an exploitable clickjacking vulnerability. Clickjacking is only a concern on your site if there are any single click buttons that have consequences. So there are two requirements for a clickjacking vulnerability to be exploitable:
- You have a frameable page (i.e. no
X-Frame-Options
/frame-ancestors
). - You have a page that can be interacted with via mouse actions only, that results in an undesirable outcome for the user or advantages the attacker in some way.
So therefore, if you have a page that requires user input and it is not possible for the attacker to supply that user input, then that page would not be exploitable. If however, the form on the page is completed by query string values or by POST data, then the attacker would have a method in which to supply the data for the attack.
It can be complicated to work out whether your site is exploitable or not, without taking into account every page on your site and what data is supplied to it and from where. Therefore, many security assessments and penetration tests tend to report that your site is vulnerable if these headers are missing. My advice is usually that unless your site needs to be framed as part of its functionality, then always add the headers. It is also good to set these headers to mitigate other vulnerabilities such as path-relative stylesheet import (PRSSI), Cross Site History Manipulation (XSHM) or framesniffing.
More information: Clickjacking: Help, I Was Framed! (SANS AppSec Blog).
Imagine facebook could be placed in an iframe. I could make a webpage with a button that says "win free bicycle!", and above that place a transparent iframe with my facebook page so that the like button is exactly above/covering the "win free bicycle!" button. If somebody clicks on that button, he will not win a bicycle, but he will instead like my facebook page without noticing it.
Imagine you have a simple login form and a submit button. The submit button sends the credentials to the server.
The attacker can load this login page inside of an iFrame, and then after creating a similarly styled login form like the original page, positions the new one over the original one on your page. After they get the data, they submit it manually and attempt to hack the account.
The Stanford Web Security Research have figured Smart ways to counter this :
https://www.codemagi.com/blog/post/194
And you can find more examples here :
Actually Click jacking is not just loading an iframe into your website.It is just a test to show that your site is vulnerable to Click jacking.
Nowadays modern browsers won't allow this testing too,because browsers like Chrome,IE,Firefox follows Same-origin-policy which won't allow loading an iframe into your website.
You can try from your localhost for this vulnerability. But you have to exploit some thing by loading an iframe into your website for example you have to change the password of a user without the knowledge of the user by asking them to click Offer for you. You can refer this link for how click jacking works Click Jacking
You can also refer OWASP top ten projects for this vulnerability.OWASP Click jacking