Insecure Processing of Data
This category covers the following issues:
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
html_safe
Option A: Avoid the use of 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.
- Go through the issues that GuardRails identified in the PR, such as:
<%= @model.name.html_safe %>
- Remove usages of
html_safe
or ensure that there is no user input. - Test it
- Ship it 🚢 and relax 🌴
raw
Option B: Avoid the use of 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.
- Go through the issues that GuardRails identified in the PR, such as:
raw @user.name
- Remove usages of
raw
or ensure that there is no user input. - Test it
- Ship it 🚢 and relax 🌴
More information:
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
- Go through the issues that GuardRails identified in the PR.
- Install
safe_yaml
by adding this line to yourGemfile
:
gem "safe_yaml"
- This would work by default prevent most of the attack vectors against YAML without requiring changing the existing
YAML.load
methods. - There is more configuration available for this gem.
- Test it
- Ship it 🚢 and relax 🌴
Option B: Use secure Marshal/JSON alternatives
- Go through the issues that GuardRails identified in the PR.
- Identify the the code that has either this pattern:
JSON.load("{}")
JSON.restore("{}")
or this one:
Marshal.load("{}")
Marshal.restore("{}")
- And replace it with:
# For JSON
JSON.parse("{}")
# For Marshal
Marshal.dump("{}")
- Test it, ship it 🚢 and relax 🌴