[
https://issues.apache.org/jira/browse/XERCESJ-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762173#comment-17762173
]
Michael Glavassevich edited comment on XERCESJ-1759 at 9/5/23 5:46 PM:
-----------------------------------------------------------------------
I also view this as a feature request and it probably belongs in
[org.apache.xerces.parsers.SecureProcessingConfiguration|https://xerces.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/parsers/SecureProcessingConfiguration.html]
with all the other similar properties that have been added to the JDK. I wrote
that class, but I'll admit never made much fanfare about its existence because
I've always been skeptical about how effective these properties actually are
and whether they're really necessary. A client that has decided that they're
going to use DOM can easily check element depth by providing an
[LSParserFilter|https://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/ls/LSParserFilter.html]
when the DOM is built, using one of the streaming APIs: SAX or StAX, checking
element depth in their custom handler and then transforming the events into a
DOM or even providing a JAXP Schema.
was (Author: mrgla...@ca.ibm.com):
I also view this as a feature request and it probably belongs in
[org.apache.xerces.parsers.SecureProcessingConfiguration|https://xerces.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/parsers/SecureProcessingConfiguration.html]
with all the other similar properties that have been added to the JDK. I wrote
that class, but I'll admit never made much fanfare about its existence because
I've always been skeptical about how effective these properties actually are
and whether they're really necessary. A client can easily check element depth
by providing an
[LSParserFilter|https://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/ls/LSParserFilter.html]
when the DOM is built, using one of the streaming APIs: SAX or StAX, checking
element depth in their custom handler and then transforming the events into a
DOM or even providing a JAXP Schema.
> Parsing xml cannot limit the maximum element depth, resulting in excessive
> memory usage and DOS.
> ------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1759
> URL: https://issues.apache.org/jira/browse/XERCESJ-1759
> Project: Xerces2-J
> Issue Type: Bug
> Components: JAXP (javax.xml.parsers), JAXP (javax.xml.validation)
> Affects Versions: 2.12.2
> Reporter: shuailingliang
> Priority: Major
> Labels: security
> Attachments: image-2023-09-05-01-37-14-363.png
>
>
> When parsing an xml file similar to the following by calling the
> javax.xml.parsers.DocumentBuilder#parse(java.io.File) method, the elements
> are nested layer by layer and there is no element closing tag. Since the
> depth of elements cannot be verified, the array in
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl#fElementStack will
> continue to increase the number of QName objects, resulting in excessive
> memory and DOS problems.
>
> <?xml version=”1.0” encoding=”UTF-8” standalone=”no” ?>
> <A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A
> a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A
> a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”><A a=”1”>…
>
> After testing, we found that a file of 12.93M will cause an OOM exception in
> a service with a maximum heap memory of 250M.
>
> We checked the jdk information and found that we can limit the nesting depth
> of xml elements by setting the system property jdk.xml.maxElementDepth. We
> hope xerces can solve this problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-dev-h...@xerces.apache.org
