I’m reviewing the security of a web app built with Ruby on Rails, so I put together a checklist for a security audit. This isn’t a bank or high security situation, but there were a number of engineers and quite a bit of open source code, so I thought a few checks were in order.
Here’s the list I came up with that I thought other folks might appreciate as a starting point (special thanks to the sfruby list, Mike Gunderloy, and Scott Bronson for feedback):
0) Make sure your Rails and gems are up to date for latest security patches (see rails security mailing list for recent advisory notes)
1) Active Record audit:
A) SQL injection:
(i) whole word search for “find”, “first”, and “all” then visually inspect all instances of ActiveRecord find calls for potential SQL injection vulnerability (also search for “sql” not whole work search to find find_by_sql and “execute” to find cases where raw sql is executed.
(ii) search your models for “named_scope” and check :conditions
B) check for mass assignment Either disable mass assignment as Eric suggests in his article, or audit its use. If doing an audit, check every model to make sure it declares which attributes are settable with attr_accessible. (While attr_protected may technically work, a white list approach is recommended by security experts and the rails security advisory on this topic)
2) Scripting attack: search all eRB files for <%= and ensure that if dynamically generated text was originally entered by the user, it is HTML escaped. Consider rails_xss
3) Secure Access: If some of the site does not have public access, check controllers and ensure that public actions are specifically allowed and that protected access is the default
4) search for “eval” (whole word) and verify that usages are safe
5) search for “forgery” (not whole word), make sure that
config.action_controller.allow_forgery_protection = false
is only disabled in test config
protect_from_forgery should be in the ApplicationController, unless there is a good reason for it not to be
6) check user auth and review that controller actions are limited to expected use
7) passwords: not saved as clear-text in the db, not logged
8) check that private data is not stored in cookies
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.
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])).
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.
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
Updated post with (0) on checking Rails and gem versions, also 1Aii for the named_scope conditions. Thanks Mike!
Pingback: Caffeine Driven Development » Blog Archive » L33t Links #74
Pingback: Interesting developments a link dump (some HTML5, some nosql, some Rails, some Agile, some Redis, a touch of Scala, etc., etc.) « turnings