When dealing with user input, or when deserializing class names from user input, for example

model = params[:type].camelize.constantize
item = model.find(params[:id])

A user could provide an arbitrary model name in params[:type] and thus find an object in a different model than expected. Now, there might be other code that will fail if the item doesn’t respond to a certain attribute name. But in some cases, Rails will show something that this user is not allowed to see. If the code continued like this, it could also update the item:

item.update_attribute(:state, params[:state])

What can I do against it?

When dealing with user-provided class names (and constantize), it’s best to use a whitelist of possible inputs rather than trusting the user. I know, your intention wasn’t to trust the user input, but just take out a bit of repetition. Let’s add a whitelist check and we’ve got the Ruby class injection problem covered:

if ['user', 'account'].include?(params[:type])


   model = params[:type].camelize.constantize


   item = model.find(params[:id])


end

The post Ruby method and class injection appeared first on Ruby on Rails Security Project.

What Is Excel Injection?

Excel injection occurs when a CSV or Excel file is crafted to contain control characters in a cell which run a command when the file is opened. When a cell starts with =, +, or – in a string field, Excel can be made to launch executable files or visit a webpage. As an example, putting the string =cmd|' /C calc'!A0 will launch the calculator app on Windows when the sheet is opened and the user confirms to trust the source of the file.

What are the risks?

Through injection, Excel can be made to open arbitrary programs or visit malicious URLs. A warning does pop up telling the user about the risks, but it may be ignored because it asks whether you trust the source of the file.

How can I prevent it?

To prevent injection attacks, you need to sanitize the inputs. Make sure any Excel special characters at the start of a cell are escaped using a single ' quotation mark (so e.g. = becomes '=).

The post Excel Injection via Rails downloads appeared first on Ruby on Rails Security Project.

SQL ‘LIKE’ injection is a form of denial-of-service attack where an end-user adds wildcards to a SQL query that uses the ‘LIKE’ keyword.This greatly increases the time it takes to run the query. If your Rails application allows user searching using email:

users = User.includes(:profile).where("profiles.email LIKE ?", "#{term}%“).all

A user can include percent signs in their search and vastly increase the query duration, slowing down the database.

What are the risks?

Because the attack causes database queries to skip the index and run slower, the main risk is a denial-of-service attack. Many searches could bog down the database.

Countermeasures in Rails

Sanitizing user input is the best way to prevent injection. For Rails version 4.2 or greater, ActiveRecord has a new helper function, sanitize_sql_like, which escapes out the percent signs (and the _ character).

The post Rails SQL Injection with LIKE appeared first on Ruby on Rails Security Project.

CSS Injection happens when a malicious party is able to alter your webpage by making use of user-defined styles. If your Rails application allows users to define a color which is then served back through CSS using a view:

<div style="background: <%= user.background_color %>;">

Then a user could supply a value which alters the page layout or content.

What are the risks?

A major risk of CSS injection is abuse of the content directive to rewrite a page’s content. Additionally, if a user is able to edit the style of forms seen by others, they could trick those users into putting personal data in the public.

How can I prevent CSS Injection?

The easiest way to prevent injection attacks is to validate user-provided values. Instead of giving end users the ability to set their own values, you can also give users a pre-defined list which you’ve already validated.

The post CSS Injection in Rails appeared first on Ruby on Rails Security Project.

A Content Security Policy comes in the form of an HTTP header and declares rules for what sources are allowed for all sorts of assets. In consequence, everything else is disallowed. If implemented well, it will completely wipe out all Cross-Site-Scripting (XSS) vulnerabilities in your app. Why? Because CSP effectively disallows inline JavaScript and CSS.

Content-Security-Policy: script-src 'self';

SecureHeaders::Configuration.default do |config|
  config.csp = {
    report_only: Rails.env.production?, # for the Content-Security-Policy-Report-Only header
    preserve_schemes: true, # default: false.

    default_src: %w(*), # all allowed in the beginning
    script_src: %w('self‘), # scripts only allowed in external files from the same origin
    connect_src: %w('self‘), # Ajax may connect only to the same origin
    style_src: %w('self' 'unsafe-inline‘), # styles only allowed in external files from the same origin and in style attributes (for now)
    report_uri: ["/csp_report?report_only=#{Rails.env.production?}“] # violation reports will be sent here
  }
end

...
    default_src: %w('self' https:), # the fallback is everything from the same origin and every HTTPS URL
    script_src: %w('self' https:), # see above
    font_src: %w('self' https: data:), # see above + data: resources
    img_src: %w('self' https: data:), # see above
    object_src: %w('none'), # no embedding
    style_src: %w('self' https: 'unsafe-inline'), # basically only styles from HTTP URLs or data: sources are disallowed
...

<button class='my-javascript-button'>

$('.my-javascript-button').on('click', function() {
  alert('hello');
});

The post A Content Security Policy (CSP) strategy appeared first on Ruby on Rails Security Project.

What Rails does against it

Isn’t it enough to make everything non-GET in my app?

How does the token look like?

Remote forms and the token

Configuration

JavaScript and CSRF

Different formats

CSRF in the API?

What happens if the token is missing or wrong?

•  protect_from_forgery with: :null_session Set all values to nil in all cookies, including the session. That means the user won’t be logged in anymore for that action and can’t perform the change (if the action requires a signed in user). However, after the action the session values will be back and the session ID will be the same, so the user will be logged in. That’s the difference to the following one.
• protect_from_forgery with: :reset_session Create a new session with a new session ID and no values in. That means the user won’t be logged in anymore. If you’re using cookie store for the session, then the old session still exists in the former cookie value (if the user copied it), but will be overwritten in the browser by the new cookie (with the new, empty session in) when the request comes back. Note that Devise by default won’t reset the „remember me“ cookie. That means if you use that feature and that cookie is present, Devise will sign me in with the new session and perform the change! Test that in your application and possibly overwrite the handle_unverified_request method.
• protect_from_forgery with: :exception Raises an ActionController::InvalidAuthenticityToken exception which you can rescue and then return a header-only response or something more user-friendly:

Caching

Can’t an external website just GET the token and then POST something?

The post Cross-Site Request Forgery and Rails appeared first on Ruby on Rails Security Project.

Store configuration in the environment

• You’ll be able to access the environment variables through ENV["KEY"], or <%= ENV["KEY"] %> in Rails’ YAML config files (config/database.yml and others (see below)). If you want to make sure that all keys are actually set before running the application, use ENV.fetch("KEY") instead. It will throw an error so that you’ll find out quickly if the key doesn’t exist.
• Rails 4.1. added the config/secrets.yml file which makes the variables stored in there accessible through Rails.application.secrets, for example <%= Rails.application.secrets[:database][:host] %>. In config/secrets.yml you can still use the environment variables (and for production you should).
• Rails 4.2. added config_for. In the configuration you should still use the environment variables <%= ENV.fetch("KEY") %>.

How to manage environment variables

• Don’t keep the environment variables in the .bashrc or .bash-profile files because that means they’re available to every process that you run as that user. Think about the worst case scenario, a bug in one of those processes would maybe expose those variables. Below you’ll find some other options, preferably choose one that makes the variables only available to the Rails process.
• Load environment variables from .env files. But don’t commit those files. Their purpose is to configure a development system, but could be used on the server, too. This means you’ll have to set a reminder to change the production environment when deploying a new version. This will only make the env variables available to the Rails process, not as global variables.
• Rbenv-vars and .ruby-env files in RVM  work similarly without adding another gem dependency.
• There are deployment tools like Ansible, Puppet or Chef to configure a server environment. However, don’t set global environment variables with this.
• Heroku or other PaaS services provide command line tools to set the environment variables on the server. Figaro can help simplify that process.
• However, you’ll still need a process of how new or changed development config variables get to the right place. Some teams use central wikis to keep the newest (development, safe-to-share) environment variables.

So use environment variables to manage all in one place, get it to the developers and production using one of the above solutions and maybe use Rails’ config_for or secrets.yml (with environment variables in it) if you prefer that syntax.

Keep environment variables secure

• As this piece points out, a process run by your Ruby/Rails app will inherit the environment variables of the parent process. So you should empty out the environment variables before executing a command that you haven’t written.
• For example with: system(Hash[ENV.map {|key,value| [key, nil]}], "echo $RAILS_ENV") RAILS_ENV will be empty for the echo process.
• Secure the environment variable files by giving them only the permissions that they really need: chmod 600 .env.

The post Secure configuration of Rails applications appeared first on Ruby on Rails Security Project.

• %x[...]
• system()
• exec()
• `...`

Keep environment variables secure when running commands

A process run by your Rails app will inherit the environment variables of the parent process that might include API keys and the like. See the Secure configuration section for more on that second line of defense.

Another type: ImageMagick Command Injection

When using ImageMagick to manipulate images, Rails makes a shell call and passes command line arguments to an executable. If those arguments come from a user-supplied source, they could be crafted to cause ImageMagick to use excessive CPU or time.

What are the Possible Risks?

The likeliest scenario is a denial of service attack, where the user causes ImageMagick to consume enough CPU or memory resources to bog down the server. It’s also possible to delete or overwrite files by passing in additional options to ImageMagick.

What can I do against ImageMagick Command Injection in Rails?

When you’re dealing with a list of known parameters, as here, it’s easiest to validate user input against a regex or set of known secure responses. The Dragonfly library, for example, does a good job of checking user arguments (e.g. resize requests) to make sure they’re safe:

RESIZE_GEOMETRY = /\A\d*x\d*[><%^!]?\z|\A\d+@\z/ # e.g. '300x200!'

The post Command injection in Rails appeared first on Ruby on Rails Security Project.

• Rails 3 introduced the ActiveSupport::SafeBuffer module to add an HTML-safe flag to strings. It’s false by default, especially when the string comes from an external source like params or the database. You can return the flag with “string”.html_safe?.
• The HTML-escape method h(), well, escapes the string and marks a string HTML-safe.

  h("html>").html_safe? #=> true 
  ("html>").html_safe? #=> false

• The Erb notation <%= “string” %> inspects the HTML-safe flag of the string. If it’s false it will escape the string automatically, otherwise it won’t.
• There’s a method called #html_safe, that marks a string HTML-safe. It’s a common misconception that this method makes the string safe, it doesn’t. If you know that the string is safe, you can call this method, but it will only set the HTML-safe flag. So you should never do <%= params[:user_input].html_safe %>. Use the h() method to make it really HTML-safe by escaping it.
• The raw() method is similar to the html_safe method. So you should never do: <%= raw params[:user_input] %>
• This is how the string concatenation methods (+, concat(), <<) work:
  • If the left side is HTML-unsafe or the right side is HTML-safe, then it works like normal string concatenation and keeps the HTML-safe flag of the left side
  • Otherwise it will HTML-escape the right side and add it to the string

The post HTML-safe, ActiveSupport::SafeBuffer explained appeared first on Ruby on Rails Security Project.

If you’re using Haml templates, instead of ERB, strings are automatically escaped in the same way as in ERB templates. Also like in ERB templates, HTML-safe strings (string.html_safe? returns true) won’t be escaped automatically. The != notation in Haml works like <%= raw(…) %> in ERB, so it will render the unescaped version.

By default,

= "<em>emphasized</em>"
!= "<em>emphasized</em>"

compiles to:

<em>emphasized</em>
<em>emphasized</em>

So take care when using != in Haml, make sure no user data will be rendered unescaped.

The post XSS protection in Haml templates appeared first on Ruby on Rails Security Project.