Clickjacking security vulnerability
Jul. 22nd, 2017 12:26 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dennisgorelikCouple of years ago security pen testers found clickjacking bug in Google API Explorer:
===
https://threatpost.com/google-patches-clickjacking-bug/112568/
Google did pay out a $1,337 bounty
“The idea behind the exploit is to frame the page where that button was, and make the frame transparent.”
===
Demo
Here is the demo of how highjacking setup page looks like:
But if you click "Log in" (or replace "https://www.wikipedia.org" with "https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Test" in the demo html above) - you would notice that Wikipedia login page is not rendered in the iframe.
How did Wikipedia do that?
I opened Fiddler2 debuggin proxy and found out that "https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Test" renders this HTTP header:
How to prevent clickjacking?
Extra experimenting showed that google.com, twitter.com and indeed.com use "X-Frame-Options: SAMEORIGIN"
facebook.com uses "X-Frame-Options: DENY" (the same as Wikipedia login page).
--------
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
There are three possible directives for X-Frame-Options:
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/
--------
What is the best practice for using "X-Frame-Options"?
I am trying to decide what "X-Frame-Options:" should I use for postjobfree.com
Does the flexibility of iframe worth the security risk?
Should we support web site that include postjobfree.com content into their own iframe?
Such iframe support has both cons and pros...
Why secure option is not a default choice in browsers?
What do you think, why browsers (such as Google Chrome and Firefox) do not assume "X-Frame-Options: SAMEORIGIN" by default?
If allowing loading your page content into parent iframe is inherently insecure, then such a risky behavior should be explicitly requested, right?
===
https://threatpost.com/google-patches-clickjacking-bug/112568/
Google did pay out a $1,337 bounty
“The idea behind the exploit is to frame the page where that button was, and make the frame transparent.”
===
Demo
Here is the demo of how highjacking setup page looks like:
<html>
Hijacker's web site content that invites user to click somewhere:
<p><input type="button" value="Click to see cats' videos"></p>
<style>
iframe {
width:600px;
height:600px;
position: absolute;
top: 0; left: 0;
filter: alpha(opacity=50);
opacity: 0.50;
}
</style>
<iframe src="https://www.wikipedia.org">
</html>Note that Wikipedia's security team made a conscious choice to allow clickjacking of their home page, because there is nothing at risk there.But if you click "Log in" (or replace "https://www.wikipedia.org" with "https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Test" in the demo html above) - you would notice that Wikipedia login page is not rendered in the iframe.
How did Wikipedia do that?
I opened Fiddler2 debuggin proxy and found out that "https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Test" renders this HTTP header:
X-Frame-Options: DENYBut "https://www.wikipedia.org" page does NOT render that header.
How to prevent clickjacking?
Extra experimenting showed that google.com, twitter.com and indeed.com use "X-Frame-Options: SAMEORIGIN"
facebook.com uses "X-Frame-Options: DENY" (the same as Wikipedia login page).
--------
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
There are three possible directives for X-Frame-Options:
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/
--------
What is the best practice for using "X-Frame-Options"?
I am trying to decide what "X-Frame-Options:" should I use for postjobfree.com
Does the flexibility of iframe worth the security risk?
Should we support web site that include postjobfree.com content into their own iframe?
Such iframe support has both cons and pros...
Why secure option is not a default choice in browsers?
What do you think, why browsers (such as Google Chrome and Firefox) do not assume "X-Frame-Options: SAMEORIGIN" by default?
If allowing loading your page content into parent iframe is inherently insecure, then such a risky behavior should be explicitly requested, right?
