Insecure Processing of Data

This category covers the following issues:

• Cross-Site Scripting (XSS)
• Insecure Deserialization

Cross-Site Scripting (XSS)

Why is this important?

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise trusted websites. XSS attacks allow attackers to target legitimate users of a web application by sending malicious script code to them.

Check out this video for a high-level explanation:

Fixing Cross-Site Scripting

Option A: Avoid the use of html_safe

html_safe sounds like it is the secure alternative of using html. However, that's not the case. The html_safe call essentially tells Ruby on Rails that the content is safe and does not need to be escaped.

1. Go through the issues that GuardRails identified in the PR, such as:

<%= @model.name.html_safe %>

2. Remove usages of html_safe or ensure that there is no user input.
3. Test it
4. Ship it 🚢 and relax 🌴

Option B: Avoid the use of raw

The raw method outputs the content of a string without escaping it. This is used when Rails should not automatically escape tags. If the data is coming from user input this can lead to a XSS.

1. Go through the issues that GuardRails identified in the PR, such as:

raw @user.name

2. Remove usages of raw or ensure that there is no user input.
3. Test it
4. Ship it 🚢 and relax 🌴

More information:

• OWASP Cheat Sheet - XSS
• Rails Raw
• Ruby on Rails: Security Guide - XSS

Insecure Deserialization

Why is this important?

Serialization is the process of translating data structures storable formats. In Ruby, objects can be serialized into strings and vice-versa, strings can be deserialized into objects. This functionality can be accessed with methods related to YAML, JSON, CSV, and Marshalling. Insecure deserialization describes the processing of malicious data which in term allows hackers to execute arbitrary code in the context of your application. These issues are common and have been the cause of many high profile breaches.

Fixing Insecure Deserialization

Option A: Use SafeYAML

1. Go through the issues that GuardRails identified in the PR.
2. Install safe_yaml by adding this line to your Gemfile:

  gem "safe_yaml"

3. This would work by default prevent most of the attack vectors against YAML without requiring changing the existing YAML.load methods.
4. There is more configuration available for this gem.
5. Test it
6. Ship it 🚢 and relax 🌴

Option B: Use secure Marshal/JSON alternatives

1. Go through the issues that GuardRails identified in the PR.
2. Identify the the code that has either this pattern:

  JSON.load("{}")
  JSON.restore("{}")

or this one:

  Marshal.load("{}")
  Marshal.restore("{}")

3. And replace it with:

  # For JSON
  JSON.parse("{}")

  # For Marshal
  Marshal.dump("{}")

4. Test it, ship it 🚢 and relax 🌴

More information

• Example Patch of Insecure Deserialization for RubyGems
• OWASP Cheat Sheet - Deserialization
• Brakeman - Unsafe Deserialization
• Gem - SafeYAML
• Ruby - Marshal Load
• Ruby - JSON Load