Preventing XXE in Java Applications
Impact, exploitation, and prevention of XML External Entity Vulnerabilities
Welcome back to AppSec simplified! In this tutorial, we are going to talk about how you can prevent XXE in Java applications. If you are not already familiar with XXE, please read my previous post first!
Why XXE happen
DTDs are used to define the structure of an XML document. Within DTDs, you can declare “XML entities”. There is a special type of XML entities called “external entities”, which are used to access local or remote content with a URL.
For example, this DTD declares an external entity named “file” that points to file:///secrets.txton the local file system. The XML parser will replace any &file reference in the document with the contents of file:///secrets.txt.
<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE example [
<!ENTITY file SYSTEM "file:///secrets.txt" >
]>
<example>&file;</example>If users can declare arbitrary XML entities in their uploads, they can declare an external entity to any location on your machine. For example, this XML file contains an external entity that points to file:////etc/shadow on your server.
<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE example [
<!ENTITY file SYSTEM "file:////etc/shadow" >
]>
<example>&file;</example>The “/etc/shadow” file stores usernames and their encrypted passwords on Unix systems. When the parsed XML document is displayed back to the user, the contents of file:////etc/shadow will also be included.
Impact of XXE
By exploiting the XML parser, a malicious user can now read arbitrary files on your server. They can access and exfiltrate files such as system files, source code, directory listings on the local machine.
Network exploration
Besides retrieving system files, attackers can use XXE vulnerabilities to launch SSRF attacks against the local network. For example, they can launch a port scan by switching out the external entity’s URL with different ports on the server. Using this technique, they can explore the local network to find other vulnerable machines or services to target.
<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE example [
<!ENTITY file SYSTEM "http://10.0.0.1:80" >
]>
<example>&file;</example>XXE can also be used to launch an SSRF to read AWS cloud services instance metadata. By accessing the address 169.254.169.254, attackers might be able to retrieve access tokens, secrets, and session token keys of the hosting cloud provider.
<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE example [
<!ENTITY file SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/" >
]>
<example>&file;</example>Denial of Service
Another potential way that attackers can exploit XML vulnerabilities is to launch Denial of Service attacks, which is when an attacker disrupts the machine so that legitimate users cannot access its services.
Take a look at this XML file for example. This DTD embeds entities within entities, causing the XML parser to recursively dereference to get to the root entity value “lol”.
<?xml version=”1.0" encoding=”UTF-8"?><!DOCTYPE example [<!ELEMENT example ANY ><!ENTITY lol “lol”><!ENTITY lol1 “&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;”><!ENTITY lol2 “&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;”><!ENTITY lol3 “&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;”><!ENTITY lol4 “&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;”><!ENTITY lol5 “&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;”><!ENTITY lol6 “&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;”><!ENTITY lol7 “&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;”><!ENTITY lol8 “&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;”><!ENTITY lol9 “&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;”>]><example>&lol9;</example>
Each “lol9” entity would be expanded into ten “lol8”, and each of those would become ten “lol7”, and so on. Eventually, one “lol9” will be expanded into one billion “lol”s. This will overload the memory of the XML parser, potentially causing it to crash.
This attack method is called a “Billion laughs attack” or an “XML bomb”. Interestingly, although this attack is often classified as an XXE attack, it does not involve the use of any external entities! It uses the recursive processing of internal entities instead.
Preventing XXE in Java
So how do you prevent XXE from happening? The best way to prevent XXE is to limit the capabilities of your XML parsers.
Since DTD processing is a requirement for XXE attacks, developers should disable DTD processing on their XML parsers. If it is impossible to disable DTDs completely, then external entities, parameter entities, and inline DTDs should be disabled. You can also disable the expansion of XML entities entirely. How you can configure the behavior of an XML parser will depend on the XML parser you use.
Java applications are particularly prone to XXE because most Java XML parsers have the requirements for XXE enabled by default. To prevent XXE attacks in a Java application, you need to explicitly disable these functionalities.
DocumentBuilderFactory
For instance, for the DocumentBuilderFactory library, you can disallow DTDs with this line.
dbf.setFeature(“http://apache.org/xml/features/disallow-doctype-decl", true);If completely disabling DTDs is not possible, you can disallow XML external entities and parameter entities. Parameter entities are XML entities that can only be referenced elsewhere within the DTD. They can also allow attackers to launch XXE.
dbf.setFeature(“http://xml.org/sax/features/external-general-entities", false);dbf.setFeature(“http://xml.org/sax/features/external-parameter-entities", false);
You should also disable external DTDs to prevent attackers from hosting an external DTD and referencing it in an XML document.
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);XInclude is a special XML feature that builds a separate XML document from a tag. They also allow attackers to trigger XXE. So set “setXIncludeAware” to false to disallow XInclude processing. Finally, set “setExpandEntityReferences” to prevent parsers from recursively expanding XML entities into XML bombs.
dbf.setXIncludeAware(false);dbf.setExpandEntityReferences(false);
XMLInputFactory
For the XMLInputFactory, these lines disable DTDs and external entities.
xmlInputFactory.setProperty(XMLInputFactory.SUPPORT_DTD, false);xmlInputFactory.setProperty(“javax.xml.stream.isSupportingExternalEntities”, false);
XMLReader
And to protect XMLReader from XXE you can disallow DTDs and external DTDs:
reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
Or disable the use of external and parameter entities.
reader.setFeature("http://xml.org/sax/features/external-general-entities", false);reader.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
The code needed to protect parsers from XXE varies for different Java XML parsers. For more information about how to secure various parsers visit the OWASP cheat sheet here.
Keeping libraries up to date
It's not just your XML parsers that you should look out for. Many third-party libraries deal with XMLs and thus are susceptible to XXE attacks. Verify that your dependencies are secure from XXE attacks, and update libraries to secure versions.
Hope you had fun with this tutorial! I sure had fun writing it. Static analysis is the most efficient way of uncovering most vulnerabilities in your applications. If you’re interested in learning more about ShiftLeft’s static analysis tool NG-SAST, visit us here.
Thanks for reading! What is the most challenging part of developing secure software for you? I’d love to know. Feel free to connect on Twitter @vickieli7.
