Migrating to rails_xss
dasil003
30,000 line app to make this transition a little smoother. I know
it's going to be hairy because of the hundreds of helpers and oddball
code paths we have. Simply upgrading Rails is certain to be a recipe
for disaster because it's very hard to click through 100+ controllers
and have any guarantee of completeness. I figure it's going to take a
full-on audit to really get to a deployable state. We've mostly been
coasting by filtering user input, and the vast majority of our helpers
just generate HTML willy nilly.
I've been thinking hard about sanitization in general recently, and I
really like the idea of rendering unsafe strings raising an explicit
error or warning. I'm wondering if anyone else has thought about
this, and what kind of tools we could possibly provide to assist
developers in upgrading. There could be a configuration option to log
deprecation-style warnings whenever the auto-escaping was invoked.
This would help in functional test suites where we aren't using
assert_select (for example) for the specific elements that will become
escaped... obviously we wouldn't want it on all the time since once an
app is upgraded its theoretically intended behavior.
Does anyone else think this would be useful or have any other ideas?
Michael Koziarski
> really like the idea of rendering unsafe strings raising an explicit
> error or warning. I'm wondering if anyone else has thought about
> this, and what kind of tools we could possibly provide to assist
> developers in upgrading. There could be a configuration option to log
> deprecation-style warnings whenever the auto-escaping was invoked.
> This would help in functional test suites where we aren't using
> assert_select (for example) for the specific elements that will become
> escaped... obviously we wouldn't want it on all the time since once an
> app is upgraded its theoretically intended behavior.
I'm not sure I follow why you'd want to get a log message every time
auto-escaping is invoked. It's *meant* to be invoked all the time,
I'm not sure that we could reliably detect an *unintentional*
invocation of auto-escaping compared to an intentional escaping of
params[:foo].
> Does anyone else think this would be useful or have any other ideas?
I'm not sure that there's going to be a silver bullet here, perhaps
look into what the django guys did? Maybe there's a clever idea there
somewhere. However I still think the best approach is a manual one.
First thing you should do is test your app in staging with the
rails_xss plugin for 2.3 (once 2.3.5 is out, or using 2-3-stable) that
uses the same fundamental logic.
Audit your helpers for places where you're building up strings instead
of using the content_tag and tag helpers.
Any places you're returning html from a model, make sure it's
sanitized before it's saved, then just mark the model method as safe.
I've ported two relatively sizable apps over and in both cases it was
relatively simple to see what was broken (entire divs missing because
they were escaped, etc) and it was only a day's work. Hopefully a
bunch of other people will go through the same process and we'll be
able to put together a nice "XSS changes" section for the 3.0 upgrade
guide.
--
Cheers
Koz
dasil003
> I'm not sure I follow why you'd want to get a log message every time
> auto-escaping is invoked. It's *meant* to be invoked all the time,
> I'm not sure that we could reliably detect an *unintentional*
> invocation of auto-escaping compared to an intentional escaping of
> params[:foo].
that most strings should end up being html_safe by the time they get
to the template. Part of this is the heavy use of helpers in our code
base. We've been making a lot of effort to refactor and standardize
HTML across hundreds of templates, and helpers are definitely the way
to go here. However in practice there is going to be a lot of auto-
escaping going on in any case. I suppose I should just get my hands
dirty instead of speculating.
