XStream security framework [BATCH-2708]

[spring-projects-issues]

Nicolas Roussel opened BATCH-2708 and commented

Hi,

When using a XStreamMarshaller with spring batch, I get the following message: 'Security framework of XStream not initialized, XStream is probably vulnerable.'

I've set a 'major' priority because the Security Framework was introduced with XStream 1.4.7, and it will be mandatory with XStream 1.5.0. (According to https://groups.google.com/forum/#!topic/xstream-user/wiKfdJPL8aY)

The problem is that we can't set the security properties inside the @Bean definition of XStreamMarshaller. Indeed, for now, to do that we need to get the XStream object with the getXStream() method. But XStreamMarshaller always instantiates a new xstream object in the afterPropertiesSet method.

By the way, the setSupportedClasses method is only used on marshalling: StaxEventItemReader doesn't care about supported classes. Is it on purpose?

Here's a link where I posted my original problem: https://stackoverflow.com/questions/49450397/vulnerability-warning-with-xstreammarshaller/49627612#49627612

Nicolas

---

Reference URL: https://stackoverflow.com/questions/49450397/vulnerability-warning-with-xstreammarshaller/49627612#49627612

Issue Links:

• BATCH-2638 Allow Secure Configuration of XStream

[spring-projects-issues]

Michael Minella commented

The XStreamMarshaller is not a Spring Batch class and is actually a Spring Framework class (via the OXM module) so these changes would need to occur there.  That being said, if you are looking to use the XStreamMarshaller for your ExecutionContext serialization, that mechanism has been depricated and will be removed in an upcoming release.

[spring-projects-issues]

Mahmoud Ben Hassine commented

Nicolas Roussel From the SO thread you linked to, you said:

I still get the vulnerability message and not supported classes are still unmarshelled correctly

So I guess you are using XStream as an unmarshaller to read xml files. Is that correct? I want to make sure to understand your usage of XStream: For reading, writing or serializing the execution context.

The problem is that we can't set the security properties inside the @Bean definition of XStreamMarshaller. Indeed, for now, to do that we need to get the XStream object with the getXStream() method. But XStreamMarshaller always instantiates a new xstream object in the afterPropertiesSet method.

No, you don't need to get the XStream object with getXStream and you shouldn't, because as said in the Javadoc of the getXStream method, the XStream object returned should not be used for further configuration. You need to extend XStreamMarshaller and override customizeXStream(XStream xstream) (basically your "Another solution" for the first try here). However, in your solution, you use the static method XStream.setupDefaultSecurity(xstream);, I would rather add a persmission on the xstream object pre-configured by spring as mentioned in the example the official docs.

I tested this here and it works as expected with Spring Batch version 4.0.1.RELEASE and xstream version 1.4.10 (same versions as you mentioned in SO) . The warning disappears and setting xstream.allowTypes to a type other than the one I want makes the unmarshalling fail as expected (see comments).

In sum, XStreamMarshaller allows you to customize the xstream object through customizeXStream(XStream xstream) and get rid of the warning. So IMO, the issue you are reporting is not an issue. Do you agree?

By the way, the setSupportedClasses method is only used on marshalling: StaxEventItemReader doesn't care about supported classes. Is it on purpose?

As mentioned by Michael, XStreamMarshaller is from Spring Framework, so this is better asked for the framework team. If they accept to change supportedClasses to be used for unmarshalling too, then our StaxEventItemReader will support this indirectly.

[spring-projects-issues]

Mahmoud Ben Hassine commented

@Nicolas Roussel Any updates on this?

[spring-projects-issues]

Mahmoud Ben Hassine commented

As explained in my previous comment (with the demo), it is possible to customize the xstream object of XStreamMarshaller through customizeXStream(XStream xstream) and get rid of the warning. I'm closing this ticket.