>From your example
  query = "".html_safe
  query << params[:query] # This WOULD be escaped. The << operator is
overwritten to recognize whether what is being appended is html_safe and
escape it if it isn't to maintain an html_safe string
  query << content_tag(...)
  query # Is still html_safe

On Mon, May 17, 2010 at 3:43 PM, Mislav Marohnić
<[email protected]>wrote:

> On Mon, May 17, 2010 at 21:07, RobL <[email protected]> wrote:
>
>>
>> Eventually I realised the original empty string was not html_safe
>
>
> I see how you got confused, but this is intentional. All strings are
> originally not html_safe since there's no way of telling if they came from
> the author or user input. I don't agree that Rails should special-case this
> behavior (blank strings not html_safe) since I don't really think the way
> you're building content here should be encouraged. Depending on your helper
> as whole, there must be better ways.
>
> Also, what about if you're appending user input instead of just content
> tags:
>
>   query = ""
>   query << params[:query]
>   query << content_tag(...)
>
> If blank strings were safe to begin with, and users grew accustomed to the
> fact, doing this would suddenly be exposing yourself to XSS via GET/POST
> params.
>
> --
> 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected]<rubyonrails-core%[email protected]>
> .
> 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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Reply via email to