Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 52

An XML document can be dynamically constructed from smaller logical blocks called entities. Entities can be either internal, external or parameter based. External entities allow the inclusion of XML data from external files.

According to XML W3C Recommendation [W3C 2008], Section 4.4.3, "Included If Validating"

When an XML processor recognizes a reference to a parsed entity, to validate the document, the processor MUST include its replacement text. If the entity is external, and the processor is not attempting to validate the XML document, the processor MAY, but need not, include the entity's replacement text.

Because the above step is optional, fewer XML processors are vulnerable to an external entity attack. An attacker may attempt to cause denial of service or program crashes by manipulating the URI of the entity to refer to special files existing on the local file system, for example, by specifying /dev/random or /dev/tty as input URIs. This severely affects the behavior of the program by crashing or blocking it indefinitely. This is called an XML External Entity (XXE) attack.

Noncompliant Code Example

This noncompliant code example is vulnerable to a remote XXE attack. It reuses code from the noncompliant code example detailed in IDS08-J. Prevent XML Injection. An attacker may supply malicious input of the form specified in the string xmlString. A SAX or a DOM parser will block waiting indefinitely until some input is obtained from the standard terminal (POSIX based machines). When the attacker can control the path to the external entity (/dev/tty in this case), he can use this technique to execute arbitrary code.

This noncompliant code example also violates guideline EXC06-J. Do not allow exceptions to expose sensitive information because it allows exceptions to propagate potentially sensitive information.

Compliant Solution

This compliant solution uses the AccessController mechanism to enforce a security check that prevents the program from accessing restricted files or resources. For instance, an attempt to access /dev/tty generates a java.security.AccessControlException. The security policy file must grant the program java.io.FilePermission with the target read so that the default schema can be read from a secure directory. The receiveXMLStream() method implements the two-argument form of Accesscontroller.doPrivileged() so that callers can pass a context that strips the read and write permissions from the currently executing context. Refer to guideline SEC00-J. Avoid granting excess privileges for more details. This solution complies with guideline ENV02-J. Create a secure sandbox using a Security Manager.

Because all fields used inside the doPrivileged block must be final, instances of SAXParser, InputStream and DefaultHandler are all declared final.

Compliant Solution

This compliant solution defines a CustomResolver class that implements the interface org.xml.sax.EntityResolver. This enables a SAX application to implement customized handling of external entities. The setEntityResolver() method registers the implementation with the corresponding SAX driver. Customized handling permits implementation of a white-list benefits for external entities. The resolveEntity method returns an empty InputSource when an input fails to resolve to one of the specified, safe entity source paths. Consequently, when parsing the xmlString that contains malicious input, the empty InputSource returned by the custom resolver provokes throwing of a java.net.MalformedURLException, which can be handled appropriately. Note that you must create an XMLReader object on which to set the custom entity resolver.

Risk Assessment

Failure to prevent external entity attacks may lead to denial of service and, in some cases, execution of arbitrary code.




Remediation Cost









Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.


[Steuck 2002]
[W3C 2008] 4.4.3 Included If Validating

IDS09-J. Prevent XPath Injection      13. Input Validation and Data Sanitization (IDS)      IDS11-J. Prevent LDAP injection

  • No labels