[jira] Resolved: (CXF-3359) introduce a threshold system property for staxutils to avoid parsing message with unreasonable element count

["Freeman Fang (JIRA)" <ji...@apache.org>]

     [ 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