This vulnerability allows the usage of external entities in XML.
-External Entity Processing allows for XML parsing with the involvement of external entities. However, when this functionality is enabled without -proper precautions, it can lead to a vulnerability known as XML External Entity (XXE) attack.
-One significant danger of XXE vulnerabilities is the potential for sensitive data exposure. By crafting malicious XML payloads, attackers can -reference external entities that contain sensitive information, such as system files, database credentials, or configuration files. When these -entities are processed during XML parsing, the attacker can extract the contents and gain unauthorized access to sensitive data. This poses a severe -threat to the confidentiality of critical information.
-Another consequence of XXE vulnerabilities is the potential for denial-of-service attacks. By exploiting the ability to include external entities, -attackers can construct XML payloads that cause resource exhaustion. This can overwhelm the system’s memory, CPU, or other critical resources, leading -to system unresponsiveness or crashes. A successful DoS attack can disrupt the availability of services and negatively impact the user experience.
-XXE vulnerabilities can also enable Server-Side Request Forgery (SSRF) attacks. By leveraging the ability to include external entities, an attacker -can make the vulnerable application send arbitrary requests to other internal or external systems. This can result in unintended actions, such as -retrieving data from internal resources, scanning internal networks, or attacking other systems. SSRF attacks can lead to severe consequences, -including unauthorized data access, system compromise, or even further exploitation within the network infrastructure.
-The following code contains examples of XML parsers that have external entity processing enabled. As a result, the parsers are vulnerable to XXE -attacks if an attacker can control the XML file that is processed.
--DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); // Noncompliant --
Protection from XXE can be done in several different ways. Choose one depending on how the affected parser object is used in your code.
-1. The first way is to completely disable DOCTYPE declarations:
-// Applicable to:
-// - DocumentBuilderFactory
-// - SAXParserFactory
-// - SchemaFactory
-factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
-
-// For XMLInputFactory:
-factory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
-
-2. Disable external entity declarations completely:
-
-// Applicable to:
-// - DocumentBuilderFactory
-// - SAXParserFactory
-factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
-factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
-
-// For XMLInputFactory:
-factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, Boolean.FALSE);
-
-3. Prohibit the use of all protocols by external entities:
--// `setAttribute` variant, applicable to: -// - DocumentBuilderFactory -// - TransformerFactory -factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); -factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); - -// `setProperty` variant, applicable to: -// - XMLInputFactory -// - SchemaFactory -factory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); -factory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); - -// For SAXParserFactory, the prohibition is done on child objects: -SAXParser parser = factory.newSAXParser(); -parser.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); -parser.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); --
The most effective approach to prevent XXE vulnerabilities is to disable external entity processing entirely, unless it is explicitly required for -specific use cases. By default, XML parsers should be configured to reject the processing of external entities. This can be achieved by setting the -appropriate properties or options in your XML parser library or framework.
-If external entity processing is necessary for certain scenarios, adopt a whitelisting approach to restrict the entities that can be resolved
-during XML parsing. Create a list of trusted external entities and disallow all others. This approach ensures that only known and safe entities are
-processed.
You should rely on features provided by your XML parser to restrict the external entities.
Specifically for DocumentBuilderFactory, it is possible to disable the entity expansion. Note, however, that this does not prevent the
-retrieval of external entities.
-factory.setExpandEntityReferences(false); --
The following code contains examples of XML parsers that have external entity processing enabled. As a result, the parsers are vulnerable to XXE -attacks if an attacker can control the XML file that is processed.
-
-import org.dom4j.io.SAXReader;
-
-public void decode() {
- SAXReader xmlReader = new SAXReader(); // Noncompliant
-}
-
-
-import org.dom4j.io.SAXReader;
-
-public void decode() {
- SAXReader xmlReader = new SAXReader();
- xmlReader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
-}
-
-The most effective approach to prevent XXE vulnerabilities is to disable external entity processing entirely, unless it is explicitly required for -specific use cases. By default, XML parsers should be configured to reject the processing of external entities. This can be achieved by setting the -appropriate properties or options in your XML parser library or framework.
-If external entity processing is necessary for certain scenarios, adopt a whitelisting approach to restrict the entities that can be resolved
-during XML parsing. Create a list of trusted external entities and disallow all others. This approach ensures that only known and safe entities are
-processed.
You should rely on features provided by your XML parser to restrict the external entities.
The following code contains examples of XML parsers that have external entity processing enabled. As a result, the parsers are vulnerable to XXE -attacks if an attacker can control the XML file that is processed.
-
-import org.jdom2.input.SAXBuilder;
-
-public void decode() {
- SAXBuilder builder = new SAXBuilder(); // Noncompliant
-}
-
-
-import org.jdom2.input.SAXBuilder;
-
-public void decode() {
- SAXBuilder builder = new SAXBuilder();
- builder.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
- builder.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
-}
-
-The most effective approach to prevent XXE vulnerabilities is to disable external entity processing entirely, unless it is explicitly required for -specific use cases. By default, XML parsers should be configured to reject the processing of external entities. This can be achieved by setting the -appropriate properties or options in your XML parser library or framework.
-If external entity processing is necessary for certain scenarios, adopt a whitelisting approach to restrict the entities that can be resolved
-during XML parsing. Create a list of trusted external entities and disallow all others. This approach ensures that only known and safe entities are
-processed.
You should rely on features provided by your XML parser to restrict the external entities.
If the denominator to an integer division or remainder operation is zero, a ArithmeticException is thrown.
This error will crash your program in most cases. To fix it, you need to ensure that the denominator value in all division operations is always -non-zero, or check the value against zero before performing the division.
-A division (/) or remainder operation (%) by zero indicates a bug or logical error. This is because in Java, a division
-or remainder operation where the denominator is zero and not a floating point value always results in an ArithmeticException being
-thrown.
When working with double or float values, no exception will be thrown, but the operation will result in special floating
-point values representing either positive infinity, negative infinity, or NaN. Unless these special values are explicitly handled by a
-program, zero denominators should be avoided in floating point operations, too. Otherwise, the application might produce unexpected results.
Issues of this type interrupt the normal execution of a program, causing it to crash or putting it into an inconsistent state. Therefore, this -issue might impact the availability and reliability of your application, or even result in data loss.
-If the computation of the denominator is tied to user input data, this issue can potentially even be exploited by attackers to disrupt your -application.
-
-void test_divide() {
- int z = 0;
- if (unknown()) {
- // ..
- z = 3;
- } else {
- // ..
- }
- z = 1 / z; // Noncompliant, possible division by zero
-}
-
-
-void test_divide() {
- int z = 0;
- if (unknown()) {
- // ..
- z = 3;
- } else {
- // ..
- z = 1;
- }
- z = 1 / z;
-}
-
-XML standard allows the inclusion of XML files with the xinclude element. When an XML parser component is set up with the
-http://apache.org/xml/features/xinclude feature, it will follow the standard and allow the inclusion of remote files.
When the XML parser will encounter an xinclude element, it will try to load the file pointed to by the href attribute
-into the document. Included files can either be local files found on the file system of the application server, or remote files that are downloaded
-over HTTP, SMB, or other protocols, depending on the capabilities of the application and server.
The files that can be accessed that way are only limited by the entitlement of the application on the local system and the network filtering the -server is subject to.
-This issue is particularly severe when the XML parser is used to parse untrusted documents. For example, when user-submitted XML messages are -parsed that way.
-Allowing the inclusion of arbitrary files in XML documents can have two main consequences depending on what type of file is included: local or -remote.
-If the application allows the inclusion of arbitrary files through the use of the xinclude element, it might be used to disclose
-arbitrary files from the local file system. Depending on the application’s permissions on the file system, configuration files, runtime secrets, or
-Personally Identifiable Information could be leaked.
This is particularly true if the affected parser is used to process untrusted XML documents.
-When used to retrieve remote files, the application will send network requests to remote hosts. Moreover, it will do so from its current network -location, which can have severe consequences if the application server is located on a sensitive network, such as the company corporate network or a -DMZ hosting other applications.
-Attackers exploiting this issue could try to access internal backend services or corporate file shares. It could allow them to access more -sensitive files, bypass authentication mechanisms from frontend applications, or exploit further vulnerabilities in the local services. Note that, in -some cases, the requests sent from the application can be automatically authenticated on federated locations. This is often the case in Windows -environments when using Active Directory federated authentication.
-The following code is vulnerable because it explicitly enables the xinclude feature.
-import javax.xml.parsers.SAXParserFactory;
-
-SAXParserFactory factory = SAXParserFactory.newInstance();
-
-factory.setXIncludeAware(true); // Noncompliant
-factory.setFeature("http://apache.org/xml/features/xinclude", true); // Noncompliant
-
-
-import javax.xml.parsers.SAXParserFactory;
-
-SAXParserFactory factory = SAXParserFactory.newInstance();
-
-factory.setXIncludeAware(false);
-factory.setFeature("http://apache.org/xml/features/xinclude", false);
-
-The following code is vulnerable because it explicitly enables the xinclude feature.
-import org.dom4j.io.SAXReader;
-
-SAXReader xmlReader = new SAXReader();
-xmlReader.setFeature("http://apache.org/xml/features/xinclude", true); // Noncompliant
-
-
-import org.dom4j.io.SAXReader;
-
-SAXReader xmlReader = new SAXReader();
-xmlReader.setFeature("http://apache.org/xml/features/xinclude", false);
-
-The following code is vulnerable because it explicitly enables the xinclude feature.
-import org.jdom2.input.SAXBuilder;
-
-SAXBuilder builder = new SAXBuilder();
-builder.setFeature("http://apache.org/xml/features/xinclude", true); // Noncompliant
-
-
-import org.jdom2.input.SAXBuilder;
-
-SAXBuilder builder = new SAXBuilder();
-builder.setFeature("http://apache.org/xml/features/xinclude", false);
-
-The compliant code example explicitly prevents the inclusion of files in XML documents by setting the
-http://apache.org/xml/features/xinclude feature property to false.
XML parsers Denial of Service attacks target XML parsers, which are software components responsible for parsing and interpreting XML documents.
-XML files are complex data structures. When a malicious user is able to submit an XML file, it triggers complex processing that may overwhelm the -parser. Most of the time, those complex processing are enabled by default, and XML parsers do not take preventive measures against Denial of Service -attacks.
-When an attacker successfully exploits the vulnerability, it can lead to a Denial of Service (DoS) condition.
-Affected system becomes unresponsive or crashes, rendering it unavailable to legitimate users. This can have severe consequences, especially for -critical systems that rely on continuous availability, such as web servers, APIs, or network services.
-In some cases, XML parsers Denial of Service attacks can be used as a part of larger-scale amplification attacks. By leveraging the vulnerability, -attackers can generate a disproportionately large response from the targeted system, amplifying the impact of their attack. This can result in -overwhelming network bandwidth and causing widespread disruption.
--import javax.xml.parsers.DocumentBuilderFactory; - -DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant --
-import javax.xml.parsers.DocumentBuilderFactory; - -DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); --
-import org.dom4j.io.SAXReader; - -SAXReader xmlReader = new SAXReader(); -xmlReader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant --
-import org.dom4j.io.SAXReader; - -SAXReader xmlReader = new SAXReader(); -xmlReader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); --
-import org.jdom2.input.SAXBuilder; - -SAXBuilder builder = new SAXBuilder(); -builder.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant --
-import org.jdom2.input.SAXBuilder; - -SAXBuilder builder = new SAXBuilder(); -builder.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); --
XML signatures are a method used to ensure the integrity and authenticity of XML documents. However, if XML signatures are not validated securely, -it can lead to potential vulnerabilities.
-Before Java 17, XML Digital Signature API does not apply restrictions on XML signature validation unless the application runs with a security -manager, which is rare.
-By not enforcing secure validation, the XML Digital Signature API is more susceptible to attacks such as signature spoofing and injections.
-By disabling secure validation, the application becomes more susceptible to signature spoofing attacks. Attackers can potentially manipulate the -XML signature in a way that bypasses the validation process, allowing them to forge or tamper with the signature. This can lead to the acceptance of -invalid or maliciously modified signatures, compromising the integrity and authenticity of the XML documents.
-Disabling secure validation can expose the application to injection attacks. Attackers can inject malicious code or entities into the XML document, -taking advantage of the weakened validation process. In some cases, it can also expose the application to denial-of-service attacks. Attackers can -exploit vulnerabilities in the validation process to cause excessive resource consumption or system crashes, leading to service unavailability or -disruption.
-For versions of Java before 17, secure validation is disabled by default unless the application runs with a security manager, which is rare. It
-should be enabled explicitly by setting the org.jcp.xml.dsig.secureValidation attribute to true with the
-javax.xml.crypto.dsig.dom.DOMValidateContext.setProperty method.
For Java 17 and higher, secure validation is enabled by default.
-
-NodeList signatureElement = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature");
-
-XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
-DOMValidateContext valContext = new DOMValidateContext(new KeyValueKeySelector(), signatureElement.item(0)); // Noncompliant
-XMLSignature signature = fac.unmarshalXMLSignature(valContext);
-
-boolean signatureValidity = signature.validate(valContext);
-
-
-NodeList signatureElement = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature");
-
-XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
-DOMValidateContext valContext = new DOMValidateContext(new KeyValueKeySelector(), signatureElement.item(0));
-valContext.setProperty("org.jcp.xml.dsig.secureValidation", Boolean.TRUE);
-XMLSignature signature = fac.unmarshalXMLSignature(valContext);
-
-boolean signatureValidity = signature.validate(valContext);
-
-When XML Signature secure validation mode is enabled, XML Signatures are processed more securely. It enforces a number of restrictionsto to protect -from XML Documents that may contain hostile constructs that can cause denial-of-service or other types of security issues.
-These restrictions can protect you from XML Signatures that may contain potentially hostile constructs that can cause denial-of-service or other -types of security issues.
-