[
https://issues.apache.org/jira/browse/GROOVY-12331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110541#comment-18110541
]
ASF GitHub Bot commented on GROOVY-12331:
-----------------------------------------
paulk-asert opened a new pull request, #2858:
URL: https://github.com/apache/groovy/pull/2858
Secure processing does not bound element depth. The JAXP limit that does,
jdk.xml.maxElementDepth, defaults to 0 meaning unlimited, and nothing in
groovy-xml set it, so the depth a document could reach was unbounded by default.
The SAX parse itself survives that, because nesting is tracked on the heap
rather than the stack. The damage lands on the first consumer to walk the
result recursively - Node.text(), XmlNodePrinter, GPathResult.toString(),
XmlUtil.serialize - each of which runs a stack frame per level. A 350KB
document 50,000 elements deep parsed cleanly and then killed every one of them
with a StackOverflowError. That is an Error, so it escapes the catch(Exception)
an application would reasonably use to handle a malformed document: the failure
arrives somewhere the caller is not defending, well after the parse it would
have attributed it to.
The limit is now set to 1000 by default, matching groovy.json's nesting
bound, so a document too deep to walk is refused by the parse that reads it.
The JDK enforces the bound itself, which puts the check ahead of every consumer
at once and reports the offending element with its depth and position rather
than unwinding an anonymous stack.
The limit cannot be set on a SAXParserFactory - it is a parser property - so
FactorySupport.createSaxParser applies it to the parser it creates, and the
four places that built a SAX parser now go through it. The
DocumentBuilderFactory route takes it as a factory attribute, which covers
DOMBuilder and the DOM paths too.
Nothing is applied when jdk.xml.maxElementDepth is already set: that is the
standard knob for this limit, and an explicitly set parser property would
otherwise override the value a user chose - including a deliberate 0 to restore
unlimited depth. A parser supplied by the caller is left alone, as with the
other hardening here.
> Improve XmlNodePrinter handling for large documents
> ---------------------------------------------------
>
> Key: GROOVY-12331
> URL: https://issues.apache.org/jira/browse/GROOVY-12331
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
