Security Checks you must do before Rails App release

Security Checks you must do before Rails App release

3 Minutes Read

Security-ChecksYou should do minimum security

checks before releasing the rails app to the public. The possible threats could be hijacking user accounts, manipulation of access control, accessing sensitive data & doctoring with garbage contents. You should act proactively to protect your valuable information.

Here you go with some useful security tips which you cannot ignore. Courtsey,:Ruby on Rails Security Guide.

  1. Don’t trust logged in users (Authentication != Authorization)
    • Always check whether the current logged in user is allowed to perform operation like create, update, delete and view.
    • Devise, a library which handles authentication, to verify that you can only get to the destroy action if you’re logged in. However, Devise does not handle authorization.
    • Apart from authentication authorization must be checked prior to allow any data sensitive operation.
  2. Mass assignments vulnerability. (Use attr_accessible in your models!)
    • ‘Mass Assignment’ is the name Rails has given to the act of constructing your object with a parameters hash. Using “mass assignment” that you can assign multiple values to attributes via a single assignment operator.
    • A ‘params hash’ can contain anything, so protect all sensitive attributes from re-assignment. The best way to do this is by disabling mass assignment using ‘attr_accessible’ (or attr_protected) in your models.
  3. Prevent your attribute being changed from outside with attr_readonly
    • Remember to disable updating protected attributes.
    • Using ‘attr_readonly’ declaration of ActiveRecord allows the attribute to be set on create, but never edited on update.
  4. SQL Injection(SQLi)
    • SQL injection (SQLi) is a code injection technique in which a user can manipulate a database in an unintended manner. Consequences of SQL injection vulnerabilities range from data leaks, to authentication bypass, to root access on a database server.
    • To get rid, never include user submitted strings in database queries. Check all model scopes and find conditions that include ‘params’ or interpolated strings.

    Instead of using such unsafe code

Post.all(:conditions => "title = #{params[:title]}")

You can have safer, simpler code like

Post.all(:conditions => {:title => params[:title]})
  • Prevent executable files from being uploaded
    • We should always distrust the user/browser provided information, to make decisions on a file’s mime/content type.
    • Validate the content type of all attachments, and place uploaded files in protected directories or on another server/service e.g. S3/Cloudfront.
    • Content-types can easily faked, so check the file extensions and be sure to disable your web server from executing scripts in the upload directory.
    • Also, beware of plugins creating or writing in temp directories during file upload operation.They may create files or directories from user submitted ‘params’ without checking the file path.
  • Avoid Redirection
    • Avoid using redirects to user supplied URLs like redirect_to(params[:some_parameter]).
    • When the arguments for a redirect comes from ‘params’, you are open to redirect to unintended URLs.
  • Security updates and patches of Gems and Plugins
    • Always check your dependencies for security updates and patches.
    • If possible subscribe to the GitHub issues list (or any mailing list) of the gems or plugins you are using.
    • Always specify the version to avoid undesirable breaks to your code.
  • Passwords in the database
    • Never ever store passwords in the database as clear text.
    • Encourage strong alphanumeric passwords and if necessary follow other strong password practices (like multiple failed logins, password expiry/reset etc.)
    • Keep encrypted password in your database like the one devise generates.
  • Make non-ActionController methods private
    • Check whether the methods you have declared in a controller is accessible to the public.
    • Change accordingly in your ‘routes’ so that it is private and inaccessible to the public.
  • Include CSRF token in all form submissions
    • Include ‘csrf_meta_tag’ helper in the HTML head tag in Rails 3.
    • Enable ‘protect_from_forgery’ and use form helpers to include the Rails authenticity token in all form submissions.

SEE ALSO: Security Patch to deal authentication bypass for RoR

Of course, this list is incomplete. Perhaps you can think of something to add to it? Post it in the comments section below.

Srikant M. Mohapatra
No Comments

Post A Comment

Exit pop up

Sad to see you leaving early...

From "Aha" to "Oh shit" we are sharing everything on our journey.
Enter your email address to stay up to date with the latest news.
Holler Box