‘Clickjacking’, if you haven’t heard of it, is a method used by malicious individuals to trick users like you into clicking something without you knowing what you’ve clicked. It’s also known as UI-redressing and only works in browsers that support frames/CSS.
The idea is simple: An iframe is positioned above what looks like a clickable button on a website. This iframe is invisible to the user (opacity:0) and so the user unknowingly clicks on the iframe which may contain anything! This can be achieved through CSS alone, no JavaScript is required. A variation of this technique involves the use of JavaScript to move the iframe around the screen inline with the user’s cursor, therefore achieving the same thing but without having to convince the user to click on a button.
Background info
I believe the original concern was related to Flash and how a user could unknowingly enable their webcam and microphone so the attacker would have access. There are some other examples shown here: http://www.grc.com/sn/notes-168.htm.
Adobe resolved this issue in October of last year with a new release of Flash Player. Obviously this only offers protection for that particular exploit – gaining access to webcam/microphone; other more rudimentary techniques still work perfectly today.
The only solid form of protection I’ve heard of (other than disabling CSS) is the NoScript addon for Firefox. Even though clickjacking is fundamentally unrelated to JavaScript the team behind NoScript went the extra mile and developed a pretty cool way of detecting it; a module named ‘clearClick‘ which will compare a screenshot of the currently viewed page against a screenshot of the same page but with frames at full opacity. If you’re not using Firefox you could try disabling iFrames (if your browser lets you), or, alternatively, you could install a user-scripting plugin and get rid of all iframes via a script. Here are some non-Firefox GreaseMonkey emulators:
- IE: Trixie or GM4IE
- Safari: Creammonkey
And here’s a script you could use:
var all = document.getElementsByTagName('iframe'), l = all.length; while (l--) all[l].parentNode.removeChild(all[l]); |
Clickjacking Twitter
THIS NO LONGER WORKS (as of ~6:45 PM, 12/Feb’09), TWITTER HAS IMPLEMENTED A FRAME-BREAKING SCRIPT » This is a good thing! 🙂
Using the basic technique of positioning an iframe over a button coupled with Twitter’s ‘status’ URL parameter I have created a small demo which shows you just how serious (and annoying) this could be!
It will only work if you’re currently logged into Twitter (and if you haven’t got any of the above measures in place):
- Go to Twitter, make sure you’re logged in.
- Go to this page: qd9.co.uk/temp/ClickJackEg.html
- Click the button.
- Wait about two seconds
- Go to your Twitter page; look at your latest status!
What does this mean? It means anyone can update your Twitter status without you knowing! Actually, it’s YOU that’s updating it, you just don’t know at the time.
This is a pretty harmless example but I can imagine it being used for more sinister endeavours!
Clickjacking is a dangerous malicious technique; take it seriously! It cannot be halted with a quick browser fix here and there because the problem lies within the CSS/frame implementation itself; it’s not a software bug! If you’re fortunate enough to use Firefox then install NoScript, otherwise explore the other measures I described above.
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
Wow… excellent example here james. I heard of this problem awhile ago, but never really got to see an example.
nice example but user can realize that his cursor change into “hyperlink hand” instead of “button arrow” while moving the cursor onto invisible iframe.
@Brenelz, Thanks! I also heard of it a while ago – back when there was the big worry about Flash. It suddenly went really quiet after that and nobody really talks about it any more, pretending that the really big elephant in the room is just for decoration…
@Gman, the cursor is dependent on what you’re getting the user to click on. It might be a button, a hyperlink, a checkbox or an image. I reckon most users wouldn’t notice that anyway. Plus if I had put a regular looking link under the iframe instead of that button then the average user would be none the wiser. And I’m sure you’re not suggesting that a user’s intuition is suitable protection against something like this?
Also, to anyone reading this, note that my example was quite petty. The technique itself doesn’t really require there to be a button or link within the page. Using JavaScript you could make the iframe follow the user’s cursor, so whenever they click down on anything they’re screwed!
Hmm, perhaps a good way to increase my follower count? Just kidding 😉
This is very interesting indeed. Is there anything twitter can do to prevent this?
e.g. Use a simple frame breaker script to break out of iframes?
@Wesley, sorry, I should’ve included that within the post.
The problem is that there are many legitimate uses of frames and it would be wrong to punish them as well. You could test to see if the iframe you are in has less than full opacity and then remove it:
I haven’t yet tested this:
How abt inc. Clicks on ad using this . .:)
Ive noticed this lately and i just ignore it not knowing that its the so called clickjacking. lol Thanks for the info James.
Thank you for spreading the word about the seriousness of clickjacking. For those interested in the original clickjacking video demo that shows how to hijack a webcam and mic.
Thx for the explanation.. I linked to this post because it’s really going around twitter right now lol…
http://twitter.com/chuckreynolds/status/1203463620
Chrome seems to thwart this exploit — neither the original “don’t click” or the test above ended up in my (logged in) Twitter stream.
FYI the “Don’t Click” that’s going around right now is not clickjacking — it’s XSRF which is simpler. It results from the fact that Twitter allows posting status updates (and possibly other things) using a simple GET request with no authentication beyond a cookie.
What it means is that you can force anyone to post a status update by sending them to a URL starting with twitter.com/?status=, or something like that. That’s easy to do — make that URL the src parameter of an image, put it in an invisible iFrame, emit a redirect to it, etc. It’s much simpler than clickjacking, and no javascript foolery is required.
Don’t get all high and mighty, Sean O. I was unable to do it on Firefox (logged into a junk twitter account to test it) 3.1 nightlies.
Wanna see a Mozilla employee fall for it?
https://twitter.com/Boriss/status/1203570063
thanks
Oh, ignore me please (or drop my comment in moderation) — I was misunderstanding the complete nature of the attack.
@Glenn, it’s NOT XSRF, it’s clickjacking! 🙂 – if I send you to this URL (http://twitter.com/home?status=Hello%20Glenn) nothing is submitted to your Twitter timeline, the GET request will simply pre-fill the ‘status’ textarea with the text specified in the ‘status’ GET parameter.
To make it work you have to knowingly click on the ‘update’ button within Twitter. My exploit (and the new _copy_ flowing around Twitter at the moment) both use the clickjacking method to make you unknowingly click on the ‘update’ button.
@Sean, it’s not only Chrome that fails. I get very inconsistent results with FF3.1 and Opera.
@Tom “High and mighty”? LMAO, I was relating my experience and nothing more. Scroll up and search for the word “seems”. Many others are reporting that Chrome has prevented the unwanted tweet as well.
Relax.
BTW, I still use (and love) Firefox + Firebug for development.
No problem Glenn :), Mr Atwood thinks its XSRF too…
Thanx for posting this information!
As of right now (12:45pm CST) Twitter’s saying they’ve patched this to stop someone from doing it.
Indeed, it’s just been fixed with the following JavaScript fragment on twitter.com:
if (window.top !== window.self) { window.top.location.href = window.self.location.href; }
This causes the toplevel frame to redirect away from the Don’t Click page, hopefully before the unsuspecting user’s had a chance to click and submit the viral text.
@Daniel
That’s not fixed, there are lots of ways around the frame escaping, eg using tags instead of or by using the nonstandard (IE) property which disables certain javascript in the iframe
My html got stripped 🙁
You can get around the frame-breaking using object tags or iframe tags with the non-standard security=”restricted” iframe property for IE
What does this have to do with iframes? It is not limited only to an iframe. This can be done with any image that is transparent, any link with false info, any div or table…
This is not an “Iframe” issue, this is a “Stupid network parlor trick” issue.
The links that say, “CLICK HERE” don’t tell you what is on the other side, what it does when you click it, or anything else other than, if you are lucky, the actual destination page.
How is that different than a link that says, “SEARCH GOOGLE”, but it actually takes you to yahoo, through a google-request, or directly taking you to a yahoo search page?
How is this different than a full-size transparent gif that is a link, overlapped across your whole screen?
These are designs by nature. Stupid, yes… but hardly exploits. (Stop calling every “bad use”, an exploit.) In that case, the writer here exploited a blog program to utilize googles addiction to search. No iframes required, and just as dangerous and malicious as the twitter-gitter. It brought you here, didn’t it!
@JasonD, are you confused because the demo no longer works? (Twitter fixed it after this exploit was used maliciously a few months ago.) This is completely different from a link that claims to go somewhere but goes somewhere else; the problem with clickjacking is that you can fool unsuspecting users into doing something functional on another site without letting them know about it. In this instance it was just a tweet but it could be used for far more malicious endeavors.