Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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
1  
What exactly in my log will tell me about clickjacking request? –  Paul Podlipensky Jul 19 '12 at 22:24

2 Answers 2

up vote 5 down vote accepted

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 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.

share|improve this answer
    
I wrote small clickjacking techniques overview as well as defense options: podlipensky.com/2012/07/clickjacking-explained –  Paul Podlipensky Jul 24 '12 at 0:14

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

share|improve this answer
    
Real-time is the best, because its the shortest time versus spammers, so its one of the best protections. –  Andrew Smith Jul 19 '12 at 23:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.