Last Updated on November 20, 2020 by Christopher G Mendla
During my interviews in my recent job search, I’ve seen an alarming number of companies running on Rails 3.x and 4.x. Unless serious work arounds have been applied, these versions have multiple vulnerabilities.
Any software goes through a continuous process of improvement. New features and functions are added. More importantly, security issues are addressed. Ruby on Rails applications have four major areas where they can be exploited.
As of November 2020, Rails versions prior to 126.96.36.199 have an actionview vulnerability that must be addressed
For this post, we will concentrate on vulnerabilities in Rails.
As of November 2020, Rails should be at 188.8.131.52
I just spent a couple of days updating my rails profile site to 184.108.40.206. GitHub’s dependabot was showing a notice that there were vulnerabilities in my code.
Working through the notices showed that there was a vulnerability in actionview for Rails versions prior to 220.127.116.11. The notice did mention possible work arounds. However, the cleanest way to fix the situation was to upgrade to 18.104.22.168. That turned out to be a bit of work as the upgrade to Rails 5.2 is a little involved.
An alarming number of companies are still running Rails 3.x or 4.x. That almost certainly means there are vulnerabilities in their application.
As of November 2020, if you look at the Wiki for Rails, you will see that versions of Rails prior to version 5 are unsupported. That means that any vulnerabilities in those versions are not being fixed. That is a hacker’s dream. Another good resource is cvedetails which will show all the vulnerabilities for Rails.
There are a number of possible reasons. Doing ‘mundane’ update work just isn’t sexy. In a previous position, upper management was critical of our team because we weren’t “Putting out enough new features”. The team was an Operations and Maintenance team. Each of us had four production apps to maintain as well as doing bug fixes and some new development.
The accolades went to the teams that were developing new applications, not to the O&M team that was keeping the applications secure.
In a previous position, members of our team were criticized for “Spending too much time on updates and maintenance” even though the constant integration system would preclude builds if the apps were not updated. Management wanted to report new features.
Maintaining and upgrading applications takes time, money and resources. For a company that is on Rails 3.x, the prospect of moving toward the current version, 6.x at the time of this post, is daunting. Quite often, the development teams are in a Dilbert like world where the pointy haired bosses don’t understand the necessity for keeping current.
A major version upgrade of Rails can be time consuming and poses risk. In many cases, supporting applications such as Postgres or the Ruby version might need to be updated.
A number of Rails updates I have done have either broken Rspec tests or required changes to the gems and applications that support Rspec.
If you are using GitHub, the ‘dependabot’ feature will alert you if your master branch has vulnerabilities.
The team should have a plan to constantly be upgrading. Letting the version stagnate for a year or two because you didn’t have the resources or because working on updates didn’t put the developers on a promotion path will cause problems later.
It isn’t necessary to always be on the latest version. There is risk to being an early adopter. Set a target perhaps for being no more than two minor versions behind the latest stable version.
In general, updating to the next minor version is usually straightforward. There are exceptions such as updating to Rails 5.2
Updating to major versions usually requires more work and poses more risk.
Updating Rails isn’t sexy or career enhancing but you need to keep ahead of any vulnerabilities. Establish a plan and be sure that efforts to update the code base are rewarded and not punished.
Your email address will not be published. Required fields are marked *
Save my name, email, and website in this browser for the next time I comment.