Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-05 Thread Daniel Schierbeck
I can see that -- it's sad that we have this great functionality built right into Ruby, yet we're unable to take advantage of it. Well, nothing to do about that. Cheers, Daniel Schierbeck On Mon, Apr 5, 2010 at 1:23 AM, Michael Koziarski wrote: >> That seems reasonable. Perhaps the tainting co

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Michael Koziarski
> That seems reasonable. Perhaps the tainting could be moved higher up > the hierarchy, the ActiveRecord itself? All getters would then return > tainted strings. Would that not suffice? If we used tainting then all it would take is one library to not return tainted strings, and your application is

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Yehuda Katz
The main issue with taint is that it's a blacklist operation. This means that we'd be relying on all libraries that could retrieve persisted user data to properly taint their Strings. In contrast, the html_safe approach assumes that all Strings are unsafe, until they are marked safe. Rails interna

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Daniel Schierbeck
That seems reasonable. Perhaps the tainting could be moved higher up the hierarchy, the ActiveRecord itself? All getters would then return tainted strings. Would that not suffice? Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 5:41 PM, Mike Gunderloy wrote: > NzKoz's original note on why he d

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Mike Gunderloy
NzKoz's original note on why he didn't go with #tainted?: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/d04d32341b4790c4/444e732a0b265f96?lnk=gst&q=taint#444e732a0b265f96 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" gr

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Daniel Schierbeck
That's a valid concern, but I think trying it out is the best approach -- then we'll se if any problems arise. Having a #html_safe wrapper around the tainting also yields some flexibility. Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 5:26 PM, Jeremy Kemper wrote: > On Sun, Apr 4, 2010 at 8:

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Jeremy Kemper
On Sun, Apr 4, 2010 at 8:23 AM, Daniel Schierbeck wrote: > What is the reason that #tainted? wouldn't suffice? Basically, all > tainted strings are HTML escaped; if you wish to circumvent this, mark > your strings as untainted with String#untaint. It seems to me that > #html_safe tries to replicat

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Jeremy Kemper
On Sun, Apr 4, 2010 at 7:54 AM, Prem Sichanugrist wrote: > If you are certain that your string is safe, then you can mark it as > html_safe by doing this: > > ?<%= link_to " bla".html_safe, path %> Prem, yes. The original poster's concern is that literal strings are already known to be HTML-safe

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Daniel Schierbeck
What is the reason that #tainted? wouldn't suffice? Basically, all tainted strings are HTML escaped; if you wish to circumvent this, mark your strings as untainted with String#untaint. It seems to me that #html_safe tries to replicate functionality which is already present (and more powerful) withi

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Prem Sichanugrist
If you are certain that your string is safe, then you can mark it as html_safe by doing this: <%= link_to " bla".html_safe, path %> - Prem On 4 เม.ย. 2553, at 21:52, Jeremy Kemper wrote: > On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck > wrote: >> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Ke

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Jeremy Kemper
On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck wrote: > On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper wrote: >> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenst...@googlemail.com >> wrote: >>> Hi, >>> >>> Using Rails 3 (git master) and Ruby 1.9.2-head I noticed I have to >>> treat EVERY SINGLE

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Daniel Schierbeck
Just out of curiosity, couldn't you use String#tainted? to check whether the string was a literal or not? Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper wrote: > On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenst...@googlemail.com > wrote: >> Hi, >> >> Using Rails 3 (git

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Jeremy Kemper
On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenst...@googlemail.com wrote: > Hi, > > Using Rails 3 (git master) and Ruby 1.9.2-head I noticed I have to > treat EVERY SINGLE STRING in my app, even things like > >  link_to " bla", path > > with raw(). This is crazy! It is a FIXED string! I understand

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread Jonas Nicklas
Unfortunately, there's no way to know if a string is a literal or not, short of parsing the Ruby, and considering the sheer number of string literals in Ruby, that seems very infeasible. /Jonas P.S.: off the top of my head: "word" 'word' %(word) %[word] %{word} %q(word) %q[word] %q{word} %Q(word

[Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

2010-04-04 Thread michael.hasenst...@googlemail.com
Hi, Using Rails 3 (git master) and Ruby 1.9.2-head I noticed I have to treat EVERY SINGLE STRING in my app, even things like link_to " bla", path with raw(). This is crazy! It is a FIXED string! I understand it when variables are concerned, but this is taking it a little too far. One might eve