Securing Ruby on Rails Application

8 minute read

This blog post explains common vulnerabilities in ruby on rails applications with mitigations and patch recommendations.

CSRF (Cross Site Request Forgery)

By default ruby on rails application prevents Cross-Site Request Forgery attacks using the authenticity_token in the POST request in newly created rails applications.

POST /posts HTTP/1.1


For older versions of the rails application you can manually enable the CSRF protection by introducing protect_from_forgery in your application controller.

class PublicAppController < ActionController::Base

Also, this is to be noted that by default ruby on rails application does not protect an application from CSRF attacks in GET requests.

Blog Post about How I was able to invite users as admin in the organization by Exploiting XSS and CSRF.

Cross Site Scripting

By default ruby on rails provides protection against cross site scripting attacks.

default case if your print any parameter it will not be vulnerable to XSS attacks for example:

<% if params[:name] %>
<%= params %>

But if you used he below-mentioned cases it, then cross-site scripting will be introduced in ruby on rails application.

XSS using content_tag:

<% if params[:name] %>
<%= content_tag params %>

XSS using raw:

<% if params[:name] %>
<%= raw params %>

XSS using html_safe:

<% if params[:name] %>
<%= "<a>#{params}</a>".html_safe %>

Fix Cross Site Scripting :

sanitize function can be used to prevent cross-site scripting attacks. But this function does not properly sanitize and has been identified as flawed numerous times. this function is also prone to HTML injection attacks.

To fix cross-site scripting vulnerabilities use rails HTML sanitizer gem ( ).

A sample function to sanitize tags and attributes using rails HTML sanitizer.

require 'rails-html-sanitizer'

Allowed_tags = %w[h1 h2 h3].freeze
Allowed_attributes = %w[style].freeze

def filter(s, tags = Allowed_tags, attributes = Allowed_attributes)

	return '' unless s

    sanitizer =
    string = sanitizer.sanitize(s, tags: tags, attributes: attributes)
    html_string = string.gsub(/\"/,"'")
    puts html_string

calling the filter method with user input as filter("<h4 onclick=alert(1)>XSS</h1>") will only return XSS string. The function will block XSS attacks but is prone to html injection.

Another gem that I recently explored is loofah. let’s create a small function using loofah and blacklist HTML tags using it.

require 'loofah'
require 'rails-html-sanitizer'

Disallowed_tags = %w[a iframe].freeze

def filter(s , disallowed_tags = Disallowed_tags)

	scrubber =
	scrubber.tags = disallowed_tags
	html = Loofah.fragment(s)
	f_string = html.to_s
	puts f_string


Now calling the function with user input as iframe payload:

filter("<iframe src=x> xss testing </iframe>")

which will print only xss testing. So, this is how we can filter required tags using loofah.

Another XSS is ignored many times is found numerous times in link_to

<%= link_to "site link", %>

if the contains user_input as javascript:alert(1) then it will trigger XSS, and link will be generated as:

<a href="javascript:alert('1')">Site</a>

SQL injections

By default, ORM ( Object Relational Mapper ) prevents the SQL injection attacks in ruby on rails application.

User.where([name LIKE ?, params[:q])

Passing the parameter as plain SQL query will lead to SQL injection attacks.

User.find_by_sql("name LIKE #{params[:q]}")
User.where("username = #{params[:username]}")

SQL injection in find_by

user = User.find_by(params[:id])

find_by is prone to SQL injection attacks. This can be fixed using find_by_id

user = User.find_by(id: params[:id])

More examples of SQL injections in ruby on rails can be found at - [ ]

Fix SQL injections:

An other solution to fix SQL injection attack in ruby on rails is to use ransack queries.

Local File Read

Local File Read vulnerability in ruby on rails application occurs when user input is directly passed into file opening methods. for example:

file_path = params[:user][:file_path]
file =

To fix local file read vulnerabilities we can create a blacklist-based method that converts the special characters into blank space.

def s(string_)
	bad_chars = [ '/', '', ':', '"', '<', '>', '.', ' ' ]
	bad_chars.each do |x|
		string_.gsub!(x, '')
	puts string_

Backlists are always prone to bypass using different encodings like URL encoding, Unicode encoding. So it’s always recommended to implement a whitelist instead of a blacklist.

here’s an example of a whitelist function that only allows specific pages and the rest of the user inputs are blocked.

def lfi_whitelist(string)
	arr = ["posts", "gallary"]
	counter = 0
	for x in arr do
		x = string
		counter += 1
		if x.match("^posts$") or x.match("^gallary$")
			puts x
		break if counter==1

So if you call the function function like lfi_whitelist("../../../etc/passwd"), the function won’t return anything.

SSRF Vulnerability in Rails Application:

SSRF vulnerability in rails applications happens if you pass user input directly in open("user_input_url").read function of the rails.

require 'sinatra'
require 'open-uri'

get '/' do
  format 'RESPONSE: %s', open(params[:url]).read

Since this will load any arbitrary URL, So we can exploit this by sending calls to AWS metadata URL and can extract identity credentials keys of the ec2 instance.

So the simple curl request to exploit this should look like:

curl -X GET --url "localhost:4567/?url=[ROLE NAME]

and you will able to extract keys:

  "Code" : "Success",
  "LastUpdated" : "2021-03-22T07:54:05Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "Aredacted",
  "SecretAccessKey" : "redacted",
  "Token" : "redacted",
  "Expiration" : "2021-03-22T14:06:53Z"

Fix SSRF vulnerabilities:

You can fix SSRF vulnerabilites using the gem ssrf_filter.

require 'ssrf_filter'

get '/' do
	response = SsrfFilter.get(params[:url])
	puts response.body

Here is the recent SSRF write-up, I have identifed where wicked pdf was being used. SSRF to local File Read

Command Injections

Some common command lines that are generally used in rails application are:

eval("ruby code here")
system("os command here")
`ls -al /` # (backticks contain os command)
exec("os command here")
open("\| os command here")

Command injections usually occur in the rails application when user input is passed inside the above-mentioned functions. A typical example of a command injection is given below.

user_supplied_path = params[:cmd]
path = "#{Rails.root}/public/downloads/#{user_supplied_path}"
`ls #{path}`

Since this user input is directly being pass in the back-ticks, so an attacker will be able to execute just by using test; whoami as in user-supplied input.

Command Injections using open3:

require 'open3'
require 'sinatra'

get '/' do
	cmd = 'bash'
	user_input = params[:cmd]

	Open3.popen2e(cmd) do |stdin, stdout_stderr, wait_thread| do
			stdout_stderr.each {|l| puts l }
  	stdin.puts "ls #{user_input}"


The above code snipped is vulnerable to command injection attacks. If you pass the user input cmd=|sleep 5`` the application response will be delayed for 5 seconds which indicates successful command injection attack.

Fix Command Injections:

To fix command injections we need to break our command into separate strings

user_supplied_path = params[:cmd]
path = "#{Rails.root}/public/downloads/#{user_supplied_path}"
system("ls", path)

it’s not recommended to fix command injection vulnerabilities using a blacklist method since they are prone to bypass using different encoding types. but if you do, then make sure you block these special characters from your user input.

bad_chars = [ '/', '\\', '?', '%', '*', ':', '|', '"', '<', '>', '.', ' ', ";", "&&", "||", "`", "&", "$" ] 
You can tweak this array a bit based on your project requirements but make sure you blacklist | ; & && % $   ` characters from your input.

shellescape is another method in the rails library that can be used to fix command injection issues. That’s also mentioned in brakeman issue’s section.

Mass Assignment:

Mass assignment is a vulnerability in rails application that allows the attacker to set model attributes by manipulating the parameter in the model attribute.

Consider a case where a user lets say manager user is able to add funds into his account.

Class User < ActiveRecord::Base
		attr_accessible :first_name :last_name :funds

Now consider user send’s a GET request to the server to change his first name and last name from the user model, request would look like this:

GET /users/edit?user[first_name]=hassan&user[last_name]=khan

Now, from the attacker’s perspective, an attacker can add fund parameters and can add funds in his account without the admin’s approval.

GET /users/edit?user[funds]=100 

Attacker will be able to add 100$ funds into his account.

Fix Mass Assignment:

Use permit to permit to fix mass assignment security issues.

def allowed_parameters
	params.require(:user).permit(:first_name, :last_name:)

This concept is called using strong parameters in rails.

Insecure Direct Object Reference in rails:

@user = User.find_by(id: params[:user_id])

Fix IDOR’s

@user = current_user.find_by(id: params[:user_id])

Logging sensitive parameters :

By Default Ruby on Rails Application everything, including user names, passwords, credit card numbers etc. To filter those special character’s make sure you initialize Rails.application.config.filter_parameters in your filter_parameter_logging.rb file.


# Filter sensitive parameters
Rails.application.config.filter_parameters += [

Sensitive files:

/config/database.yml                 -  May contain production credentials.
/config/initializers/secret_token.rb -  Contains a secret used to hash session cookie.
/db/seeds.rb                         -  May contain seed data including bootstrap admin user.
/db/development.sqlite3              -  May contain real data.
/db/seeds/users.rb                   -  May contain application default users
/config/application.yml              -  May contain env variables
/config/secrets.yml                  -  May contain application secret_key_base 
/config/yetting.yml.                 -  May contain application sensitive keys

If you have identified LFI or any other file read vulnerability you can extract these sensitive files to escalate your bug. Sometimes these sensitive files are not in straight /config/ folders so you have to guess the directory.

Black Box Enumeration of Rails Application:

- Wordlists

You can use multiple wordlists to enumerate an application running on ruby on rails. here’s the list of wordlists:

Tip: While running dirsearch scan on rails application always brute force with extensions .json .html .xml, sometimes the application leaks sensitive information in other file formats.

- Burp Suite Extension

Burp Suite Extensions that can help you in black box testing of Ruby on Rails Applications are:

  • Active Scan ++
  • Back Slash Power Scanner
  • J2EEScan
  • Attack Surface Detector

Static Code Analysis:

1- Brakeman

To identify potential security issues in your code use brakeman. it will help you to identify vulnerabilities including Cross-Site Scripting, SQL injections, Command Injections, Insecure Direct Object Reference, and other OWASP security issues.

2- dawnscanner

dawnscanner - A static analysis security scanner for ruby applications.

Vulnerabilities and Security Advisories

1- Bundle-audit

Bundler-audit is a gem that reads your Gemfile and based on the existing versions identifies existing flaws in gems.

2- ruby-advisory-db

ruby-advisory-db is a database of vulnerable Ruby Gems.

3- GemScanner:

GemScanner - Another tool that I have recently coded to identify older version of gems in your Gemfile.lock. The purpose of this tool is not to identify vulnerability in a gem but to find the current or latest version of gems.