Skip to main content

Insecure Processing of Data

This category covers the following vulnerabilities:

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​

Specific References:

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 operations.

  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 🌴

Option D: Handle untrusted XSLTs safely​

XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents. It is possible to attach malicious behavior to those style sheets. Therefore, if attackers can control the content or the source of the style sheet, they might be able to trigger remote code execution.

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

  2. Look for code like this:

    <x:transform xml="${xmlData}" xslt="${xsltControlledByUser}" />

    or this:

    Source xslt = new StreamSource(new FileInputStream(inputUserFile)); //Dangerous source
    Transformer transformer = TransformerFactory.newInstance().newTransformer(xslt);
    Source text = new StreamSource(new FileInputStream("/data_2_process.xml"));
    transformer.transform(text, new StreamResult(...));

  3. And replace it with this:

    TransformerFactory factory = TransformerFactory.newInstance();
    factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
    Source xslt  = new StreamSource(new FileInputStream(inputUserFile));
    Transformer transformer = factory.newTransformer(xslt);

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing XML External Entities (XXE)​

About XML External Entity (XXE) Injection

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: JAXB Unmashaller​

This rule flags any use of tainted input reaching the JAXB Unmarshaller. There are several options to remediate this vulnerability.

Specific References:

Option B: Update to the latest JDK version release​

The JAXB Unmashaller is insecure by default in old JDK versions. Update to the JDK version 1.8 or later, as since JDK-8010393, which is in OpenJDK 8 beta 86, javax.xml.bind.Unmarshaller instances are safe by default.

Note that the XML Binding (JAXB) API has been removed since Java 11.

Option C: Use a secure XML parser for unmarshalling​

JAXB Unmashaller can parse untrusted XML via a configurable secure XML parser.

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

  2. Look for instances where user input is passed to Unmarshaller

    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
          ...
          String content = req.getParameter("xmlContent");
          // Do unmarshall operation
          JAXBContext context = JAXBContext.newInstance(Object.class);
          Unmarshaller unmarshaller = context.createUnmarshaller();
          unmarshaller.unmarshal(new ByteArrayInputStream(content.getBytes(StandardCharsets.UTF_8)));
          ...
      }

  3. Configure a secure XML parser as below:

    // Disable XXE
    SAXParserFactory spf = SAXParserFactory.newInstance();
    spf.setFeature("http://xml.org/sax/features/external-general-entities", false);
    spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
    spf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
    String content = req.getParameter("xmlContent");
    // Do unmarshall operation
    Source xmlSource = new SAXSource(spf.newSAXParser().getXMLReader(),
                                    new InputSource(new StringReader(content)));
    JAXBContext context = JAXBContext.newInstance(Object.class);
    Unmarshaller unmarshaller = context.createUnmarshaller();
    unmarshaller.unmarshal(xmlSource);

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option D: 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);
      [...]
    }

  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 🌴

Option E: Prevent XXE through XPathExpression​

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:

    DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
    df.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
    DocumentBuilder builder = df.newDocumentBuilder();
    [...]
    xPathExpr.evaluate( builder.parse(inputStream));

  3. And replace it with this:

    DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
    df.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
    DocumentBuilder builder = df.newDocumentBuilder();
    [...]
    xPathExpr.evaluate( builder.parse(inputStream));

    or this:

    DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
    spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
    DocumentBuilder builder = df.newDocumentBuilder();
    [...]
    xPathExpr.evaluate( builder.parse(inputStream));

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option F: Prevent XXE through SAXParser​

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:

    SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
    parser.parse(inputStream, customHandler);

  3. And replace it with this:

    SAXParserFactory spf = SAXParserFactory.newInstance();
    spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
    SAXParser parser = spf.newSAXParser();
    parser.parse(inputStream, customHandler);

    or this:

    SAXParserFactory spf = SAXParserFactory.newInstance();
    spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
    SAXParser parser = spf.newSAXParser();
    parser.parse(inputStream, customHandler);

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option G: Prevent XXE through XMLReader​

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:

    XMLReader reader = XMLReaderFactory.createXMLReader();
    reader.setContentHandler(customHandler);
    reader.parse(new InputSource(inputStream));

  3. And replace it with this:

    XMLReader reader = XMLReaderFactory.createXMLReader();
    reader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
    reader.setContentHandler(customHandler);
    reader.parse(new InputSource(inputStream));

    or this:

    XMLReader reader = XMLReaderFactory.createXMLReader();
    reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
    reader.setContentHandler(customHandler);
    reader.parse(new InputSource(inputStream));

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option H: Prevent XXE through DocumentBuilder​

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:

    DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();
    Document doc = db.parse(input);

  3. And replace it with this:

    DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
    dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
    DocumentBuilder db = dbf.newDocumentBuilder();
    Document doc = db.parse(input);

    or this:

    DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
    dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
    DocumentBuilder db = dbf.newDocumentBuilder();
    Document doc = db.parse(input);

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option I: Prevent XXE through TransformerFactory​

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:

    Transformer transformer = TransformerFactory.newInstance().newTransformer();
    transformer.transform(input, result);

  3. And replace it with this:

    TransformerFactory factory = TransformerFactory.newInstance();
    factory.setAttribute(XMLConstants.ACC`ESS_EXTERNAL_DTD, "all");
    factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "all");
    Transformer transformer = factory.newTransformer();
    transformer.setOutputProperty(OutputKeys.INDENT, "yes");
    transformer.transform(input, result);`

    or this:

    TransformerFactory factory = TransformerFactory.newInstance();
    factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
    Transformer transformer = factory.newTransformer();
    transformer.setOutputProperty(OutputKeys.INDENT, "yes");
    transformer.transform(input, result);

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing XPath Injection​

About XPath Injection

What is XPath Injection?​

XPath injection is a type of security vulnerability that allows attackers to exploit the processing of XPath queries by an application.

This occurs when an application accepts user input and uses it to construct an XPath query without proper validation, allowing attackers to inject malicious code or entities that modify or bypass the intended behavior of the query.

XPath injection can affect various types of applications that use XPath queries, such as web applications, document processing software, or online forms.

Attackers can use various techniques, such as crafted queries or filter values, to inject malicious code or entities into the application.

Check out this video for a high-level explanation:

What is the impact of XPath Injection?​

XPath injection can lead to various security threats and risks, such as:

  • Information disclosure: XPath injection can expose sensitive information, such as user data, login credentials, or other types of confidential information, to unauthorized parties.
  • Unauthorized access: XPath injection can allow attackers to gain unauthorized access to applications, perform unauthorized actions, or modify data.
  • Denial-of-service: XPath injection can cause denial-of-service (DoS) attacks by injecting malicious queries or values that consume system resources, such as CPU or memory, leading to system crashes or slowdowns.

How to prevent XPath Injection?​

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

  • Use input validation: Validate user input to ensure that it is safe and does not contain malicious code or characters that can be used for injection attacks.
  • Use parameterized queries: Use parameterized queries and other secure coding practices to ensure that user input is properly sanitized and not used to construct XPath queries directly.
  • Use secure XPath libraries and frameworks: Use secure XPath libraries and frameworks that support secure XPath queries and provide additional security features, such as input validation and parameterized queries.
  • Limit application access: Limit access to applications to authorized users and restrict access to sensitive information and actions.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Use parameterized queries​

XPath injection risks are similar to SQL injection. If the XPath query contains untrusted user input, the complete data source could be exposed. This could allow an attacker to access unauthorized data or maliciously modify the target XML.

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

  2. Look for code like this:

    XPath xpath = XPathFactory.newInstance().newXPath();
    XPathExpression xlogin = xpath.compile("//users/user[login/text()='" + login.getUserName() + "' and password/text() = '" + login.getPassword() + "']/home_dir/text()");
    Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml"));
    String homedir = xlogin.evaluate(d);

  3. Use parameterized XPath queries such as XQuery.

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing LDAP Injection​

About LDAP Injection

What is LDAP Injection?​

LDAP injection is a type of security vulnerability that allows attackers to exploit an application's interaction with Lightweight Directory Access Protocol (LDAP) servers.

This occurs when an application fails to properly sanitize user input and includes untrusted data in an LDAP query, allowing attackers to inject malicious code or modify the intended behavior of the query.

LDAP injection can affect various types of applications that interact with LDAP servers, such as web applications, directory services, and authentication systems.

Attackers can use various techniques, such as crafted search queries, filter values, or search base paths, to inject malicious code or entities into the application.

Check out this video for a high-level explanation:

What is the impact of LDAP Injection?​

LDAP injection can lead to various security threats and risks, such as:

  • Information disclosure: LDAP injection can expose sensitive information, such as user data, login credentials, or other types of confidential information, to unauthorized parties.
  • Unauthorized access: LDAP injection can allow attackers to gain unauthorized access to LDAP servers, perform unauthorized actions, or modify data.
  • Denial-of-service: LDAP injection can cause denial-of-service (DoS) attacks by injecting malicious queries or values that consume system resources, such as CPU or memory, leading to system crashes or slowdowns.

How to prevent LDAP Injection?​

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

  • Use input validation: Validate user input to ensure that it is safe and does not contain malicious code or characters that can be used for injection attacks.
  • Use parameterized queries: Use parameterized queries and other secure coding practices to ensure that user input is properly sanitized and not used to construct LDAP queries directly.
  • Use secure LDAP libraries and frameworks: Use secure LDAP libraries and frameworks that support secure LDAP queries and provide additional security features, such as input validation and parameterized queries.
  • Limit LDAP server access: Limit access to LDAP servers to authorized users and restrict access to sensitive information and actions.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Use strong input validation​

Just like SQL, all inputs passed to an LDAP query need to be passed in safely. Unfortunately, LDAP doesn't have prepared statement interfaces like SQL. Therefore, the primary defense against LDAP injection is strong input validation of any untrusted data before including it in an LDAP query.

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

  2. Look for code like this:

    NamingEnumeration<SearchResult> answers = context.search("dc=People,dc=example,dc=com", "(uid=" + username + ")", ctrls);

  3. Follow the instructions provided by WASC-29.

  4. Test it

  5. Ship it 🚢 and relax 🌴

Last updated on by Stefan Streichsbier