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.
I think twitter is using Lift, not Rails.
Persistent XSS on Twitter.com
11–19 of 19 posts
Re: Persistent XSS on Twitter.com
#12Twitter 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.
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
#13Twitter 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.
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
#14Re: Persistent XSS on Twitter.com
#15"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
#16This seems a good time to mention interpolique: http://recursion.com/interpolique.html
I'm curious what people here think of that idea, ie, preventing string injection attacks at the language level.
Re: Persistent XSS on Twitter.com
#17Twitter 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.
Of course. But there's no reason not to make security easier and more natural (pit of success vs. struggling uphill).
Re: Persistent XSS on Twitter.com
#18This 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...
Different field, application name instead of application URL.
Re: Persistent XSS on Twitter.com
#19Twitter 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.
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.