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.
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.
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.
– 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.
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.