Skip to main content

Insecure Processing of Data

This category covers the following issues:

Fixing Insecure Deserialization​

About Deserialization

What is a Deserialization vulnerability?​

Serialization converts complex data structures into a stream of bytes that can be sent or received over a network. Deserialization restores the byte stream to a copy of the previously serialized object. The receiving application can then interact with this deserialized object.

Deserializing attacker-controlled data allows attackers to manipulate serialized objects and pass malicious data to the receiving application.

Alternative terms for Serialization/Deserialization are:

  • Marshaling, Unmarshaling
  • Pickling, Unpickling

Check out this video for a high-level explanation:

What is the impact of Deserialization vulnerabilities?​

Attackers can reuse existing application code in malicious ways which results in a wide range of vulnerabilities such as:

  • Code execution: An attacker can exploit deserialization vulnerabilities to execute arbitrary code on a target system, giving them control over the system and access to sensitive data.
  • Unauthorized access: An attacker can use deserialization vulnerabilities to access and manipulate data or functionality that they are not authorized to access, such as administrative functions or sensitive data.
  • Denial-of-service (DoS) attacks: An attacker can exploit deserialization vulnerabilities to cause DoS attacks, by overloading the system with large amounts of data or by manipulating the data in a way that causes the system to crash or become unresponsive.

How to prevent Deserialization vulnerabilities?​

To prevent deserialization vulnerabilities, it is important to follow security best practices and implement appropriate security measures, such as:

  • Avoid deserialization of untrusted data: Do not deserialize data from untrusted sources or unvalidated user input.
  • Use type checking and input validation: Verify the type and content of serialized data to ensure that it is valid and expected.
  • Use secure deserialization libraries and frameworks: Use secure deserialization libraries and frameworks that can help prevent deserialization vulnerabilities and provide additional security features, such as input validation and type checking.
  • Apply access controls: Apply access controls to limit the privileges and actions that deserialized data can perform, such as preventing it from executing arbitrary code or accessing sensitive resources.
  • Keep software up to date: Keep software and security protocols up to date, as new vulnerabilities and security patches are regularly released.

References​

Taxonomies​

Explanation & Prevention​

Training​

Category-specific references:

Option A: Use SafeYAML​

  1. Go through the issues that GuardRails identified in the PR/MR

  2. Install safe_yaml by adding this line to your Gemfile:

    gem "safe_yaml"

  3. This would work by default to 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/MR

  2. Identify 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 🌴

Fixing Cross-Site Scripting​

About XSS

What is Cross-Site Scripting?​

Cross-site scripting (XSS) is a type of security vulnerability that allows attackers to inject malicious code into web pages viewed by other users. This occurs when an application fails to properly sanitize user input and injects untrusted data into a web page without validating or encoding it.

XSS attacks can occur in different forms, such as reflected, stored, or DOM-based, and can affect various types of web applications, including social media, e-commerce, and online banking sites.

Attackers can use various techniques, such as phishing emails, web forms, or malicious links, to trick users into visiting or interacting with web pages that contain malicious code.

Check out this video for a high-level explanation:

What is the impact of Cross-Site Scripting?​

Cross-site scripting (XSS) can lead to various security threats and risks, such as:

  • Information theft: XSS attacks can steal sensitive information, such as login credentials, credit card details, or other personally identifiable information, by injecting malicious code that collects and transmits user data to attackers.
  • Account hijacking: XSS attacks can hijack user sessions by injecting malicious code that takes over user sessions, allowing attackers to perform unauthorized actions on the website or gain access to user accounts.
  • Data tampering: XSS attacks can modify or delete data on a website by injecting malicious code that alters the content of web pages, leading to data tampering, data corruption, or other types of malicious activities.
  • Malware distribution: XSS attacks can distribute malware by injecting malicious code that downloads and installs malicious software on the user's computer, leading to malware infections or other types of cyber attacks.

Overall, XSS attacks can compromise the confidentiality, integrity, and availability of data, leading to a range of security threats and risks.

How to prevent Cross-Site Scripting?​

To prevent XSS vulnerabilities, you can take the following steps:

  • Input validation and sanitization: Ensure that all user input is validated and sanitized before being used to generate web pages or manipulate other data. Input validation should include validating the data type, length, and format, and filtering out any special characters that could be used to inject malicious code.
  • Output encoding: Encode all output to protect against XSS attacks. Use output encoding techniques such as HTML entity encoding, URL encoding, and JavaScript encoding to encode user input and output to the browser.
  • Use security headers: Implement security headers to protect against XSS attacks, such as Content-Security-Policy (CSP) and X-XSS-Protection. CSP can help prevent XSS attacks by allowing only trusted sources of content to be loaded on a page, while X-XSS-Protection can help prevent the browser from rendering pages that contain malicious scripts.
  • Session management: Implement secure session management mechanisms, such as session cookies, to protect against session hijacking and other attacks.
  • Secure coding practices: Use secure coding practices to prevent XSS vulnerabilities. This includes using libraries and frameworks that are designed to prevent XSS attacks, testing code for vulnerabilities, and using secure coding practices such as input validation and output encoding.
  • Regular security audits: Regularly audit your system for security vulnerabilities, including XSS vulnerabilities. Use automated tools and manual testing to identify potential issues and fix them before they can be exploited.

References​

Taxonomies​

Explanation & Prevention​

Training​

Category-specific references:

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/MR, 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 XSS.

  1. Go through the issues that GuardRails identified in the PR/MR, 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 🌴

Last updated on by Stefan Streichsbier