15

I am implementing XML validation which prevents XXE (External XML Entity) Injection. I borrowed some code from OWASP XXE Prevention Cheat Sheet. My code looks like this - 

        SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
        Schema schema = factory.newSchema(xsdFileURL);
        Validator validator = schema.newValidator();
        validator.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
        validator.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
        validator.validate(new StreamSource(new StringReader(xml)));

The code runs correctly on my local windows machine (JDK 1.8.0_92, Wildfly 8.2). But on a QA Red Hat machine with similar config (JDK - 1.8.0_101, Wildfly 8.2), it throws an exception with the message - 

Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.

After some reading my suspicion is that during runtime, incorrect class definition is being read for the validator class. How do I fix this?

Update

Turns out Jboss comes with its own implementation of JAXP, and my code needs to pick the JAXP implementation from JDK and not from JBoss. I can do this easily by passing -jaxpmodule argument in standalone.sh (using this, my code picked the correct JAXP implementation as well) - 

java -jar jboss-modules.jar -jaxpmodule "javax.xml.jaxp-provider"

But I'd like to do this using jboss-deployment-structure.xml and add an exclusion like this -

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <deployment>
    <exclusions>
        <module name="javax.api" />  // is the module name correct?
    </exclusions>   
  </deployment>
</jboss-deployment-structure>

But this isn't working, how can I fix this?

halfer
  • 19,824
  • 17
  • 99
  • 186
Ankit Rustagi
  • 5,539
  • 12
  • 39
  • 70
  • Shouldn't you exclude the javax.xml.bind.api or com.sun.xml.bind modules? – Jan-Willem Gmelig Meyling Aug 28 '16 at 16:06
  • I am using `JAXP` since all i am doing is parsing an xml. AFAIK `JAXB` is used to bind XML documents to a java object model. – Ankit Rustagi Aug 29 '16 at 05:30
  • Also, via '-jaxpmodule' argument, jboss-modules.jar lets us specify the `JAXP` module implementation. There is no such argument available for any other `JBoss` module. Does this mean that it was intended to specify `JAXP` implementation via only command line? – Ankit Rustagi Aug 29 '16 at 05:34

2 Answers2

1

As you mentioned in your update, JBoss/Wildfly does ship its own JAXP implementation - Xalan (and Xerces). As such, it uses that implementation as it builds the classpath for your deployed application(s). You can override this behavior in your jboss-deployment-structure.xml file as follows:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>            
        <exclusions>            
            <module name="org.apache.xalan" />
            <module name="org.apache.xerces" /> 
        </exclusions>
    </deployment>
</jboss-deployment-structure>
Lin Du
  • 88,126
  • 95
  • 281
  • 483
g_param
  • 156
  • 5
  • While this will filter out the classes, it won't take care of registration of the included implementations via META-INF/services. These will still remain set according to those 2 excluded modules. I wish there would be an easy way how to completely switch to the default JDK implementations and in a compatible way (with other JDKs where the classes may be in different packages etc). Now you can either add your own META-INF/services settings which may break at other JDKs, or use system properties which are quite cumbersome (you need to set a bunch of them) and will affect the whole JVM. – Petr H Feb 18 '21 at 13:32
0

Instead of trying to remove JARs from the Server's runtime.It is always advisable to exclude these JARs from your project at runtime.E.g. If you are using Maven for dependency management,then for this particular JAR in your pom.xml,you can just provide scope for this JAR as "provided".Provided scope indicates that this JAR will be used for compile time and at runtime it will be provided by runtime itself.

Sakalya
  • 568
  • 5
  • 15