Write-up: DOM-based XSS and open redirect on Twitter.com

Summary. A client-side redirect helper on twitter.com, twttr.griffin.redirectOnHash(), took the location hash and used it to navigate without validating the scheme. A hash beginning with #! followed by a javascript: URI produced reflected cross-site scripting, and the same sink allowed open redirection. Reported on 30 September 2012 and fixed by Twitter within 24 hours.

Background

Last week I started analysing Twitter's JavaScript files, looking for DOM-based vulnerabilities. During that review I noticed that Twitter used several JavaScript functions to handle inbound redirects. The method twttr.griffin.redirectOnHash() on twitter.com turned out to be prone to reflected cross-site scripting and open redirection.

 ...

Source line 36: twttr.griffin.redirectOnSearch=function(a) twttr.griffin.redirectOnHash=function(){if(window.location.pathname=="/"&&window.location.hash!=""){var a=window.location.hash.substr(1).toLowerCase();twttr.griffin.redirectIfEvent(a,"redir")}},twttr.griffin.redirectOnHash();

...

Proof of concept

After studying the source carefully, I built a proof of concept. One detail I had to account for is that Twitter required an exclamation mark as the first character after the location hash (#!) before our own code would run.

1) xss: https://twitter.com/#!javascript:alert(/windowname-xss/);//

2) open redirection: https://twitter.com/#!://window.name

Impact and remediation

The hash is attacker-controllable through a crafted link, so a victim who followed one would either run script in the context of twitter.com or be redirected to an arbitrary site under a trusted-looking URL. The fix is to validate the target before navigating: accept only same-origin paths, and reject any value whose scheme is not http or https.

Disclosure

I reported both issues to Twitter's security team on September 30th 2012. They verified the findings and fixed them within 24 hours. Many thanks to the Twitter security team for the quick turnaround.