5 Common Rails Security Vulnerabilities
Ruby on Rails is a wonderful framework for creating web applications. It provides a lot of great features, is used by many organizations, and the language is one of the best to learn for new developers. As exciting as it is to jump into programming creating an application does not come without some risks. Like all programming languages rails is susceptible to a variety of different security vulnerabilities. OWASP (Open Web Application Security Project) regularly updates a list of the top ten vulnerabilities within programming. In this post I intend to go over a few of these common vulnerabilities that I think a new Rails developer should be aware of, and provide some resources on how to avoid others.
SQL Injection
Thanks to Rails’ doing a lot of the work under the hood for us many of the methods available for database queries are secure. However, there could be times where it could be necessary to write a query that falls outside the scope of normal queries. When these times do occur, it is important that a developer be careful to ensure that they are creating the query to their database that they are as narrow and specific as possible so that the user making the query can only access the information they are authorized to access. Rails has provided a website that can help new developers avoid some of these pitfalls.
Sessions
Sessions are a fantastic way to scramble a user’s authentication token and save the information about that user without having them to log in on every page or every time they return to your web-application. However, they although they are more secure than a traditional cookie, they do not come without their own set of vulnerabilities. First, in Rails, a session does not expire. To mitigate this it would be best to implement either a gem, like devise, that will sign their users out of their session upon closing the application, or setting up an expiry time window. Pictured below is the documentation for setting up a session expiration window.
Second, a session could also be vulnerable to a variety of forms of session hijacking. According to wikipedia, there are four major methods used to hijack a users session: session fixation, session side-jacking, cross-site-scripting, and malware. For more information, please follow the link:
Gem Vulnerabilities
Ruby’s gems make life so much easier. Gem libraries like Twilio, bcrypt, bootstrap, rest- client and many others can add a lot of dynamic functionality to a web application. Finding new ones can be very exciting. However, they do not come without their own set of worries. Because Ruby is open source, bad actors can take advantage of various libraries. In July, the community responsible for maintaining Ruby Gems took down 18 malicious versions of 11 gem libraries, one of which being rest client.
Be sure that when you are looking into new or commonly used gems to include in your application that there are currently no vulnerabilities currently being exploited. If there are and you would still like to take advantage of a gems functionality consider making sure that you are using the safest version of the library.
Sensitive Files
Because many web applications are hosted on GitHub much of their repositories can be accessed and viewed by others. Therefore it is a good idea to remove these sensitive files before pushing them to github. OWASP offers a list of example files to remove:
Ensuring Users are being Secure
There are multiple ways to ensure that when a user is using your application they are using best practices to make themselves less vulnerable any potential exploits. Be sure to set up strict and strong validations that ensures a User is using your app as intended. If they are storing a password, be sure to include validation parameters that will make sure their password contains a mixture of uppercase and lowercase letters, numbers, and symbols. Moreover be sure that your method for storing passwords does not store them in plain text. Gems like bcrypt and divise are great resources to ensure users are creating complex passwords, and that they are not being stored as plain text.
Furthermore consider providing either a tutorial, or some documentation to provide users on best practices for how to use your app ( don’t reuse passwords, don’t use common passwords , don’t transmit sensitive data over unknown networks, etc.). No app is 100% secure so it is absolutely imperative that we do our best to ensure that our users are doingo best to protect themselves as we do ours to protect them.
These are just a few vulnerabilities any developer should be aware of. And thankfully many of them can be managed through setting up the proper authentications, authorizations, strong parameters. However, it is important that either you or someone on your team be familiar with these vulnerabilities to make sure that you are mitigating security vulnerabilities and not creating them.
Links to resources:
Ruby’s guidelines on handling security
Rails’ examples on how not to write sql queries
