www.stackhawk.com Open in urlscan Pro
13.32.110.70  Public Scan

Form analysis
0 forms found in the DOM

Text Content

go to homepage
Product
Solutions
Partners
CustomersDocsPricing
Resources
Sign InCreate Account



RAILS PATH TRAVERSAL GUIDE:
EXAMPLES AND PREVENTION

StackHawk|July 27, 2021

In this post, you'll learn what the path traversal vulnerability is and how to
prevent it in the case of the Ruby on Rails application.

 * What's Path Traversal Vulnerability?
 * Path Traversal in Rails
 * Path Traversal
 * Prevention
 * Vulnerable Rails
 * Watch Out for User Input
 * Non-Root
 * Gems
 * Summary



Cyberattacks are happening pretty much constantly these days. Even if you follow
general security best practices, there are many language- and framework-specific
vulnerabilities that attackers can try to exploit. One of these vulnerabilities
is the so-called path traversal vulnerability. 

In this post, you'll learn what the path traversal vulnerability is and how to
prevent it in the case of the Ruby on Rails application.


WHAT'S PATH TRAVERSAL VULNERABILITY?

A path traversal vulnerability, sometimes also called a directory traversal
attack, is a type of vulnerability that allows attackers to access files to
which they shouldn't have access. For example, an attacker may try to access the
/etc/passwd file on your host operating system. 

This vulnerability happens when your web application doesn't properly validate
the paths that the user is requesting. For now, we'll focus on path traversal in
the context of the Rails framework.




PATH TRAVERSAL IN RAILS

In order to understand how path traversal can happen in Rails, we need to first
understand how Rails handles paths in general. There are three most common ways
of serving files in Rails. 

First, we have assets pipeline files. These are all the CSS, JavaScript, and
image files that Rails needs for rendering the HTML code. For example, your
website logo is a good candidate to be in the assets directory. Anything that's
there will have a Rails-generated path assigned. So you don't access these files
directly (as in www.example.com/assets/logo.jpg), but you let Rails generate and
use a path for you. 

Next, we have the Rails public directory. This is a folder where you can put any
file that you need to serve to clients. So, for example, if you need a
marketing1.jpg file accessible as www.example.com/marketing1.jpg, you can just
put it into the public directory. It's worth noting here that serving files from
the public directory can be done by Rails itself but can also be offloaded to a
web server (for example, Apache or NGINX). 

Lastly, we have dedicated libraries for serving images on your website.
Depending on your Rails version, this could be handled by third-party libraries
(such as Paperclip or CarrierWave) or, in the case of the latest Rails versions,
natively by Active Storage. 

Now, all of these different options for getting the path of a specific file will
give you different results. And the possibility of a path traversal
vulnerability differs for all of them. So let's get back to the topic of this
post. What does the path traversal attack actually look like?


PATH TRAVERSAL

You know already that publicly available files in your Rails application are
located in the same folder as the rest of your application. Our goal is to only
show the users the files they're supposed to see. For instance, the contents of
the public folder. But you wouldn't like users to see your Gemfile or
environment configuration files.

Let's look at an example. When a user opens www.example.com/example.jpg, Rails
looks for example.jpg in the /app/public folder. But just two directories higher
is your Gemfile (/Gemfile). 

So you want to avoid the situation where a user simply opens
www.example.com/../../Gemfile and is able to see your Gemfile. That's path
traversal vulnerability: the ability to manipulate a URL in order to read files
that shouldn't be read. Fortunately, it's not that simple, and Rails, by
default, protects you from such obvious misusages. 

However, attackers can try different ways of forcing Rails to go up or down
directories. For example, using URL-encoding characters: 

https://www.example.com/%2e%2e/%2e%2e/Gemfile

%2e is a URL-encoded version of a dot ( . ); therefore, effectively we're asking
for the same path as before: ../../Gemfile. This is just an example.
Fortunately, Rails will protect you from that too. 

But while Rails is smart enough to protect you from most attempts, it's not
bulletproof. So let's talk about preventing path traversal.


PREVENTION

The good news is that because of the way Rails works (you barely write raw code
but you use Rails methods and helpers), you don't need to do anything specific
to protect yourself from path traversal vulnerability. As we mentioned before,
commonly used methods in Rails already protect you from path traversal. 

The problem may arise when you don't use native Rails path-generation mechanisms
or you start generating paths from user input. So the most important prevention
mechanism is to not build any custom path-handling logic yourself and use
Rails-native methods instead.




VULNERABLE RAILS

The bad news is some of the built-in Rails libraries or gems can have this
vulnerability. One of the most common examples is CVE, found in actionpack. 

On the other hand, if you're building a very custom application, you may find
yourself in a situation where you need to, for example, integrate your
application with some legacy system. Sometimes such integrations require you to
handle files and directories on the file system in a non-Rails-native way. 


WATCH OUT FOR USER INPUT

One of the best ways to create a path traversal vulnerability in your
application is to directly use the user input as a variable for path generation.
In many cases, this bypasses default Rails security mechanisms, allowing
attackers to manipulate a path that you never intended them to.

If your use case requires getting user input for building a path, make sure to
validate and sanitize that input before using it as a variable for path methods.


NON-ROOT

Another good practice that can help you avoid a path traversal vulnerability is
to run your application as a non-root user. In the case of a path traversal
vulnerability, this will still allow attackers to get access to the application
directory but will at least prevent them from accessing /etc or /root
directories on your host machine. 


GEMS

Last but not least: gems. We all love gems. They drastically simplify Ruby on
Rails applications development. However, they can sometimes be buggy. While the
most commonly used gems are safe (or at least patched quickly in case of a found
vulnerability), you should be careful when installing gems that are really old
or that haven't been updated for a long time and don't have much information
about them on the internet. Sometimes it's better to write a little bit of extra
code yourself instead of using a gem that was last updated 10 years ago.


SUMMARY

When it comes to the path traversal vulnerability, the bottom line is that it's
a very exotic attack vector, and Rails, by default, protects you from it.
However, that doesn't mean that you're safe and don't need to worry about it. By
using user input without validation or when using very old Rails versions, you
can still become compromised. Path traversal, in the worst-case scenario, can
give an attacker full access to your machine (if, for example, they manage to
read the private SSH key of the root user). Therefore, it's always a good idea
to keep your Rails version up to date. 

But even if you follow security best practices, there's always a chance that
you'll leave one small vulnerable line of code or won't update your Rails in
time. To avoid becoming exposed, you'd benefit from keeping security scanning as
part of your CI/CD pipeline and having a continuous overview of your security
posture. For that, you can use StackHawk. It's a modern application security
tool that can help you avoid not only path traversal but many other
vulnerabilities too. And if you want to learn more about application security
testing, feel free to read this post. 

This post was written by Dawid Ziolkowski. Dawid has 10 years of experience as a
Network/System Engineer at the beginning, DevOps in between, Cloud Native
Engineer recently. He’s worked for an IT outsourcing company, a research
institute, telco, a hosting company, and a consultancy company, so he’s gathered
a lot of knowledge from different perspectives. Nowadays he’s helping companies
move to cloud and/or redesign their infrastructure for a more Cloud Native
approach.

--------------------------------------------------------------------------------

StackHawk  |  July 27, 2021

MORE STACKHAWK

Add AppSec to Your CircleCI Pipeline With the StackHawk Orb



Application Security is Broken. Here is How We Intend to Fix It.



Using StackHawk in GitLab Know Before You Go (Live)

We use first and third party cookies to ensure that we give you the best
experience on our website and in our products. If you continue to use this site
we will assume that you are happy with it and we'll let corporate know.
OKPrivacy policy
Close GDPR Banner

PRODUCT

 * Overview
 * Watch a Demo
 * Snyk
 * CodeQL
 * Documentation
 * Pricing
 * Sign In

RESOURCES

 * Getting Started
 * Customers
 * Config
 * Run Hawkscan
 * Troubleshooting
 * Blog
 * ZAP Fund

COMPANY

 * About
 * Team
 * JobsWe're Hiring
 * Press
 * Security

GET IN TOUCH

 * Contact Us
 * hello@stackhawk.com
 * StackHawk Inc.
   1624 Market St,Ste 226
   PMB 36969
   Denver, CO 80202
 * Follow
 * Visit Stackhawk's Twitter AccountVisit Stackhawk's Linkedin Company
   ProfileVisit Stackhawk's Facebook AccountVisit Stackhawk's Github Account

--------------------------------------------------------------------------------

©2023 StackHawk Inc., All Rights Reserved

|Terms|Privacy

Crafted in Colorado