Securing Rails Applications

RedCloth.new("<script>alert(1)</script>").to_html
# => "<script>alert(1)</script>"

Use the :filter_html option to remove HTML which was not created by the Textile processor.

RedCloth.new("<script>alert(1)</script>", [:filter_html]).to_html
# => "alert(1)"

However, this does not filter all HTML, a few tags will be left (by design), for example <a>:

RedCloth.new("<a href='javascript:alert(1)'>hello</a>", [:filter_html]).to_html
# => "<p><a href="javascript:alert(1)">hello</a></p>"

Countermeasures

It is recommended to use RedCloth in combination with a permitted input filter, as described in the countermeasures against XSS section.

Ajax Injection

NOTE: The same security precautions have to be taken for Ajax actions as for "normal" ones. There is at least one exception, however: The output has to be escaped in the controller already, if the action doesn't render a view.

If you use the in_place_editor plugin, or actions that return a string, rather than rendering a view, you have to escape the return value in the action. Otherwise, if the return value contains a XSS string, the malicious code will be executed upon return to the browser. Escape any input value using the h() method.

Command Line Injection

NOTE: Use user-supplied command line parameters with caution.

If your application has to execute commands in the underlying operating system, there are several methods in Ruby: system(command), exec(command), spawn(command) and command. You will have to be especially careful with these functions if the user may enter the whole command, or a part of it. This is because in most shells, you can execute another command at the end of the first one, concatenating them with a semicolon (;) or a vertical bar (|).

user_input = "hello; rm *"
system("/bin/echo #{user_input}")
# prints "hello", and deletes files in the current directory

A countermeasure is to use the system(command, parameters) method which passes command line parameters safely.

system("/bin/echo", "hello; rm *")
# prints "hello; rm *" and does not delete files

{Kernel#open's} Vulnerability

{Kernel#open} executes OS command if the argument starts with a vertical bar (|).

open("| ls") { |file| file.read }
# returns file list as a String via `ls` command

Countermeasures are to use {File.open}, {IO.open} or {URI#open} instead. They don't execute an OS command.

File.open("| ls") { |file| file.read }
# doesn't execute `ls` command, just opens `| ls` file if it exists

IO.open(0) { |file| file.read }
# opens stdin. doesn't accept a String as the argument

require "open-uri"
URI("https://example.com").open { |file| file.read }
# opens the URI. `URI()` doesn't accept `| ls`

Header Injection

WARNING: HTTP headers are dynamically generated and under certain circumstances user input may be injected. This can lead to false redirection, XSS, or HTTP response splitting.

HTTP request headers have a Referer, User-Agent (client software), and Cookie field, among others. Response headers for example have a status code, Cookie, and Location (redirection target URL) field. All of them are user-supplied and may be manipulated with more or less effort. Remember to escape these header fields, too. For example when you display the user agent in an administration area.

Besides that, it is important to know what you are doing when building response headers partly based on user input. For example you want to redirect the user back to a specific page. To do that you introduced a "referer" field in a form to redirect to the given address:

redirect_to params[:referer]

What happens is that Rails puts the string into the {Location} header field and sends a 302 (redirect) status to the browser. The first thing a malicious user would do, is this:

http://www.yourapplication.com/controller/action?referer=http://www.malicious.tld

And due to a bug in (Ruby and) Rails up to version 2.1.2 (excluding it), a hacker may inject arbitrary header fields; for example like this:

http://www.yourapplication.com/controller/action?referer=http://www.malicious.tld%0d%0aX-Header:+Hi!
http://www.yourapplication.com/controller/action?referer=path/at/your/app%0d%0aLocation:+http://www.malicious.tld

Note that %0d%0a is URL-encoded for \r\n which is a carriage-return and line-feed (CRLF) in Ruby. So the resulting HTTP header for the second example will be the following because the second Location header field overwrites the first.

HTTP/1.1 302 Moved Temporarily
(...)
Location: http://www.malicious.tld

So attack vectors for Header Injection are based on the injection of CRLF characters in a header field. And what could an attacker do with a false redirection? They could redirect to a phishing site that looks the same as yours, but ask to login again (and sends the login credentials to the attacker). Or they could install malicious software through browser security holes on that site. Rails 2.1.2 escapes these characters for the Location field in the {redirect_to} method. Make sure you do it yourself when you build other header fields with user input.

DNS Rebinding and Host Header Attacks

DNS rebinding is a method of manipulating resolution of domain names that is commonly used as a form of computer attack. DNS rebinding circumvents the same-origin policy by abusing the Domain Name System (DNS) instead. It rebinds a domain to a different IP address and then compromises the system by executing random code against your Rails app from the changed IP address.

It is recommended to use the {ActionDispatch::HostAuthorization} middleware to guard against DNS rebinding and other Host header attacks. It is enabled by default in the development environment, you have to activate it in production and other environments by setting the list of allowed hosts. You can also configure exceptions and set your own response app.

Rails.application.config.hosts << "product.com"

Rails.application.config.host_authorization = {
  # Exclude requests for the /healthcheck/ path from host checking
  exclude: ->(request) { request.path.include?("healthcheck") },
  # Add custom Rack application for the response
  response_app: -> env do
    [400, { "Content-Type" => "text/plain" }, ["Bad Request"]]
  end
}

You can read more about it in the ActionDispatch::HostAuthorization middleware documentation

Response Splitting

If Header Injection was possible, Response Splitting might be, too. In HTTP, the header block is followed by two CRLFs and the actual data (usually HTML). The idea of Response Splitting is to inject two CRLFs into a header field, followed by another response with malicious HTML. The response will be:

HTTP/1.1 302 Found [First standard 302 response]
Date: Tue, 12 Apr 2005 22:09:07 GMT
Location:Content-Type: text/html


HTTP/1.1 200 OK [Second New response created by attacker begins]
Content-Type: text/html


<html><font color=red>hey</font></html> [Arbitrary malicious input is
Keep-Alive: timeout=15, max=100         shown as the redirected page]
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

Under certain circumstances this would present the malicious HTML to the victim. However, this only seems to work with Keep-Alive connections (and many browsers are using one-time connections). But you can't rely on this. In any case this is a serious bug, and you should update your Rails to version 2.0.5 or 2.1.2 to eliminate Header Injection (and thus response splitting) risks.

Unsafe Query Generation

Due to the way Active Record interprets parameters in combination with the way that Rack parses query parameters it was possible to issue unexpected database queries with IS NULL where clauses. As a response to that security issue (CVE-2012-2660, CVE-2012-2694 and CVE-2013-0155) {deep_munge} method was introduced as a solution to keep Rails secure by default.

Example of vulnerable code that could be used by attacker, if {deep_munge} wasn't performed is:

unless params[:token].nil?
  user = User.find_by_token(params[:token])
  user.reset_password!
end

When params is one of: [nil], [nil, nil, ...] or ['foo', nil] it will bypass the test for {nil}, but IS NULL or IN ('foo', NULL) where clauses still will be added to the SQL query.

To keep Rails secure by default, {deep_munge} replaces some of the values with {nil}. Below table shows what the parameters look like based on {JSON} sent in request:

It is possible to return to old behavior and disable {deep_munge} configuring your application if you are aware of the risk and know how to handle it:

config.action_dispatch.perform_deep_munge = false

HTTP Security Headers

To improve the security of your application, Rails can be configured to return HTTP security headers. Some headers are configured by default; others need to be explicitly configured.

Default Security Headers

By default Rails is configured to return the following response headers. Your application returns these headers for every HTTP response.

X-Frame-Options

The [X-Frame-Options][] header indicates if a browser can render the page in a ,