This morning, Twitter.com – the most widely used Twitter client – was hit by an XSS (cross-scripting) security flaw that allows malicious code to be inserted into shortened URLs on the Twitter website. At first, it seemed like fun and games but it quickly became apparent that it could cause some serious issues, and we warned users to keep away from the website.
Now, it appears that at least some at Twitter knew about the security hole late last month, but nothing was done about it until this morning when it began to wreak havoc across the Web.
Update: Twitter has offered an explanation of what happened this morning, noting that it “discovered and patched this issue last month. However, a recent site update (unrelated to new Twitter) unknowingly resurfaced it.” It’s good to know that this particular exploit did not sit there knowingly open for the last month.
The exploit, which we wrote about earlier today, allowed a user to insert a bit of Javascript after an “@” included in the middle of a URL. Some of this code, as evidenced this morning, could self replicate and spread wildly, redirecting users of Twitter.com to other websites. At first, it seemed like this would only happen when users moused over links, but then it began to affect all users of the old Twitter.com. According to Georg Wicherski, the XSS code was spreading at a rate of up to 100 tweets per second during the peak of the infection.
On August 23rd, Twitter front-end developer Ben Cherry posted a “code commit” on code-hosting site github that patched the loophole experienced on Twitter.com this morning. As the description of the commit (or code submission) states, the code “closed XSS after the @”.
It seems to us that an XSS loophole of this sort would be a high priority for Twitter to fix and we could only wonder why it wouldn’t have fixed it sooner. Perhaps it wasn’t a high priority with the redesign of Twitter.com on the way? After all, it seems that the loophole does not affect the new Twitter.com.
