Comments on: rails security review checklist /2010/01/rails-security-review-checklist/ Sarah Allen's reflections on internet software and other topics Fri, 10 Apr 2015 18:26:15 +0000 hourly 1 https://wordpress.org/?v=5.7.1 By: Interesting developments a link dump (some HTML5, some nosql, some Rails, some Agile, some Redis, a touch of Scala, etc., etc.) « turnings /2010/01/rails-security-review-checklist/#comment-659 Tue, 09 Feb 2010 12:58:01 +0000 /?p=2378#comment-659 […] /sarahblog/2010/01/rails-security-review-checklist […]

]]>
By: Caffeine Driven Development » Blog Archive » L33t Links #74 /2010/01/rails-security-review-checklist/#comment-658 Fri, 29 Jan 2010 18:27:05 +0000 /?p=2378#comment-658 […] rails security review checklist […]

]]>
By: Sarah /2010/01/rails-security-review-checklist/#comment-657 Wed, 27 Jan 2010 13:59:11 +0000 /?p=2378#comment-657 Updated post with (0) on checking Rails and gem versions, also 1Aii for the named_scope conditions. Thanks Mike!

]]>
By: Sarah /2010/01/rails-security-review-checklist/#comment-656 Wed, 27 Jan 2010 13:09:49 +0000 /?p=2378#comment-656 Hi Scott,

I had forgotten to add that mass assignment the list (now added as 1A — good catch!). I haven’t tried it yet, but it seems like the ideal solution to just disable ActiveRecord’s powers of mass assignment.

Here’s the initializer recommended by Eric Chapweske:

config/initializers/disable_mass_assignment.rb
     ActiveRecord::Base.send(:attr_accessible, nil)

Thanks!
Sarah

]]>
By: Mike Gunderloy /2010/01/rails-security-review-checklist/#comment-655 Wed, 27 Jan 2010 11:28:21 +0000 /?p=2378#comment-655 On the SQL injection front, you’ll also want to search “conditions” – named scopes, for example, can be vulnerable without having find/first/all in sight.

Another thing to look at is the version of Rails, to make sure that it’s current (or that appropriate patches have been applied). http://groups.google.com/group/rubyonrails-security is the fastest way to get an overview of recent security patches.

For XSS, it’s worth considering installing http://github.com/nzkoz/rails_xss which switches escaping from a “doesn’t happen unless you ask for it” to an “always happens unless you override it” action. This may require application rewrites, but it gives you a safe default.

You need to check all models for appropriate use of attr_accessible/attr_protected to make sure you’re not vulnerable to mass assignment bugs. I’ve particularly seen places where this can be used for escalation of privilege in applications I’ve reviewed.

It’s also worth reviewing the deployment stack, from the operating system through the ruby version to the web server software, to make sure it’s being kept up to date.

]]>
By: Scott Bronson /2010/01/rails-security-review-checklist/#comment-654 Wed, 27 Jan 2010 08:46:26 +0000 /?p=2378#comment-654 Might want to mention mass assignment issues. http://railspikes.com/2008/9/22/is-your-rails-application-safe-from-mass-assignment This one is still found in popular Rails apps.

It’s so easy to fix too: you must use attr_accessible on any model that gets mass-assigned from user-supplied parameters (i.e. @order.update_attributes(params[:order])).

]]>
By: Matthew Lang /2010/01/rails-security-review-checklist/#comment-653 Wed, 27 Jan 2010 08:23:56 +0000 /?p=2378#comment-653 Great list Sarah! It’s been a while since I’ve seen an article on security in Rails. Most previous articles tend to focus on SQL injection and scripting attacks. Good to see other aspects of security in Rails being covered as well.

]]>