The "Don't Click" Twitterjacking Explained

[cjoh]

http://sunlightlabs.com/blog/2009/02/12/what-dont-click-business/

[CalmQuiet]

This "Don't Click" virus may have the great benefit of giving CSRF (Cross-Site Request Forgery) the sort of front-page news that will spur developers of social sites to adopt safe(r) cookie practices. ...and more and more sites are adopting at least some cookie-based social features.

Demonstrations that the (apparently) innocent "Don't Click" virus is poorly defended against at Twitter will likely mean that more nefarious and damaging are being cooked right now. Neophyte developers like myself keep having to remind myself that there more stringent rules need to be applied to surfing from same browser as used for database access such as phpMyAdmin: http://news.ycombinator.com/item?id=209457

For other noobs like me, the wikipedia entry should strike the fear of black-hatting in you: http://en.wikipedia.org/wiki/Cross-site_request_forgery

[coderrr → CalmQuiet]

This wasn't CSRF, but clickjacking, aka UI redressing. CSRF protection does nothing against it. There are some ways to attempt to defend against it but I don't think there is any 100% reliable way yet.

http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_pag...

[CalmQuiet → coderrr]

Thank you for clarification. It seems that Twitter thinks (http://blog.twitter.com/2009/02/clickjacking-blocked.html) they are reliably defending against it. Someone will soon be trying to determine if theirs is "100% reliable" yet.

EDIT: So what do you think of the sufficiency of the "fix" as explained at: http://dsandler.org/outgoing/dontclick.html ?

[coderrr → CalmQuiet]

this might be a way around it in IE

http://code.google.com/p/browsersec/wiki/Part3#Microsoft_Int...

[coderrr → coderrr]

and one way around this is http://keepitlocked.net/archive/2008/11/07/preventing-clickj...

[wesley → coderrr]

They've just fixed this it seems. Content is now hidden in iframes.

[coderrr → CalmQuiet]

Here's another way around it: http://coderrr.wordpress.com/2009/02/13/preventing-frame-bus...

[tectonic → coderrr]

Thanks for the link to Google's browsersec page, that's really useful. http://code.google.com/p/browsersec/wiki/Main

[axod]

Current code:

  <form action="http://twitter.com/status/update" 
        id="doingForm" 
        method="post">
  <input name="authenticity_token" 
         type="hidden" 
         value="bd7a45884127cc55d971a53733026770aee78597" />
  <input id="tab_action" 
         name="tab" type="hidden" 
         value="home" />
  <input id="authenticity_token" 
         name="authenticity_token" 
         type="hidden" 
         value="bd7a45884127cc55d971a53733026770aee78597" />

Just to be certain, they include the authenticity_token twice ;)

[wesley]

Clickjacking has been known about for over a year. When will companies start to proactively fix these kind of exploits? It always seems to take a "sample" exploit first.

[cjoh]

Sort of disappointed that this "one time only" exploit wasn't used for a massive twitter rickroll.

[lonestar]

Ran a quick test, and it looks like Twitter has already enabled frame-busting on the status submit page.

[teej → lonestar]

You could probably still have some success using this technique- http://aplus.rs/web-dev/insert-html-page-into-another-html-p... - which masks the fact that you're embedded in IE.