Earlier today, a tweet caused significant trouble and ire among TweetDeck users. It didn’t look like your average tweet:

Users didn’t even have to click on the tweet. Just the act of viewing the tweet would cause the user to automatically retweet it. As a result, the message was seen and retweeted all over Twitter, in some cases over ten thousand times. But how could one tweet cause such devastation? The details lie in the code.

Cross-Site Scripting 101

An example of XSS, although not the one used in the Tweetdeck hack.
An example of XSS, although not the one used in the Tweetdeck hack.

First of all what is cross-site scripting? XSS, as it’s commonly abbreviated, is a weakness in the design of a website that allows hackers to insert malicious code into a web page or application, altering the intended operation of the service. It’s a common concern among web developers to prevent such attacks.

That little bit of code in between is written in a language called JavaScript. Basically, JavaScript allows the browser to manipulate the HTML of a page. Many sites on the web today would not work without JS, and unfortunately, hackers can exploit JavaScript to their own use as well.

A well-secured web service would never allow such code to perform malicious actions. Behind the scenes, all text that goes through the web server gets sanitized so that it is simply displayed as text and not run like a script. Unfortunately for TweetDeck, its engineers forgot to vaccinate such tweets, allowing scripts to run inside a tweet instead of displaying as benign text.

Taking apart the code

If you were on TweetDeck, all you would have seen is the heart symbol, because the script doesn’t display its own code. However, viewing the tweet on Twitter reveals the script’s code.

Let’s examine the code inside this tweet. First of all, it’s all on one line to fit within Twitter’s 140 character limit. Let’s make it more readable, by adding line breaks and spacing. Don’t worry, this does not affect the functionality of the code in any way.

$( '.xss' ).parents().eq( 1 )
    .find( 'a' ).eq( 1 ).click();
$( '[data-action=retweet]' ).click();
alert( 'XSS in Tweetdeck' )

This particular instance of JavaScript is written in jQuery, a library built on top of JavaScript. Think of it as JavaScript, simplified.

The first line of code calls the <script class="xss"> bit in the tweet, then .parents().eq(1) references the displayed tweet. In the second line, .find('a').eq(1) finds the retweet link, and .click() simulates a click just as if you had clicked it yourself. On TweetDeck, hitting the retweet button brings up this window:


Examining the web page source, this code defines the blue Retweet button:

<button data-action="retweet" class="js-action-button js-retweet-button btn btn-positive">Retweet</button>

Notice the data-action="retweet" portion. The JavaScript code, third line, grabs this button via this data attribute, and again, simulates a click with click(). Because all of this script runs automatically, you’ve just unwillingly retweeted the tweet without even moving your mouse.

But wait, there’s one more line. alert( ... ) simply displays a conspicuous message in your browser (some browsers, a popup) that says “XSS in Tweetdeck”. It’s just an extra line of code to let users know of the script’s presence, and was not part of the reason why almost eighty-thousand users “click()ed” Retweet.

What users see when the fourth line of code is run.
What users see when the fourth line of code is run.

In a nutshell, the tweet contained a script which forced users to click a Retweet button. There was nothing you could have done unless you had JavaScript disabled (which you probably don’t — and won’t want to).

Why didn’t it work in [insert name of app here]?

It worked on TweetDeck because TweetDeck forgot to check its tweets for malicious content. Also, JavaScript/jQuery only work with HTML-based applications. This particular instance of jQuery worked because it was tailored to the structuring of TweetDeck’s HTML code, and will most likely not work anywhere else, including the main Twitter website.

Also, Twitter patched the vulnerability fairly quickly. Kudos to them!

Published by Geoffrey Liu

A software engineer by trade and a classical musician at heart. Currently a software engineer at Groupon getting into iOS mobile development. Recently graduated from the University of Washington, with a degree in Computer Science and a minor in Music. Web development has been my passion for many years. I am also greatly interested in UI/UX design, teaching, cooking, biking, and collecting posters.

One thought on “How TweetDeck got hacked: the non-technical answer

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.