[
https://issues.apache.org/jira/browse/CAMEL-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304828#comment-14304828
]
Stephan Siano edited comment on CAMEL-8312 at 2/4/15 9:37 AM:
--------------------------------------------------------------
One thing I overlooked:
the javadoc of the XPathBuilder.documentType() method says:
...
For example you can set it to InputSource to use SAX streams. By default Camel
uses Document as the type.
...
Using InputSource as documentType is a particularily bad idea as it opens the
route to XXE injection again (and it does not use SAX streams but creates a DOM
with the default configuration of the DOM parser). If the XPath implementation
supports it (Saxon does, the JDK implementation doesn't), SAXSource can be a
more memory efficient choice for the docuementType. We should probably also
change the Javadoc here...
was (Author: siano):
One thing I overlooked:
the javadoc of the XPathBuilder.setDocumentType() method says:
...
For example you can set it to InputSource to use SAX streams. By default Camel
uses Document as the type.
...
Using InputSource as documentType is a particularily bad idea as it opens the
route to XXE injection again (and it does not use SAX streams but creates a DOM
with the default configuration of the DOM parser). If the XPath implementation
supports it (Saxon does, the JDK implementation doesn't), SAXSource can be a
more memory efficient choice for the docuementType. We should probably also
change the Javadoc here...
> XML External Entity (XXE) injection in XPath
> --------------------------------------------
>
> Key: CAMEL-8312
> URL: https://issues.apache.org/jira/browse/CAMEL-8312
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.13.3, 2.14.1
> Reporter: Stephan Siano
> Assignee: Willem Jiang
> Attachments:
> 0001-CAMEL-8312-XXE-vulnerability-in-XPath-evaluator.patch
>
>
> If the documentType of an XPath expression is set to a class for that no type
> converter exists and the data to which the expression is applied is of type
> WrappedFile or String the XPath will seem to work anyway. However this setup
> will make the scenario susceptible to XXE injection attacks (because the
> InputSource created from the String or Generic file will be parsed by a
> default parser within the XPath evaluation and the XXE will succeed.
> Even worse, if the documentType is Document (the default) and the DOM parsing
> fails because the document is invalid and contains an XXE injection this will
> allow DOS attacks on the system.
> The two unit tests contained in the patch show these two use cases (and throw
> a FileNotFoundException on an unchanged XPath builder).
> As a side effect the Exception in the XPathFeatureTest.testXPath changes
> (because initially there are errors during type conversion and during XPath
> evaluation whereas after the patch processing is stopped after the type
> conversion error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
