Whether you’ve been using Ruby on Rails for a while or are about to start, you might be worried about the framework’s possible vulnerabilities. It debuted in 2004, which makes it 16 years old this year — a reason to worry. Or not?
Is Ruby on Rails secure in 2020? The short answer is yes. The framework/language combination has never been more secure than it is today. Nevertheless, we don’t recommend playing fast and loose with it (or any other framework).
This article explains why Ruby on Rails vulnerabilities are only minor security issues and what precautions you can take to be on the safe side.
What Makes Ruby on Rails So Reliable
In the case of Ruby on Rails, whether you are just about to start using the framework for your project or have been using it for a while, age is an ultimate advantage.
The framework has matured for more than a decade. Top companies in a range of markets, from software development to real estate, have been running on Rails since their inception.
You’ve probably already used many of the applications that were built with Ruby on Rails: Basecamp, GitHub, Shopify, Airbnb, Twitch, SoundCloud, Hulu, Zendesk, Square, Cookpad, and more. As major players cleave to the framework, they contribute to its further development and improvement of its security.
The latest major vulnerability discovered with the framework dates back to 2012. Egor Homakov, a security researcher, found out he could remotely execute particular tasks, such as committing to master, reopen and close issues in Issue Tracker. The programmer managed to hack GitHub without doing real damage — just to demonstrate that it could be done.
The community had spotted Ruby on Rails vulnerabilities throughout the years, but most of them were minor issues that professional RoR developers have been studying until they knew them cold. Since 2016, there haven’t been significant unpleasant discoveries in this area.
The Ruby on Rails community is worth emphasizing as another factor that makes the framework a secure choice. Its official group on Google features 69,232 topics, while Stack Overflow boasts 319,053 relevant questions, many of which are actively discussed.
All this means that if you encounter a security problem, you can reach out and get help from the community.
Human Element As the Root of All Evil
What is crucial to know about security is that most of the breaches and leaks happen because of the human element.
Negligence, unawareness, and social engineering are the main threats to Ruby on Rails applications. These can threaten your web product at every stage, from its very first day to many years down the track.
We’ve often had to clean up after the original development team who failed to keep an eye on things. Some examples include:
- Developers who left the password from the database in the source code. Hackers got hold of the code, extracted the password and stole sensitive business data.
- A front-end team who placed the AWS API Access Key in the source code. Perpetrators used the key to tap the company’s cloud infrastructure and launched a Bitcoin mining farm on multiple remote servers. As a result, the business lost a substantial amount of money in a single day.
- A DevOps engineer who, after making some changes, forgot to restrict access to the caching database for the outside world. A significant amount of data was stolen through this loophole.
- Developers who tend to forget to hide pages from search engines. Some of these pages can contain sensitive information, which is compromised as a result.
- Developers who fail to make timely updates to libraries, frameworks, and infrastructure elements; this is also one of the most typical reasons for exposure and undesired consequences.
As you can see, it makes sense to establish mandatory best practices for staff who have access to your website. It’s never too late to do that, but the earlier it’s done, the safer it will be for your company.
Major Ruby on Rails Security Threats
Rails is one of the safest frameworks to run on when you know what its security issues are and how to fix them.
The most common Ruby on Rails security threats are typical to all other frameworks. The CVE Details website has been tracking vulnerabilities in the framework since 2006. Most vulnerabilities were revealed in 2013, while the latest discoveries date back to 2017. Let’s take a closer look.
Ruby on Rails vulnerability statistics according to CVE Details
Note: Work towards ensuring security of your Ruby on Rails application before it goes live. It will be a target for hackers from its first day online.
XSS Attacks
Number one in vulnerability statistics for Ruby on Rails is Cross-Site Scripting (XSS) attacks. The attackers exploit XSS vulnerabilities in the code of a trusted website to inject malicious scripts into it.
If a vulnerability of this kind is not fixed, the web application is easily hackable. We once had to clean up for a client after one attacker had entered a specific line of code into the username in his profile. He commented on multiple pages on the website and other users landing there were automatically redirected to his own site.
SQL Injections
The second most widespread vulnerability of Ruby on Rails websites is SQL injections (SQLi). If you use a MySQL, Oracle, SQL Server or any other SQL-type database, be warned. The attackers can gain control over the database server behind your web application by executing a malicious SQL statement.
Criminals can use this type of attack to access sensitive data such as personal information of your customers, classified documents, and even passwords from other sources. If you fail to take precautions against SQLi, financial and legal consequences can be devastating.
Denial of Service
Denial-of-service (DoS) attacks make up about 16% of all threats to Ruby on Rails applications. The attackers can make a resource unavailable to its users by flooding it with a slew of requests that are too heavy for the website to handle.
According to CVE Details, nine DoS vulnerabilities have been detected with Ruby on Rails versions up to 5.0.0.beta1.1 (2016) while the latest framework version, 6.0, arrived on August 15, 2019. This is proof of how important it is to keep up to date.
But you might need a little more than updating. Distributed DoS (DDOS) attacks have lately been a nuisance for many companies that have drawn attention to themselves. We have been able to neutralize multiple distributed DoS (DDOS) attacks with the help of a third-party application.
Bypass Something
The fourth most common threat to Ruby on Rails applications that a DevOps should be aware of are the loopholes in the security which allow attackers to get inside. Typically, hackers manage to bypass
- intended validation steps via crafted parameters (before 5.0.0.beta1)
- intended change restrictions by manipulating the nested attributes feature (before 5.0.0.beta1)
- authentication by measuring timing differences (before 5.0.0.beta1)
- intended database-query restrictions to perform NULL checks or trigger missing WHERE clauses via a crafted request (before 4.0.2)
You can prevent these attacks by establishing a reliable access policy execution process, designing a strong authentication system architecture, and setting strict safety guidelines for developers who work with the application.
[optin-monster-shortcode id=”c204mqnkkjvtapvhj1jz”]
General Safety Rules to Prevent a Breach with RoR
Whether you are about to start building your Ruby on Rails application or want to improve the security of an existing product, follow these guidelines:
- Stay informed about the latest threats. Subscribe to relevant mailing lists and check out security blogs on a regular basis.
- Have a security check schedule in place and follow it through.
- Establish rules, workflows, and guidelines for everyone who modifies your application. Make sure that these are being complied with, especially when outsourcing development.
There are more specific steps that you can take to further boost the security of your Ruby on Rails application. Provide users with a prominent log-out button; use cookies only for the session-relevant data; disallow <script> tags across the website; use a stored timestamp so that your app invalidates old-session cookies; this list can go on and on.
Try to at least hardcode the three general guidelines above into your security routine early enough, and the odds will be in your favor. This will work both for a simple website and something more advanced, like a custom CRM.
Conclusion
We hope that this post has proven to you that Ruby on Rails security remains solid in 2020 and will continue improving. Now that you are better informed of potential threats and appropriate precautions, you can take them into account in future.
If you need to ensure that your application is secure, don’t hesitate: contact us right away.
Rubyroid Labs is the Ruby on Rails development company. Learn more about our services.
Rubyroid Labs is mention in the List of Best Ruby On Rails Development Companies & Ruby on Rails Expert Developers on TopDevelopers.
