What is this Don't Click business?
- Written by
- Clay Johnson
- Date
- 02/12/2009 1:14 p.m.
This afternoon, a friend of mine tweeted "Don't Click: (link)"
I, being a naturally curious human being, proceeded to click the button and saw a page with another button that says "Don't Click"
I clicked on that button as well and then noticed that in my Twitter feed, I had in fact tweeted the same link even though I never consented to do so.
Huzzah! the first twitter social virus!
It seems mostly harmless, just perpetuating itself and breeding. You can check out the graph of its use here:
Here's how it works:
You can actually link to twitter and auto-fill a message box quite easily. All you have to do is write a link like this: "http://twitter.com/home?status=Sunlight Labs post on Don't Click:http://bit.ly/kj1z9". What this "virus" does is, it creates an iframe of the page, hides it, and when you click that button and you're logged into Twitter, it makes you post that message (even though you don't see it). There's not a bit of javascript involved. The only javascript on the page is their Google Analytics code.
Shockingly it works amazingly well. Now we can see all the people who probably as children defied their parents when they were told not to do something. Check out this graph of the volume of the Don't Click bug:
It also appears like all the source is available. The "virus" should be totally harmless. It doesn't look like your account info was stolen or anything of the sort. Here's the source of the virus translated into English.
Discussion
What are Your Thoughts?
Have thoughts that might fuel this discussion further, post them below. (Markdown syntax is supported in comments.)
I don't think it even matters if you click the button. When the page loads, the IFRAME makes an HTTP GET request to Twitter (because the Twitter URL is set as the source of the IFRAME's content), and that request sends the tweet. So by the time the page is done loading you've been "infected" whether you click the button or not.
This type of exploit is technically known as Cross-Site Request Forgery , because it relies on your having a cookie in your browser from the site to be exploited. If the cookie is set, Twitter assumes that the request is authorized because you've successfully logged in. The trick is that because many sites store cookies in your browser for long periods of time, another site can take advantage of a login that you did days, weeks or months ago to send requests today that appear to be from you -- like this "Don't Click" tweet.
(You may have noticed that the big social sites are asking you to re-enter your password a lot more often than they used to these days. That's because they are defending against CSRF attacks by cutting down the time before your browser cookie from them expires.)
This particular attack is pretty benign, but it's an excellent illustration of how improperly secured Web applications can be "hacked" via CSRF. This issue is worth paying attention to, because just 'cuz this particular CSRF exploit doesn't do damage doesn't mean you couldn't come up with one that does -- it's entirely possible that there are other Twitter URLs and API endpoints that are similarly vulnerable that do more dramatic things. My guess is that the folks at Twitter are going to be reviewing them all fairly shortly...
Thanks for the write-up. Benign in this case maybe. But it sounds like it would be easy to change the "payload" to be a much more embarrassing message. Then you'd probably have to go a'runnin' for the Twitter trashcan to delete it before your boss or friends saw the damage.
@Jason: In this case, it is in fact safe to hit the page without hitting the button. It isn't posting directly to twitter (or the API) just prepoulating the box. I know this, in part, because I've hit the page a half dozen times. Check it out, view source (or click the link to the english translation at the end of the post) to see the author of the virus' write-up.
Interesting... a new wrinkle on the classic CSRF.
I made the assumption that the GET was doing the action because there was no scripting in the page to handle the event when the button is clicked.
Which raises the question -- how does clicking that button trigger the submission of the form in the IFRAME? If there's no script catching the click event and no FORM element encasing the button?
The best explanation I've seen so far is that they're using clever CSS to make you think you're clicking the "Don't Click" button, when you're actually clicking the Twitter "Submit" button. I just went to check it in Firebug but it looks like they've taken the "Don't Click" page down...
And now there's word from Twitter that the clever-CSS thing is indeed how it's done, along with the name of the technique, clickjacking -- which like CSRF is a "confused deputy" attack...
The rather hideous / stupid part is that Rails has CSRF protection built in (on POSTs, but it can be done on GETs as well) that prevents this problem by adding a hashed secret parameter. I don't know why Twitter doesn't use it.
That wouldn't have prevented this kind of attack. Using such a parameter (a "nonce") is effective against CSRF, but, as Clay noted (more astutely than I, as I chased my initial impression down the garden path), clickjacking isn't CSRF. The request is generated and consumed within the same domain and without steps in between, just as it would be for a legitimate request. A nonce is protection against old requests being re-used, not new requests that are just generated without the user's knowledge.
The way to defend against clickjacking appears to be JavaScript frame-busting, which would have protected Twitter by ensuring that their site couldn't have been contained in the hidden IFRAME the exploit used.
Looking for more info on the exploit, I found the original paper that introduced clickjacking to the world last year and it explains in more detail the differences between CSRF and clickjacking and why nonces don't shield you from the latter. An interesting read.
The frame busting code they added is not sufficient:
http://coderrr.wordpress.com/2009/02/13/preventing-frame-busting-and-click-jacking-ui-redressing/
Sum up of the "Don't Click" effect. So that you'll have an inside view of what happened.
http://www.umoor.eu/blog/general/the-dont-click-effect
By looking at the comment here I see that it was not a CSRF.
It is all click jacking and we might see more such attacks in future.
The quickest fix for this attack is - DO NOT let your site be loaded in an iframe. Thats it!
if (window.parent.frames.length>0) { //you are framed. //Go to your site without frame window.parent.location=location; }
http://seugmint.com/dutch-porno/index.html - dutch porno xxsex video http://seugmint.com/smutt-porno/index.html