Hi,
Can somebody update me on the state of html_safe strings in rails 2.3.8?
I know rails 2.3.6 and 2.3.7 broke a lot of code because strings were
being escaped when they shouldn’t have been and I thought this was all
fixed in 2.3.8.
I’m upgrading an app from 2.3.5 to 2.3.8 and there are many spots where
previous code was output correctly and now it expects html_safe method
calls to properly escape the strings. Are those who don’t want to use
the new escaping behaviour in the 2.3.x branch expected to stick with
2.3.5 from now on moving forward?
Thanks,
Andrew
Andrew K. wrote:
I’m upgrading an app from 2.3.5 to 2.3.8 and there are many spots where
previous code was output correctly and now it expects html_safe method
calls to properly escape the strings. Are those who don’t want to use
the new escaping behaviour in the 2.3.x branch expected to stick with
2.3.5 from now on moving forward?
I haven’t yet done the conversion of my 2.3.5 app to 2.3.8, will
hopefully do so soon. I intend to do this as a first step in preparing
it for Rails 3. However, as I understand it nothing should change in the
escaping unless you install the rails_xss.
In fact that was the problem with 2.3.6 & 2.3.7. Version 2.3.6
introduced a problem discovered by the HAML guys, and 2.3.7 was a hasty
fix for that, which broken stuff for everyone else. Version 2.3.8 was
supposed to get things back to normal.
I just hit a similar problem where I was concatenating strings with
escapable characters within a formbuilder. I googled about and there
seems to be a some logic being discussed that anything that is “magic
security” is going to be a nightmare. My problems were quite isolated
(the great thing about form builders)
What was:
‘’
Turned into
‘’.html_safe
I am sure there are other ways but this seemed the easiest for me for
string concatenation.
O.
Robert W. wrote:
Andrew K. wrote:
I’m upgrading an app from 2.3.5 to 2.3.8 and there are many spots where
previous code was output correctly and now it expects html_safe method
calls to properly escape the strings. Are those who don’t want to use
the new escaping behaviour in the 2.3.x branch expected to stick with
2.3.5 from now on moving forward?
I haven’t yet done the conversion of my 2.3.5 app to 2.3.8, will
hopefully do so soon. I intend to do this as a first step in preparing
it for Rails 3. However, as I understand it nothing should change in the
escaping unless you install the rails_xss.
In fact that was the problem with 2.3.6 & 2.3.7. Version 2.3.6
introduced a problem discovered by the HAML guys, and 2.3.7 was a hasty
fix for that, which broken stuff for everyone else. Version 2.3.8 was
supposed to get things back to normal.
Exactly. I’m not using the rails_xss plugin, but the escaping rules are
not as they were in 2.3.5. String literals were “safe” in 2.3.5, but
aren’t in 2.3.8… a minor difference with huge implications.
I was looking at hacking the rails code to fix this for my local app,
but wasn’t sure why this would even still be a problem for 2.3.8 when
this release was supposed to “fix” the fiasco that was 2.3.6 and 2.3.7.
Andrew K. wrote:
Exactly. I’m not using the rails_xss plugin, but the escaping rules are
not as they were in 2.3.5. String literals were “safe” in 2.3.5, but
aren’t in 2.3.8… a minor difference with huge implications.
I created a quick-n-dirty test app. See the result here:
http://www.ruby-forum.com/topic/214314#new
Robert W. wrote:
Andrew K. wrote:
Exactly. I’m not using the rails_xss plugin, but the escaping rules are
not as they were in 2.3.5. String literals were “safe” in 2.3.5, but
aren’t in 2.3.8… a minor difference with huge implications.
I created a quick-n-dirty test app. See the result here:
Prevent Helper Automatically Escaping String - Rails - Ruby-Forum
2.3.8 should not require the use of “raw” to do what worked out of the
box in 2.3.5 and every release before that if rails_xss is not
installed.
2.3.8>> " ".html_safe?
=> false
That result right there is why “raw” would be required now in 2.3.8 and
not in 2.3.5. String literals in 2.3.8 should not be false… in rails
3 though that is correct and the expected result.
Andrew K. wrote:
I just wanted to know if others are having this issue, and it sounds
like people are, but I’m still not sure if this is a bug or if this is
the expected behviour for 2.3.8. If this is expected behaviour for
2.3.8 then this should not have been in a “minor” point release and
instead saved for a 2.4 release or something. Quite disappointing.
I don’t know, but my quick test was really quite simple and certainly
didn’t present the behavior I would have expected from a Rails 2.3.x
application:
welcome_helper
def gotcha_helper
content_tag(:script, “alert(‘Gotcha!’)”)
end
index.html.erb
<%= h gotcha_helper %>
Generated HTML - Rails 2.3.8
untitled
Obviously not escaping is being done here and I see a JS alert dialog.
Rails 2.3.5 HTML (in question)
<script>alert(‘Gotcha!’)</script>
All else being equal I’d call this a bug, but that’s just me. Maybe I’m
missing something obvious.
Andrew K. wrote:
Robert W. wrote:
Andrew K. wrote:
Exactly. I’m not using the rails_xss plugin, but the escaping rules are
not as they were in 2.3.5. String literals were “safe” in 2.3.5, but
aren’t in 2.3.8… a minor difference with huge implications.
I created a quick-n-dirty test app. See the result here:
Prevent Helper Automatically Escaping String - Rails - Ruby-Forum
2.3.8 should not require the use of “raw” to do what worked out of the
box in 2.3.5 and every release before that if rails_xss is not
installed.
2.3.8>> " ".html_safe?
=> false
That result right there is why “raw” would be required now in 2.3.8 and
not in 2.3.5. String literals in 2.3.8 should not be false… in rails
3 though that is correct and the expected result.
There are other changes in 2.3.8 that are the cause of the escaping
issues, but at the moment my app is not upgradeable to 2.3.8.
I just wanted to know if others are having this issue, and it sounds
like people are, but I’m still not sure if this is a bug or if this is
the expected behviour for 2.3.8. If this is expected behaviour for
2.3.8 then this should not have been in a “minor” point release and
instead saved for a 2.4 release or something. Quite disappointing.