Log in

No account? Create an account
22 July 2017 @ 12:26 pm
Clickjacking security vulnerability  
Couple of years ago security pen testers found clickjacking bug in Google API Explorer:
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.”

Here is the demo of how highjacking setup page looks like:
Hijacker's web site content that invites user to click somewhere:
<p><input type="button" value="Click to see cats' videos"></p>
iframe { 
position: absolute;
top: 0; left: 0; 
filter: alpha(opacity=50); 
opacity: 0.50;
<iframe src="https://www.wikipedia.org">
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: DENY
But "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).
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?

Originally posted at: http://dennisgorelik.dreamwidth.org/136194.html
Валерий Крылов: flowjusty_tylor on July 23rd, 2017 08:47 pm (UTC)
Best practice: X-Frame-Options: DENY
You can change it to SAMEORIGIN (if you find any use for it in postjobfree) or ALLOW-FROM [...] (if you need specific pages to be shown in iframe on partner sites), but that's not likely. The only use I see for iframes in modern web is for identification or payment providers.

About security:
Like in earlier case of cross-domain img tags creators of this feature were not thinking about integrity or security. As usual.
Dennis Gorelikdennisgorelik on July 23rd, 2017 11:14 pm (UTC)
Actually there is one case when allowing rendering in iframe may be attractive.
That is an aggregator, that renders jobs from PostJobFree.com in iframe and allows job seekers to apply for these jobs in iframe.
This jobs inclusion in iframe is somewhat appealing (because of extra applications we receive), but it is also not clean from usability perspective: job seekers would be a little bit confused about what web site they are actually use.
So, even without security considerations, the usability of such iframe inclusion is questionable.

I still did not make up my mind, but it is likely that we would render "X-Frame-Options:SAMEORIGIN" on every page for these reasons:
1) The same approach everywhere - to keep code consistent and simple.
2) SAMEORIGIN - because occasionally we use iframe ourselves to dynamically load extra information, such as on search input pages (https://www.postjobfree.com/search-jobs) and alert editor pages (https://www.postjobfree.com/job-alert).
Валерий Крылов: flowjusty_tylor on July 24th, 2017 09:09 pm (UTC)
Yes, in this case SAMEORIGIN is a good choice.
Dennis Gorelikdennisgorelik on July 24th, 2017 09:12 pm (UTC)
Thank you.
Yaturkenzhensirhiv - a handheld spy: Веселый носорогyatur on July 24th, 2017 02:31 am (UTC)
Can you elaborate? How would you use iframe for identification? I dealt with authentication/authorization quite a lot, and I am not sure what scenario you have in mind.

I have never interacted with payment providers, so this one may be obvious, but how does one use iframe for that?

In both cases, a pointer to an example site would be enough, or a general description of the idea, I am not looking for a how-to.
Валерий Крылов: flowjusty_tylor on July 24th, 2017 09:21 pm (UTC)
Recent example:
I'm paying for phone/internet services with a credit card. After entering card info service provider shows iframe from bank, where I can enter confirmation code from SMS to complete payment process.