Comments on: Clickjacking Twitter

By: James

James — Thu, 24 Sep 2009 12:33:26 +0000

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

By: JasonD

JasonD — Thu, 24 Sep 2009 11:01:03 +0000

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!

By: Eion

Eion — Fri, 13 Feb 2009 07:01:58 +0000

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

By: Eion

Eion — Fri, 13 Feb 2009 06:38:42 +0000

@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

By: Daniel Sandler

Daniel Sandler — Thu, 12 Feb 2009 18:53:22 +0000

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.

By: CJ

CJ — Thu, 12 Feb 2009 18:45:49 +0000

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.

By: James

James — Thu, 12 Feb 2009 18:44:27 +0000

No problem Glenn :), Mr Atwood thinks its XSRF too...

By: Sean O

Sean O — Thu, 12 Feb 2009 18:43:52 +0000

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

By: James

James — Thu, 12 Feb 2009 18:41:52 +0000

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

By: Glenn Willen

Glenn Willen — Thu, 12 Feb 2009 18:37:08 +0000

Oh, ignore me please (or drop my comment in moderation) — I was misunderstanding the complete nature of the attack.