-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SAXParserFactory doesn't disable XML entity expansion #3446
SAXParserFactory doesn't disable XML entity expansion #3446
Comments
@glassfishrobot Commented |
@glassfishrobot Commented https://docs.oracle.com/javase/tutorial/jaxp/limits/limits.html Setting the following system property would greatly limit the impact of the issue you raise (setting to 0 makes it unlimited, which you wouldn't want):
I agree, though. It would be helpful to disable entity expansion altogether for systems that don't require it. More generally speaking, it'd be nice to offer control over all the configuration options as recommended by OWASP: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#Java |
@glassfishrobot Commented |
@kiranmn Commented The system property jdk.xml.entityExpansionLimit=1 does that work? |
|
There is also the system property |
Hi there, For some reason, this issue has started being reported as a vulnerability by SourceClear - https://www.sourceclear.com/vulnerability-database/security/xml-entity-expansion-xee-/java/sid-3606 - with no CVE, however. Is there a documented workaround, or possibly a patch that sets some better/safer defaults on the parser? Is PR#4472 doing that? If so, is that available in a particular Jersey release yet? edit: it looks like it is included in 2.31 indeed. |
Jersey version 2.31 fixes eclipse-ee4j/jersey#3446, bump it to 2.33
The DocumentBuilderFactory and XmlInputFactory providers aren't vulnerable to Billion Laughs attacks (exponential entity expansion) by disabling entity expansion altogether.
But the SAXParserFactory provider is only disabling external entities, and it's possible to use the following input to generate a very high memory consumption (specially if the application using it allows parallel requests):
There is I actually a limit, but very high (like 100000 I think, and couldn't configure it with the entityExpansionLimit JDK property). If it doesn't work try removing the last level of recursion. Even if the depth is limited, there is no maximum for the expanded size so adding a few kilobytes to the entity text would make the attack successful.
Check disallow-doctype-decl feature in this example:
https://gist.github.com/asudhakar02/45e2e6fd8bcdfb4bc3b2
Affected Versions
[2.24]
The text was updated successfully, but these errors were encountered: