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​

Option A: Don't parse untrusted data with XMLDecoder​

XMLDecoder should not be used to parse untrusted data. Deserializing user input can lead to arbitrary code execution. This is possible because XMLDecoder supports arbitrary method invocation. This capability is intended to call setter methods, but in practice, any method can be called.

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

  2. Look for code that passes untrusted data to XMLDecoder.

    XMLDecoder d = new XMLDecoder(in);
    try {
        Object result = d.readObject();
    }
    [...]

  3. Follow the steps detailed here: Using XMLDecoder to execute server-side Java Code on a Restlet application

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option B: Avoid deserializing untrusted objects with ObjectInputStream​

Object deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows the trigger of malicious operation.

Libraries developers tend to fix class that provided potential malicious trigger. There are still classes that are known to trigger Denial of Service.

Deserialization is a sensible operation that has a great history of vulnerabilities. The web application might become vulnerable as soon as a new vulnerability is found in the Java Virtual Machine.

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

  2. Look for code that passes untrusted data to ObjectInputStream.

    public UserData deserializeObject(InputStream receivedFile) throws IOException, ClassNotFoundException {
      try (ObjectInputStream in = new ObjectInputStream(receivedFile)) {
          return (UserData) in.readObject();
      }
    }

  3. Follow the steps detailed here: Deserialization of untrusted data

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option C: Avoid deserializing untrusted objects with Jackson​

When the Jackson databind library is used incorrectly the deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows the trigger of malicious operation.

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

  2. Look for code like this:

    public class Example {
      static class ABean {
          public int id;
          public Object obj;
      }
      static class AnotherBean {
          @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS) // or JsonTypeInfo.Id.MINIMAL_CLASS
          public Object obj;
      }
      public void example(String json) throws JsonMappingException {
          ObjectMapper mapper = new ObjectMapper();
          mapper.enableDefaultTyping();
          mapper.readValue(json, ABean.class);
      }
      public void exampleTwo(String json) throws JsonMappingException {
          ObjectMapper mapper = new ObjectMapper();
          mapper.readValue(json, AnotherBean.class);
      }
    }

  3. Explicitly define what types and subtypes you want to be available when using polymorphism through JsonTypeInfo.Id.NAME.

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing XML Processing Issues​

About XML External Entities

What is XML External Entities (XXE) injection?​

XML External Entities (XXE) injection is a type of security vulnerability that allows attackers to exploit the processing of XML data by an application.

This occurs when an application accepts XML data from an untrusted source and processes it without proper validation, allowing the inclusion of external entities that can be malicious or contain sensitive information.

As a result, attackers can perform various malicious activities, such as stealing user data, executing arbitrary code, or performing denial-of-service attacks.

Check out this video for a high-level explanation:

What is the impact of XXE injection?​

XML External Entities (XXE) injection can lead to various security threats and risks, such as:

  • Information theft: XXE attacks can steal sensitive information, such as login credentials, credit card details, or other personally identifiable information, by injecting malicious code or entities that collect and transmit user data to attackers.
  • Server-side request forgery: XXE attacks can initiate requests to systems that are accessible from the affected web server.
  • Denial of service: XXE attacks can cause denial-of-service (DoS) attacks by injecting malicious code or entities that consume system resources, such as CPU or memory, leading to system crashes or slowdowns.
  • Arbitrary code execution: XXE attacks can execute arbitrary code on the server by injecting malicious code or entities that exploit vulnerabilities in the application or the underlying operating system.

How to prevent XXE injection?​

To prevent XML External Entities (XXE) injection, it is important to follow security best practices and implement appropriate security measures, such as:

  • Disable external entity processing: Disable the processing of external entities in XML parsers and libraries to prevent XXE vulnerabilities.
  • Use secure parsers and libraries: Use secure parsers and libraries that support secure XML processing.
  • Use input validation: Validate user input to ensure that it is safe and does not contain malicious code or entities.
  • 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​

Option A: Prevent XML External Entity Attacks​

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source.

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

  2. Look for code like this:

    public void parseXML(InputStream input) throws XMLStreamException {
      XMLInputFactory factory = XMLInputFactory.newFactory();
      XMLStreamReader reader = factory.createXMLStreamReader(input);
      [...]
    }

    or:

    $XMLFACTORY.setProperty("javax.xml.stream.isSupportingExternalEntities", true);

  3. And replace it with this:

    public void parseXML(InputStream input) throws XMLStreamException {
      XMLInputFactory factory = XMLInputFactory.newFactory();
      factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
      XMLStreamReader reader = factory.createXMLStreamReader(input);
      [...]
    }

    or this:

    public void parseXML(InputStream input) throws XMLStreamException {
      XMLInputFactory factory = XMLInputFactory.newFactory();
      factory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
      XMLStreamReader reader = factory.createXMLStreamReader(input);
      [...]
    }

  4. Test it

  5. Ship it 🚢 and relax 🌴

Last updated on by Stefan Streichsbier