[
https://issues.apache.org/jira/browse/CXF-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-3359.
-------------------------------
Resolution: Fixed
commit fix
http://svn.apache.org/viewvc?rev=1073631&view=rev for trunk
http://svn.apache.org/viewvc?rev=1073632&view=rev for 2.3.x branch
> introduce a threshold system property for staxutils to avoid parsing message
> with unreasonable element count
> ------------------------------------------------------------------------------------------------------------
>
> Key: CXF-3359
> URL: https://issues.apache.org/jira/browse/CXF-3359
> Project: CXF
> Issue Type: Improvement
> Reporter: Freeman Fang
> Assignee: Freeman Fang
>
> if the incoming message like
> <soap:envelope><soap:body><a1/><a2/>...<an/></soap:body></soap:envelope>
> "n" here could be very huge, then it will take long time(a 500k size message
> with only element tag but no real content will take minutes) for staxutils to
> parse this message. In case of dispatch/provider mode, this kind of message
> with unreasonable element count should be considered as potential
> vulnerability, so we need introduce element count threshold property for
> staxutils, so that we get chance that if it reach the threshold, just throw
> exception and stop parsing, this way ensure release resource soon in case of
> vulnerability.
> The default value of this property should be -1 which means no element count
> limitation, for backward compatible.
> This issue is related to CXF-3223, which adding a threshold for the element
> level, but this one is for the element count
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
