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.