Re:Persistent XSS on Twitter.com
by b3n on Thursday June 24, 2010 @10:24AM
(#1458087)
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
by jluxenberg on Thursday June 24, 2010 @01:31PM
(#1458561)
"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.h...
Re:Persistent XSS on Twitter.com
by ashearer on Thursday June 24, 2010 @11:48AM
(#1458297)
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.
Re:Persistent XSS on Twitter.com
by marcinw on Thursday June 24, 2010 @11:52AM
(#1458308)
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.
Re:Persistent XSS on Twitter.com
by wingo on Thursday June 24, 2010 @05:36PM
(#1459214)
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.
Re:Persistent XSS on Twitter.com
by code_duck on Thursday June 24, 2010 @10:42AM
(#1458133)
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
by NathanKP on Thursday June 24, 2010 @10:55AM
(#1458162)
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.
[1] http://www.davidnaylor.co.uk/massive-twitter-cross-site-scri...
> 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.
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.h...
Either way, XSS sucks. Surprised that they haven't plugged this one yet.
Rails 3 changes this by always html escaping strings.
Rails' conflation of these types guarantees that whatever the default for escaping, there will be bugs in applications written in/on rails.
I'm curious what people here think of that idea, ie, preventing string injection attacks at the language level.