Securing your Ruby and Rails Codebase
Need help securing your Rails apps? We are here to help at email@example.com.
When writing software you want to avoid introducing functional bugs or security issues.
For functional bugs, we usually write unit tests and try to cover edge cases. Integration tests then make sure that things work together.
In this article, we will walk through how we can secure a Ruby, Rails, or Rack-based app.
No matter if it is a new codebase, or we are adding it to a 10-year-old project, in the end we will have a decent level of security testing.
For this article we will be using open-source software tools to secure our codebase. We will also consider some hosted and already configured alternatives.
- rubocop (has some security rules)
The tools can be categorized into Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools.
Static analysis scans your codebase and looks for certain kinds of patterns. It will not execute your code and cannot detect problems in generated code, or at runtime.
The results will usually show the line of code the issue is detected. They will also alert you to the type of issue identified (with a severity), and sometimes an advisory on how to fix the problem.
In contrast, software composition analysis will check the dependencies you are using for vulnerabilities.
The report usually includes:
- The package name of the affected dependency.
- Severity on how bad it is. This usually spans from
- The next safe version to upgrade to.
- Some more references that explain what the problem is and more details.
- In some cases an identifier that leads to a vulnerability database.
To run the security tools, you do not need a CI pipeline but it is generally recommended to have one in place.
We will install the tools in a ruby/rails project. You will also learn how to enable the rake tasks and run them.
All the tools also have normal executables and can be used one by one, or in a shell script.
Bundler Audit will detect vulnerable dependencies in your codebase
First, add the bundler-audit gem to your Gemfile:
and install your bundle.
Now you can run a
bundle audit check --update
This will update the local database first, and then check your project for vulnerable dependencies.
Keep in mind that
bundle audit does not update the dependencies automatically. I recommend you to always update them before each run to ensure you get the best and most up-to-date results.
To enable the rake tasks, add the following to your project Rakefile:
require 'bundler/audit/task' Bundler::Audit::Task.new
rake bundle:audit will now update the data and perform the checks.
If you found any vulnerabilities at this point do not freak out. You can look into fixing them by updating the version to the next safe one.
In case you can not update, you can use the
--ignore $vulnerability-id to suppress it for now.
bundle audit check --update --ignore OSVDB-108664
The output looks something like this:
$ bundle audit check --update Updating ruby-advisory-db ... From https://github.com/rubysec/ruby-advisory-db * branch master -> FETCH_HEAD Already up to date. Updated ruby-advisory-db ruby-advisory-db: 322 advisories Name: omniauth-oauth2 Version: 1.0.2 Advisory: CVE-2012-6134 Criticality: High URL: http://www.osvdb.org/show/osvdb/90264 Title: Ruby on Rails omniauth-oauth2 Gem CSRF vulnerability Solution: upgrade to >= 1.1.1 Name: rubyzip Version: 1.2.1 Advisory: CVE-2018-1000544 Criticality: Unknown URL: https://github.com/rubyzip/rubyzip/issues/369 Title: Directory Traversal in rubyzip Solution: upgrade to >= 1.2.2 Vulnerabilities found!
Next, we will add Brakeman as our first static code analysis tool. Brakeman will look for known insecure patterns and configurations in your code base. It will also check if you are using a known vulnerable rails version.
Brakeman works not only for Rails, but it also covers Sinatra and any kind of rack application.
First, add the dependency to your Gemfile:
and install it:
Then you can run it for the first time in your rails root directory.
This will invoke Brakeman and output some lengthy report. Here is a gist with a sample report: https://gist.github.com/pxlpnk/4a829b6101abe5fc0102d358d8dd028d
If your app is safe and you get no findings run it, first of all good job!
But then you want to see how it looks like, so you can try it with OWASP/RailsGoat.
If you run Brakeman for the first time on any older Rails application you might get a lot of findings.
To make things easier, you want to start with more severe issues and work down to the less critical ones.
To do so, use
brakeman -w3 and it will show only high,
-w2 will show high and medium,
-w1 will show all other findings.
Approaching it level-by-level usually works the best and is the most efficient.
If you plan to use rake, you can install the RakeTask very easily.
will create a task file in
lib/tasks/brakeman.rake which can be run with:
To customize it and use more advanced options see the documentation brakeman as a library/.
While rubocop is known as a linter and formatter, it comes with some security rules and can be extended with some community extensions.
Let us get started with installing RuboCop first. Add the following to your Gemfile:
gem 'rubocop', require: false
Then run our old friend
Once this has finished, you can execute the
If you have not used rubocop before you might see a lot of output and warnings printed out in your terminal.
For this post, we are not so much interested in the linting and formatting rules. Instead we make sure we only run the security relevant rules.
We will be using the following
.rubocop.yml configuration to start out.
AllCops: DisabledByDefault: true Security/Eval: Enabled: true Security/JSONLoad: Enabled: true Security/MarshalLoad: Enabled: true Security/Open: Enabled: true Security/YAMLLoad: Enabled: true Bundler/InsecureProtocolSource: Enabled: true Rails/OutputSafety: Enabled: true
We are disabling all the style and linting rules, and enabling only security-relevant ones. This is only done for simplicity in this blog post.
rubocop command now should be way less noisy.
This is how it looks like on the RailsGoat repository:
$ bundlex exec rubocop Inspecting 121 files ............C.................... Offenses: app/controllers/password_resets_controller.rb:6:20: C: Security/MarshalLoad: Avoid using Marshal.load. user = Marshal.load(Base64.decode64(params[:user])) unless params[:user].nil? ^^^^ 121 files inspected, 1 offense detected
Not too impressive yet, but we are getting some relevant security info already.
Now we will add some more security rules.
Add the following to your Gemfile:
gem 'rubocop-gitlab-security' and run
bundle install again.
Now add the following to the configuration file
GitlabSecurity/DeepMunge: Enabled: true GitlabSecurity/JsonSerialization: Enabled: true GitlabSecurity/RedirectToParamsUpdate: Enabled: true GitlabSecurity/SendFileParams: Enabled: true GitlabSecurity/SqlInjection: Enabled: true GitlabSecurity/SystemCommandInjection: Enabled: true
Those curated rules by the GitLab team add tremendous value to our security setup.
Now we need to require the new modules when running RuboCop:
Either by running:
bundle exec rubocop --require rubocop-gitlab-security
or add this to the
We can now find more security problems in the RailsGoat repository. Here is a gist with a sample report:https://gist.github.com/pxlpnk/958c500aab22f90b54918d6d9573251d
To configure the RakeTasks add:
require 'rubocop/rake_task' RuboCop::RakeTask.new do |task| task.requires << 'rubocop-gitlab-security' end
to your RakeFile and run it:
To not drown in findings I recommend you configure and enable one scanner at a time.
Start with high severity findings and filter out the rest.
Some of the results will be false positives or are no danger at all for various reasons. They can usually be ignored and added to a list to not be noisy.
Once you have fixed or muted the findings and it behaves as you would like, move on to the next one.
When you have reached the point that you feel happy and comfortable with your setup, enable these tools to fail your CI builds and run them on every code change you commit.
Now you will always know when something is not up to your security standards.
Hosted Services and Other Alternatives
In addition to the open source tools that are available, there are also a set of commercially available tools.
Open Source Security Tools are Great
The ruby community has put massive effort into creating those tools. They are free for everyone to use and should be supported!
If you can afford it, send them some money or other support so they can continue and improve the tools in the future.
How do you secure your codebase? Let me know at firstname.lastname@example.org.