To be honest, it took me up until about a few weeks ago to come
across a
posting from someone in the Rails community why <%=h is needed to
secure the
output of the user input. I have been developing with rails for
some time
now, and I know a few things about XSS, yet still, while I was
shifting my
paradigm to Rails, I had simply forgot about encoding my HTML
output. The
apps I have written are not blogware, or open to the public so this
wasn't a
major concern of mine, but it brought up a good point. At what
point do we
say, OK, I need to secure my application now.
I find this hard to believe. I heard about escaping with <%=h on my
first day on Rails. Also, I love how escaping has become synonymous
with "secure", when the issue of security goes far beyond html
escaping. For instance, your next point...
Another example to highlight is the :conditions on things such as
model.find. This should always be encoded, and you should have to
override
the default to allow direct data insertion.
That said, when finding all records such as this:
Model.find(:all, :conditions => 'this = "' + params[:xss] + '"')
Should not even be allowed to happen. One method I had found, maybe
a month
after getting into Rails, was a post by Robby mentioning how to use
hash
marks, like so:
Model.find(:all, :conditions => ['this = :this', {:this => params
[:xss]}])
Now, from what I gather that is the secure way of writing a
condition, yet
TONS of people I can guarantee have no idea about this, or even the
simpler
method without the named using the sprintf method. Either way,
security
should be default, and you should have to break off the Rails path
to choose
to open up security holes in your application.
- Nb
How could anybody go through the present documentation on rails and
not come across this? Have you even read AWDWR? I can't even count
how many times this has been presented to me in my reading on rails.
Not to mention, if it hadn't been presented to me, I would have gone
looking for it. It should be common knowledge for any database
developer, whether web related or not, that variables in SQL
statements should be bound. If this syntax hadn't been so accessible
I would have said, "Ok, so how do I bind variables in Ruby...there
must be something akin to my old friend the '?' character from the
Perl DBI."
Furthermore, how do you prevent someone from simply concatenating the
variable into the string? This would require some sort of pre-
compile to detect the presence of the concatenation operator in the
parameter string...and oh yeah, we would need to make sure they
didn't use #{} either. The find method can't know if the string was
written explicitly or pieced together from several variables. This
is a compilation issue...talk about a performance hit!
There are always going to be newbies, and the newbies need
information about how to write "safe" code. Therefore, we must keep
writing it. However, if we attempt to restrict the language in such
a way as to make it impossible to write sloppy code, we'll end up
with nothing more than AppleScript for the web...or worse
yet...HyperCard! However, anybody with the 2-3 years experience it
usually takes to get a job without a supervisor breathing down your
neck while you program will already know this stuff. If they haven't
learned it by now, they're dangerous and should get out of the industry.
Don't tie my hands. If you're scared of your own code, write an
acts_as_diffident plugin. If this email sounds harsh, you can blame
it on the fact that I'm hungry, tired, or both... or perhaps I'm just
right... who knows?
-Derrick Spell
"Perl's grammar can not be reduced to BNF.
The work of parsing perl is distributed between
yacc, the lexer, smoke and mirrors.''
-Chaim Frenkel
_______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
