12

I'm aware of modern anti-clickjacking approaches, such as X-Frame-Options header or framekiller scripts. But all these tactics prevent content to be inside iframe. But what if there is a requirement for content to be in iframe, such as Twitter "Follow" button or Facebook "Like" button? How to protect such iframes from clickjacking?

Manishearth
  • 8,237
  • 5
  • 34
  • 56
Paul Podlipensky
  • 2,837
  • 4
  • 21
  • 25
  • For this you require automation - auth server, and clickjacking monitoring, so with every request, you check on the auth server if the page / request is allowed (some you might disable, and require token), and also detect clickjacking referers based on logs. It is because you want both iframe and no clickjacking. – Andrew Smith Jul 19 '12 at 22:08
  • 1
    How can I distinguish clickjacked request from normal one? – Paul Podlipensky Jul 19 '12 at 22:14
  • You can detect new referer and block it. As for facebook. But I for myself issue tokens, so each website does copy-paste of the code (javascript), which has token inside, which grants access to the html page. And I can revoke tokens. This does perfectly what you want to do. Problem is that each website has to have the code snippet on their site with token installed, so if there isnt one, one has to upgrade it and issue them. – Andrew Smith Jul 19 '12 at 22:20
  • So you need to find out which referer is clickjacking, and revoke their tokens. And if you ask which one is clickjacking, by log analysis, and website monitoring. – Andrew Smith Jul 19 '12 at 22:22
  • I got idea about tokens, but still can't understand how to detect clickjacking in first place. Let's say some publisher registered on my website and received script to place on the page with token. In addition publisher allows third-party javascript to run on his page, so the script do clickjacking attack for each second user who visit the page. How can I distinguish clickjacked user's requests from normal user's requests? – Paul Podlipensky Jul 19 '12 at 22:23
  • 1
    What exactly in my log will tell me about clickjacking request? – Paul Podlipensky Jul 19 '12 at 22:24
  • You can read the referer and download the original website, and perform statistical analysis on the learned database of clickjacking websites. And just ban the referers which you find out being clickjacking. – Andrew Smith Jul 19 '12 at 22:26
  • You mean that I have to manually go to website, try to click somewhere and figure out that the request is clickjacked? Doesn't sound like a good solution... In the wild such publishers may register thousand websites a day, there is no way to check all of them manually! – Paul Podlipensky Jul 19 '12 at 22:33
  • But you can run automated script which does a check, e.g. it can statistically detect the domain name, and once the clickjacking site is detected, it is blocked. More data you got, the better check. It could even check the domain registration details via whois or EPP. – Andrew Smith Jul 19 '12 at 22:44
  • Are you aware of any such automated scripts? What exactly do they check on the page? Do they emulate user's mouse and behavior? I think publisher could implement bot-detection logic and prevent the script to figure out any problems on the page... – Paul Podlipensky Jul 19 '12 at 22:49
  • I am afraid that the domain and page statistical analysis would have to be coded, as well whois and RBL checks for the domains. However there are many web proxy firewalls which does the same. If you check referers against anti-spam, anti-phishing etc real-time databases that should help a lot. Just like antivirus does. These proxies are called web application firewall and would require function to check the referers against RBL and threat database, so I think it would be easier just to do it. – Andrew Smith Jul 19 '12 at 23:02

2 Answers2

5

Share buttons will often use an iframe to protect them selves from CSRF. In this context CSRF and ClickJacking have an identical impact which is sometimes called "LikeJacking". You have to choose to be vulnerable to CSRF OR you can use an iframe prevent CSRF but then you expose your self to ClickJacking. It so happens that ClickJacking is the lesser of two evils. FaceBook solves this logic problem with Legal Action. You can make "LikeJacking" and ClickJacking against your Terms of Service and sue them like FaceBook.

There maybe a technical solution to this problem. I emailed Google Security on this topic and they said that they where using "Signal Analysis" to determine if behavior was taking place. Which is a pretty gaseous answer to say the least. Being Google they do spider all of the pages that are liked, and they could determine if a clickjacking method, such as an SVG mask was applied to their iframe by the parent page. But this is just speculation.

rook
  • 46,916
  • 10
  • 92
  • 181
-1

You might want to check with one of the DNSBLs. Some of them have URLs found in spam email messages. I cant advice which particularly one has the best database, but you can google for online DNSBL check and see the offending websites if they are there. Such check can be done real-time during page execution.

URI DNSBLs A URI DNSBL is a DNSBL that lists the domain names and IP addresses which are found in the "clickable" links contained in the body of spams, but generally not found inside legitimate messages. URI DNSBLs were created when it was determined that much spam made it past spam filters during that short time frame between the first use of a spam-sending IP address and the point where that sending IP address was first listed on major sending-IP-based DNSBLs. In many cases, such elusive spams contain in their links domain names or IP addresses (collectively referred to as a URIs) where that URI was already spotted in previously caught spam and where that URI is not found in non-spam e-mail. Therefore, when a spam filter extracts all URIs from a message and checks them against a URI DNSBL, then the spam can be blocked even if the sending IP for that spam has not yet been listed on any sending IP DNSBL.

http://en.wikipedia.org/wiki/DNSBL

Andrew Smith
  • 1
  • 1
  • 6
  • 19