When having classpath issue (namely, multiple XML implementation provided), it's possible that the rule might not correctly detect method invocations supposed to sanitize the configuration, depending of the order in which the semantic encountered the XML API implementation classes.
Consequently, FPs might be raised, and, even worse, these FPs are usually exactly what the "Compliant" code is suggesting to do.
For instance, the following code can raise an issue, while perfectly valid, if method setFeature is not properly resolved by the semantic engine:
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl",true); dbf.setFeature("http://xml.org/sax/features/external-general-entities",false); dbf.setFeature("http://xml.org/sax/features/external-parameter-entities",false); dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); dbf.setXIncludeAware(false); bf.setExpandEntityReferences(false);
While fixing classpath issue in order to correctly know WHICH implementation of XML is used should fix the FP (see SONARJAVA-2957, SONARJAVA-3056). Another approach could be the following:
> Do not raise an issue if there is calls to unknown method called "setFeature" following the creation of the factory
- relates to
-
SONARJAVA-3056 Classes for the analysis are loaded with parent first strategy
-
- Open
-
-
SONARJAVA-2957 Lookup for .class resource should use a child first strategy
-
- Closed
-
-
RSPEC-2755 XML parsers should not be vulnerable to XXE attacks
- Active
-
SUPPORT-16595 Loading...
- is related to
-
SUPPORT-15777 Loading...