@exceptionfactory Aren't the vulnerabilities associated more with what value one picks for the SECURE_PROCESSING property?

@exceptionfactory Aren't the vulnerabilities associated more with what value one picks for the SECURE_PROCESSING property?

There are different classes of vulnerabilities. Secure Processing covers them in general, but allowing DTD resolution is a more narrow type of potential issue. Although it is possible to scope down the issues, it is still a potential attack vector. Given that fact, introducing a new property without an overriding use cases is less than optimal from a maintenance perspective.

So perhaps instead of introducing the VALIDATE_DTD property, could we assume to always not to resolve DTD's thereby avoiding the FileNotFoundException as reported in the ticket? In other words we should always call the following

factory.setAttribute("http://saxon.sf.net/feature/entityResolverClass", IgnoreDoctypeEntityResolver.class.getCanonicalName());

The Secure Processing property came years after this ticket was created, and blocks DTD resolution, so the issue could be closed, noting that DTD resolution is not supported with Secure Processing enabled.

@exceptionfactory I do not understand, even though I had Secure Processing set to true in the TransformXML processor, the exception reported in the ticket still occurs as I noted on the ticket last week and demonstrated in the unit test I added. Doesn't that indicate DTD resolution still occurs?

Thanks for clarifying @dan-s1, most of the Secure Processing handling focuses on the XSLT Source. Let me take a closer look at the options and follow up.