Live data from Hacker News

Persistent XSS on Twitter.com

praetorianprefect.com

1–10 of 19 posts

Re: Persistent XSS on Twitter.com

#3
At least this script in particular seems pretty harmless. I glossed over the "rainbow links" code, so maybe there was something vicious in there.

Either way, XSS sucks. Surprised that they haven't plugged this one yet.

Re: Persistent XSS on Twitter.com

#5
Why can't Twitter get its shit together? When Facebook faces those kind of problems, they iron them out in a blink of an eye. Scaling problems? No problem, I don't think I've ever experienced Facebook going down in the past 4-5 years!

How can a top-10 Alexa site such as Twitter continually entertain users with hours of downtime every week? What about escaping input? This is below web dev 101 for god's sake.

Re: Persistent XSS on Twitter.com

#7
post #2

This has been demo'd a long time ago already [1], and it seems they haven't done anything yet ? Wtf. [1] http://www.davidnaylor.co.uk/massive-twitter-cross-site-scri...

It was fixed, but now it's back again...

> The problem is similar to one described last August by James Slater. That time around the issue was with the application URL, this time it appears the application name is the issue.

Re: Persistent XSS on Twitter.com

#8
Twitter sure does have issues with stuff like this. I noticed a while back that they were double encoding some strings on output, too - I had an ampersand in my location and it was showing as & on the page.

Re: Persistent XSS on Twitter.com

#10

Twitter is probably still using Rails 2.3, where you have to explicitly tell the framework to html escape every time you're outputting a string. Rails 3 changes this by always html escaping strings.

Security shouldn't be a matter of the framework, especially if it belongs to well known problems like XSS.
Post reply on HN