Ruby on Rails Security Guide

Victor Rak

Victor Rak

Ruby on Rails Security Guide

Why use Ruby on Rails? Rails is one of the most comfortable frameworks. Due to the concise code and ease of learning, RoR is a favorite platform for both small teams and large-scale enterprises. What is Ruby on Rails used for? RoR was used to create such renown sites as Twitter, Airbnb, Github, Groupon, Basecamp, Scribd, Kickstarter, CrunchBase, and many others.

 

Why use Ruby on Rails: Why do we consider it a safe platform?

 

Ruby on Rails was released in 2005 and over the next 6 years has become very popular, in part thanks to Apple support. However, 2012 and 2013 became the “black” times for the framework. The security of the popular framework and projects based on it has undergone serious tests. Many vulnerabilities were discovered and announced, many constructive and not criticism was voiced. For some time, ill-wishers even altered the RoR’s slogan – “Web development that does not hurt” – to “Web development that hurts a lot”.

 

Nevertheless, the Rails developer community did not stumble and all the vulnerabilities were leveled one-by-one. Even to this day, the security elements of the platform are regularly updated, augmented and improved. The classic attacks such as SQL injection, file inclusion, XSS, CSRF, etc., are impossible in RoR or the protection against them is a part of platforms code. Currently, Ruby on Rails is rightfully considered one of the safest development environments.

 

What are the major vulnerabilities that are eliminated using the Ruby programming best practices?

 

The framework has an ideal balance between the development convenience and protection against attacks. It is well defended against most known types of malicious attacks due to the built-in security solutions. However, despite all the in-built security measures, careless Ruby programming can still make an app vulnerable. Let us review the Ruby on Rails security best practices.

 

The types of attacks to which RoR websites are exposed most often

 

XSS. Cross-site scripting (XSS) attacks are considered the most dangerous and devastating for web applications. Malicious code can be injected through various entry points such as posts, comments, guest books, project and document titles, search result pages, etc. Even URL parameters can serve as attack vectors. The application saves the altered element and later it can be presented to users. The injected code may manifest after a prolonged period or in various parts of the site simultaneously. Most software developers rely on the default XSS filters, forgetting that this type of attack has a complex structure. In particular, problems arise when developer inserts data in the unsafe format (JSON, for example) into JavaScript inline. In this case, it is better to use other, safer methods instead of inline scripting or to convert the data into a more secure format;

 

CSRF. Cross-site request forgery (CSRF) attacks, which are based on the HTTP transmission protocol vulnerability, can have a negative impact on the performance of your web application. Such attack operates under the assumption of already active user privileges. Fortunately, Ruby on Rails has a built-in protection mechanism against this type of attack – authenticity tokens. However, it would not hurt to follow the additional recommendations, namely, carefully plan all the POST and DELETE requests;

Mass assignment. The mass assignment allows setting a bunch of attributes at once. Without the convenience of mass assignment, we would have to write an assignment statement for each attribute to achieve the same result. Parameters in MVC applications are transferred as a hash. When the controller receives such hash, it is conveyed into the model unchecked and unchanged. This vulnerability is characteristic to many known MVC frameworks. Using it, hackers can execute the malicious code without the knowledge of the site owner. Ruby on Rails employs a special ‘strong_parameters’ module that allows indicating explicitly, which data cannot and which can be mass assigned;

SQL-injections. SQL-injections are, by far, the most favorite way of hacker attacks. Most ORMs block the unsafe input parameters by default. However, there are a number of methods, which allow the transfer of unverified data, thereby potentially exposing a website to an attack. You can read about the SQL-injection attacks and ways to protect your application in more detail at the OWASP Cheat Sheet;

Clickjacking. Clickjacking is a type of network attack in which a user, clicking a page that an attacker “tied” to your site, actually visits another site. Typically, this type of attack is used to increase the attendance of the outside resource and there is no actual harm done to your website. Nevertheless, since the fourth version of Ruby on Rails there is a clickjacking prevention mechanism that operates by adding the HTTP header “X-Frame-Options: SAMEORIGIN” to natively generated pages;

Session interception. RoR stores the user sessions in a signed cookies, using HMAC secret keys. Ordinary users cannot change the session parameters, but they are readable (which means that hackers can use them for personal purposes). That is why experienced developers strongly recommend against storing such data client-side. To ensure the session safety it is also advisable using the methods of ‘activerecord-session_store’ gem to process and store sessions.

 

 

Final thoughts on Ruby on Rails security

 

Ruby on Rails has a number of internal protection mechanisms (including the gem security tools). Nevertheless, some developers are oblivious to their existence or use them incorrectly. Therefore, in order to secure your web application, we strongly recommend that you take into account the above Ruby on Rails security tips.

Leave a Reply

Your email address will not be published. Required fields are marked *

Join our Newsletter