michael.hasenstein@googlemail.com
2010-Apr-04 11:51 UTC
XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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 even say the escaping only is necessary if STRING variables are introduced, so including number-variables in a(n otherwise fixed) string should not trigger the need to use raw(). I only just started but the amount of "raw()" I have to insert into my app seems excessive. Michael -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jonas Nicklas
2010-Apr-04 13:53 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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)
%Q[word]
%Q{word}
<<STRING
word
STRING
<<-STRING
word
STRING
etc...
On Sun, Apr 4, 2010 at 1:51 PM, michael.hasenstein@googlemail.com
<michael.hasenstein@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 it when
> variables are concerned, but this is taking it a little too far. One
> might even say the escaping only is necessary if STRING variables are
> introduced, so including number-variables in a(n otherwise fixed)
> string should not trigger the need to use raw().
>
> I only just started but the amount of "raw()" I have to insert
into my
> app seems excessive.
>
> Michael
>
> --
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper
2010-Apr-04 13:54 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com <michael.hasenstein@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 it when > variables are concerned, but this is taking it a little too far. One > might even say the escaping only is necessary if STRING variables are > introduced, so including number-variables in a(n otherwise fixed) > string should not trigger the need to use raw(). > > I only just started but the amount of "raw()" I have to insert into my > app seems excessive.Making the switch to HTML-safety is quite a pain. The grass is greener on the other side, though! You mark just a handful of strings as <%= raw ... %> instead of almost every string as <%= h ... %> -- less work down the line, plus no lingering XSS worries. jeremy -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Daniel Schierbeck
2010-Apr-04 14:37 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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 <jeremy@bitsweat.net> wrote:> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com > <michael.hasenstein@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 it when >> variables are concerned, but this is taking it a little too far. One >> might even say the escaping only is necessary if STRING variables are >> introduced, so including number-variables in a(n otherwise fixed) >> string should not trigger the need to use raw(). >> >> I only just started but the amount of "raw()" I have to insert into my >> app seems excessive. > > Making the switch to HTML-safety is quite a pain. The grass is greener > on the other side, though! > > You mark just a handful of strings as <%= raw ... %> instead of almost > every string as <%= h ... %> -- less work down the line, plus no > lingering XSS worries. > > jeremy > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper
2010-Apr-04 14:52 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com >> <michael.hasenstein@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 it when >>> variables are concerned, but this is taking it a little too far. One >>> might even say the escaping only is necessary if STRING variables are >>> introduced, so including number-variables in a(n otherwise fixed) >>> string should not trigger the need to use raw(). >>> >>> I only just started but the amount of "raw()" I have to insert into my >>> app seems excessive. >> >> Making the switch to HTML-safety is quite a pain. The grass is greener >> on the other side, though! >> >> You mark just a handful of strings as <%= raw ... %> instead of almost >> every string as <%= h ... %> -- less work down the line, plus no >> lingering XSS worries. > > Just out of curiosity, couldn''t you use String#tainted? to check > whether the string was a literal or not?Yes! Using native String tainting would have some nice advantages. Another is that string interpolation would work: "foo #{bar}" is tainted if bar is tainted, but it is not html_safe? if bar is html_safe? jeremy -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Prem Sichanugrist
2010-Apr-04 14:54 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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 > <daniel.schierbeck@gmail.com> wrote: >> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >>> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com >>> <michael.hasenstein@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 it when >>>> variables are concerned, but this is taking it a little too far. One >>>> might even say the escaping only is necessary if STRING variables are >>>> introduced, so including number-variables in a(n otherwise fixed) >>>> string should not trigger the need to use raw(). >>>> >>>> I only just started but the amount of "raw()" I have to insert into my >>>> app seems excessive. >>> >>> Making the switch to HTML-safety is quite a pain. The grass is greener >>> on the other side, though! >>> >>> You mark just a handful of strings as <%= raw ... %> instead of almost >>> every string as <%= h ... %> -- less work down the line, plus no >>> lingering XSS worries. >> >> Just out of curiosity, couldn''t you use String#tainted? to check >> whether the string was a literal or not? > > Yes! Using native String tainting would have some nice advantages. > > Another is that string interpolation would work: "foo #{bar}" is > tainted if bar is tainted, but it is not html_safe? if bar is > html_safe? > > jeremy > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >
Daniel Schierbeck
2010-Apr-04 15:23 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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) within Ruby itself. Should I cook up a patch for this? Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 4:52 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote:> On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck > <daniel.schierbeck@gmail.com> wrote: >> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >>> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com >>> <michael.hasenstein@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 it when >>>> variables are concerned, but this is taking it a little too far. One >>>> might even say the escaping only is necessary if STRING variables are >>>> introduced, so including number-variables in a(n otherwise fixed) >>>> string should not trigger the need to use raw(). >>>> >>>> I only just started but the amount of "raw()" I have to insert into my >>>> app seems excessive. >>> >>> Making the switch to HTML-safety is quite a pain. The grass is greener >>> on the other side, though! >>> >>> You mark just a handful of strings as <%= raw ... %> instead of almost >>> every string as <%= h ... %> -- less work down the line, plus no >>> lingering XSS worries. >> >> Just out of curiosity, couldn''t you use String#tainted? to check >> whether the string was a literal or not? > > Yes! Using native String tainting would have some nice advantages. > > Another is that string interpolation would work: "foo #{bar}" is > tainted if bar is tainted, but it is not html_safe? if bar is > html_safe? > > jeremy > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper
2010-Apr-04 15:23 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
On Sun, Apr 4, 2010 at 7:54 AM, Prem Sichanugrist <sikandsak@gmail.com> 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, so having to state it again is annoying and not DRY.> On 4 เม.ย. 2553, at 21:52, Jeremy Kemper wrote: > >> On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck >> <daniel.schierbeck@gmail.com> wrote: >>> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >>>> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com >>>> <michael.hasenstein@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 it when >>>>> variables are concerned, but this is taking it a little too far. One >>>>> might even say the escaping only is necessary if STRING variables are >>>>> introduced, so including number-variables in a(n otherwise fixed) >>>>> string should not trigger the need to use raw(). >>>>> >>>>> I only just started but the amount of "raw()" I have to insert into my >>>>> app seems excessive. >>>> >>>> Making the switch to HTML-safety is quite a pain. The grass is greener >>>> on the other side, though! >>>> >>>> You mark just a handful of strings as <%= raw ... %> instead of almost >>>> every string as <%= h ... %> -- less work down the line, plus no >>>> lingering XSS worries. >>> >>> Just out of curiosity, couldn''t you use String#tainted? to check >>> whether the string was a literal or not? >> >> Yes! Using native String tainting would have some nice advantages. >> >> Another is that string interpolation would work: "foo #{bar}" is >> tainted if bar is tainted, but it is not html_safe? if bar is >> html_safe? >> >> jeremy >> >> -- >> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >> > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper
2010-Apr-04 15:26 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
On Sun, Apr 4, 2010 at 8:23 AM, Daniel Schierbeck <daniel.schierbeck@gmail.com> 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 replicate functionality which is already present > (and more powerful) within Ruby itself. > > Should I cook up a patch for this?The problem with tainted is that it''s a single flag for everybody to share. It may have different meanings in different libraries. Say, a database driver checks taint to see whether strings should be SQL-escaped. I think the benefits of using tainting in the common case, 99% of usage, far outweigh these unlikelihoods though. jeremy> Cheers, > Daniel Schierbeck > > On Sun, Apr 4, 2010 at 4:52 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >> On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck >> <daniel.schierbeck@gmail.com> wrote: >>> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >>>> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com >>>> <michael.hasenstein@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 it when >>>>> variables are concerned, but this is taking it a little too far. One >>>>> might even say the escaping only is necessary if STRING variables are >>>>> introduced, so including number-variables in a(n otherwise fixed) >>>>> string should not trigger the need to use raw(). >>>>> >>>>> I only just started but the amount of "raw()" I have to insert into my >>>>> app seems excessive. >>>> >>>> Making the switch to HTML-safety is quite a pain. The grass is greener >>>> on the other side, though! >>>> >>>> You mark just a handful of strings as <%= raw ... %> instead of almost >>>> every string as <%= h ... %> -- less work down the line, plus no >>>> lingering XSS worries. >>> >>> Just out of curiosity, couldn''t you use String#tainted? to check >>> whether the string was a literal or not? >> >> Yes! Using native String tainting would have some nice advantages. >> >> Another is that string interpolation would work: "foo #{bar}" is >> tainted if bar is tainted, but it is not html_safe? if bar is >> html_safe? >> >> jeremy >> >> -- >> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Daniel Schierbeck
2010-Apr-04 15:31 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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 <jeremy@bitsweat.net> wrote:> On Sun, Apr 4, 2010 at 8:23 AM, Daniel Schierbeck > <daniel.schierbeck@gmail.com> 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 replicate functionality which is already present >> (and more powerful) within Ruby itself. >> >> Should I cook up a patch for this? > > The problem with tainted is that it''s a single flag for everybody to > share. It may have different meanings in different libraries. > > Say, a database driver checks taint to see whether strings should be > SQL-escaped. > > I think the benefits of using tainting in the common case, 99% of > usage, far outweigh these unlikelihoods though. > > jeremy > >> Cheers, >> Daniel Schierbeck >> >> On Sun, Apr 4, 2010 at 4:52 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >>> On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck >>> <daniel.schierbeck@gmail.com> wrote: >>>> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote: >>>>> On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenstein@googlemail.com >>>>> <michael.hasenstein@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 it when >>>>>> variables are concerned, but this is taking it a little too far. One >>>>>> might even say the escaping only is necessary if STRING variables are >>>>>> introduced, so including number-variables in a(n otherwise fixed) >>>>>> string should not trigger the need to use raw(). >>>>>> >>>>>> I only just started but the amount of "raw()" I have to insert into my >>>>>> app seems excessive. >>>>> >>>>> Making the switch to HTML-safety is quite a pain. The grass is greener >>>>> on the other side, though! >>>>> >>>>> You mark just a handful of strings as <%= raw ... %> instead of almost >>>>> every string as <%= h ... %> -- less work down the line, plus no >>>>> lingering XSS worries. >>>> >>>> Just out of curiosity, couldn''t you use String#tainted? to check >>>> whether the string was a literal or not? >>> >>> Yes! Using native String tainting would have some nice advantages. >>> >>> Another is that string interpolation would work: "foo #{bar}" is >>> tainted if bar is tainted, but it is not html_safe? if bar is >>> html_safe? >>> >>> jeremy >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >>> To post to this group, send email to rubyonrails-core@googlegroups.com. >>> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. >>> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Mike Gunderloy
2010-Apr-04 15:41 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Daniel Schierbeck
2010-Apr-04 15:55 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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 <larkware@gmail.com> wrote:> 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" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Yehuda Katz
2010-Apr-04 19:35 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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 internally marks its own Strings as safe, which is why you don''t need to mark form_for, link_to, etc. as html_safe. Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 On Sun, Apr 4, 2010 at 8:55 AM, Daniel Schierbeck < daniel.schierbeck@gmail.com> wrote:> 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 <larkware@gmail.com> wrote: > > 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" group. > > To post to this group, send email to rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Michael Koziarski
2010-Apr-04 23:23 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
> 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 completely hosed. It''s not just a question of ActiveRecord either. Apps read strings from memcached, redis, http (dozens of libraries here), one bug here and you''re hosed. The risk outweighs the slim rewards. Tainting was an alluring option initially, but the more you drill down into it the more of a red-herring it becomes. -- Cheers Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Daniel Schierbeck
2010-Apr-05 08:27 UTC
Re: XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!
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 <michael@koziarski.com> wrote:>> 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 completely hosed. > > It''s not just a question of ActiveRecord either. Apps read strings > from memcached, redis, http (dozens of libraries here), one bug here > and you''re hosed. The risk outweighs the slim rewards. > > Tainting was an alluring option initially, but the more you drill down > into it the more of a red-herring it becomes. > > > -- > Cheers > > Koz > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.