Hi Phil,
I really do want to avoid the case where developers deploy JAX-RS/
Jersey apps that are by default insecure. Often developers are unaware
or not knowledgeable about such vulnerabilities. So by default the
framework should be as secure as possible.
So logging a severe error IMHO is not suitable. The exception forces
the developer or the integrator to focus on resolving security issues
or the developer actively disabling it, thus explicitly taking
responsibility for a potential vulnerability.
The feature ".../secure-processing" is more vague in what it actually
specifies:
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING
and mentions cases around DoS attacks based on limits which is less
severe than that for external entities, which is why in this case i
log a severe error rather than throwing an exception.
If i would change this code i would take the conservative route of
throwing an Exception for the second case as well, rather the logging
a sever error for the first case :-)
Like Tatu i am surprised that the XML parser does not recognize both
properties.
Paul.
On Feb 20, 2010, at 5:31 PM, Phil Griffin wrote:
> After a bit more debugging, this bit of Jersey code seems to be
> causing my pain...more specifically, pain in the SAXParserFactory
> I'm using.
>
> I'm not a SAX feature expert, but this snippet from
> com.sun.jersey.core.impl.provider.xml.SAXParserContextProvider
> doesn't make sense to me?
> Since disableXmlSecurity is false by default, the effect of this
> code is to disable "http://xml.org/sax/features/external-general-entities
> " processing in my factory, resulting in the exception I originally
> reported in this thread (which occurs during Jersey-driven
> processing/parsing of a POST request).
>
> Also, my factory doesn't support feature "http://javax.xml.XMLConstants/feature/secure-processing
> ", but at least that just gets logged.
>
> Paul/Tatu - can you comment on this?
> Thanks,
> Phil
>
> disableXmlSecurity =
> fps.getFeature("com.sun.jersey.config.feature.DisableXmlSecurity");
> protected SAXParserFactory getInstance()
> {
> SAXParserFactory f = SAXParserFactory.newInstance();
> f.setNamespaceAware(true);
> if(!disableXmlSecurity)
> {
> try
> {
> f.setFeature("http://xml.org/sax/features/external-general-entities
> ", Boolean.FALSE.booleanValue());
> }
> catch(Exception ex)
> {
> throw new RuntimeException("Security features for
> the SAX parser could not be enabled", ex);
> }
> try
> {
> f.setFeature("http://javax.xml.XMLConstants/feature/secure-processing
> ", Boolean.TRUE.booleanValue());
> }
> catch(Exception ex)
> {
> LOGGER.log(Level.WARNING, "JAXP feature
> XMLConstants.FEATURE_SECURE_PROCESSING cannot be set on a
> SAXParserFactory. External general entity processing is disbaled but
> other potential securty related features will not be enabled.", ex);
> }
> }
> return f;
> }
>
>
> On 2/17/2010 3:02 PM, Phil Griffin wrote:
>>
>>
>>
>> On 2/17/2010 1:28 AM, Paul Sandoz wrote:
>>>
>>>
>>> On Feb 17, 2010, at 1:06 AM, Phil Griffin wrote:
>>>
>>>> Hi Paul,
>>>> Thanks for the reply. It's a little hard to confirm what version
>>>> the SAX parser is...looks like it could be Xerces 2.8.1?
>>>> Is it likely the change in behavior occurred between Jersey 1.0.2
>>>> and 1.1.4.1?
>>>
>>> Yes, i added support for setting the security settings on the JAXP
>>> parsers in Jersey 1.0.3.1 and 1.1.4.
>>>
>>> Actually i went back and looked at the code and you can disable
>>> this, see:
>>>
>>> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/core/util/FeaturesAndProperties.html
>>> #FEATURE_DISABLE_XML_SECURITY
>> Thanks - yes adding this to web.xml is a workaround (while I'm
>> confirming if the bundled Xerces I'm required to use can be updated?)
>> <param-name>com.sun.jersey.config.feature.DisableXmlSecurity</param-
>> name>
>> <param-value>true</param-value>
>>>
>>>
>>>
>>>> If so, what version of Xerces would be compatible?
>>>>
>>>
>>> Not sure :-( but Tatu provides some more details in his email.
>>>
>>> Paul.
>>>
>>>> -Phil
>>>>
>>>> On 2/16/2010 2:15 PM, Paul Sandoz wrote:
>>>>>
>>>>> Hi Phil,
>>>>>
>>>>> What is the implementation and version of the SAX parser you are
>>>>> using?
>>>>>
>>>>> This warning is important because Jersey cannot configure the
>>>>> parsing to protect against certain XML-based denial of service
>>>>> attacks. So if you are building public-facing services that
>>>>> consume XML your application could be at risk.
>>>>>
>>>>> Currently the only way to disable this is to disable JDK logging.
>>>>>
>>>>> If you really need this disabled can you log a enhancement and
>>>>> we can had a feature to disable security-based configuration?
>>>>>
>>>>> Paul.
>>>>>
>>>>> On Feb 16, 2010, at 6:54 PM, Phil Griffin wrote:
>>>>>
>>>>>> I recently updated our Jersey jars to 1.1.4.1 and began getting
>>>>>> a JAXP parser registry exception for a non-supported feature
>>>>>> (in the factory I'm required to use). Is there a way to disable
>>>>>> the com.sun.jersey.core.provider.jaxb.AbstractJAXBProvider or
>>>>>> Jersey from expecting this feature?
>>>>>>
>>>>>> WebLogicSAXParser cannot be created.SAX feature
>>>>>> @ 'http://xml.org/sax/features/external-general-entities'
>>>>>> not supported
>>>>>>
>>>>>> Thanks,
>>>>>> Phil
>>>>>
>>>