4 ms·

Persistent XSS on Twitter.com

62 points by forkqueue 16y ago

Seldaek 16y ago
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-scripting-vulnerability.html http://www.davidnaylor.co.uk/massive-twitter-cross-site-scri...
- fname 16y ago
  EDIT: nevermind.. you're right. WTF is right.
- b3n 16y ago
  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.
- Sejanus 16y ago
  Different field, application name instead of application URL.
agentultra 16y ago
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.
dirtyhand 16y ago
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.
- texec 16y ago
  Security shouldn't be a matter of the framework, especially if it belongs to well known problems like XSS.
  - ashearer 16y ago
    With programmers being human, there's a lot to be said for the framework providing a secure default. Even so, it's surprising how often this particular mistake occurs.
  - marcinw 16y ago
    You seriously think developers will manually HTML encode every time user input is rendered in the response? It's not just HTML they have to worry about, but Javascript, URL, HTML attributes, etc. If the framework doesn't automatically do it, nobody does it. That is, until they get hit by XSS.
  - InclinedPlane 16y ago
    Of course. But there's no reason not to make security easier and more natural (pit of success vs. struggling uphill).
  - wingo 16y ago
    Depends on what you mean by "framework". I would interpret that as "the language in which you write your application", and in that case a language that treats text and HTML as different datatypes does provide more security. Rails' conflation of these types guarantees that whatever the default for escaping, there will be bugs in applications written in/on rails.
- hnal943 16y ago
  I think twitter is using Lift, not Rails.
  - fizx 16y ago
    Nope
caffogene 16y ago
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.
code_duck 16y ago
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.
NathanKP 16y ago
None of the code looks malicious, but I would suggest that if you have a Twitter account and/or are logged into it, don't visit the page because he might be stealing cookies.
jluxenberg 16y ago
"appears to be due to a lack of input validation of the application name field" They should just be sure that they _render_ the application name field appropriately. Angle brackets should be escaped, minimally. It's really not so difficult, Ruby does it with three calls to gsub: http://rdoc.sourceforge.net/rd/doc/classes/CGI.src/M000003.html http://rdoc.sourceforge.net/rd/doc/classes/CGI.src/M000003.h...
dreeves 16y ago
This seems a good time to mention interpolique: http://recursion.com/interpolique.html http://recursion.com/interpolique.html I'm curious what people here think of that idea, ie, preventing string injection attacks at the language level.

62 points by forkqueue 16y ago

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-scripting-vulnerability.html http://www.davidnaylor.co.uk/massive-twitter-cross-site-scri...

fname 16y ago
EDIT: nevermind.. you're right. WTF is right.
b3n 16y ago
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.
Sejanus 16y ago
Different field, application name instead of application URL.

agentultra 16y ago

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.

dirtyhand 16y ago

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.

texec 16y ago
Security shouldn't be a matter of the framework, especially if it belongs to well known problems like XSS.
- ashearer 16y ago
  With programmers being human, there's a lot to be said for the framework providing a secure default. Even so, it's surprising how often this particular mistake occurs.
- marcinw 16y ago
  You seriously think developers will manually HTML encode every time user input is rendered in the response? It's not just HTML they have to worry about, but Javascript, URL, HTML attributes, etc. If the framework doesn't automatically do it, nobody does it. That is, until they get hit by XSS.
- InclinedPlane 16y ago
  Of course. But there's no reason not to make security easier and more natural (pit of success vs. struggling uphill).
- wingo 16y ago
  Depends on what you mean by "framework". I would interpret that as "the language in which you write your application", and in that case a language that treats text and HTML as different datatypes does provide more security. Rails' conflation of these types guarantees that whatever the default for escaping, there will be bugs in applications written in/on rails.
hnal943 16y ago
I think twitter is using Lift, not Rails.
- fizx 16y ago
  Nope

caffogene 16y ago

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.

code_duck 16y ago

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.

NathanKP 16y ago

None of the code looks malicious, but I would suggest that if you have a Twitter account and/or are logged into it, don't visit the page because he might be stealing cookies.

jluxenberg 16y ago

"appears to be due to a lack of input validation of the application name field" They should just be sure that they _render_ the application name field appropriately. Angle brackets should be escaped, minimally. It's really not so difficult, Ruby does it with three calls to gsub: http://rdoc.sourceforge.net/rd/doc/classes/CGI.src/M000003.html http://rdoc.sourceforge.net/rd/doc/classes/CGI.src/M000003.h...

dreeves 16y ago

This seems a good time to mention interpolique: http://recursion.com/interpolique.html http://recursion.com/interpolique.html I'm curious what people here think of that idea, ie, preventing string injection attacks at the language level.