Preventing XXE in Java Applications
Impact, exploitation, and prevention of XML External Entity Vulnerabilities.
Join the DZone community and get the full member experience.
Join For FreeWelcome back to AppSec simplified! In this tutorial, we are going to talk about how you can prevent XXEs in Java applications. If you are not already familiar with XXEs, please read my previous post first: https://blog.shiftleft.io/intro-to-xxe-vulnerabilities-appsec-simplified-80be40102815.
Why XXEs 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.
xxxxxxxxxx
<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.
xxxxxxxxxx
<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 XXEs
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.
xxxxxxxxxx
<example>&file;</example>
XXEs 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.
xxxxxxxxxx
<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”.
xxxxxxxxxx
<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 XXEs in Java
So how do you prevent XXEs from happening? The best way to prevent XXEs 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 XXEs because most Java XML parsers have the requirements for XXEs 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.
xxxxxxxxxx
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 XXEs.
xxxxxxxxxx
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.
xxxxxxxxxx
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 XXEs. 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.
xxxxxxxxxx
xmlInputFactory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
xmlInputFactory.setProperty(“javax.xml.stream.isSupportingExternalEntities”, false);
XMLReader
And to protect XMLReader from XXEs you can disallow DTDs and external DTDs:
xxxxxxxxxx
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 XXEs 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.
Published at DZone with permission of Vickie Li. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments