Dinis Cruz, Abraham Kang and Alvaro Muñoz recently [presented an interesting vulnerability]((http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html?m=1) which a developer could easily introduce into their application if using the Restlet framework and XMLDecoder. The vulnerability could allow an attacker to execute arbitrary OS commands on the server, through the REST interface.

Now there are many ways to construct Java objects from XML, such as JAXB, Apache XMLbeans, Castor or Spring to name a few.

But XMLDecoder offers a key feature that sets it apart from the other marshalling libraries:

It will execute method calls defined in the XML, on the newly created objects

And it’s this feature that introduces the security vulnerability if the XML data comes from an untrusted source.

As Dinis explains, XMLDecoder/Encoder was created for the purposes of offering Long Term Persistence of Java objects. I.e. If you wanted to store your Java object on disk or in a database, then you could transform it into XML using XMLEncoder, and then reconstruct it into an object using XMLDecoder. This is all good and well as long as the origin of the XML data is trusted.

Reading and writing XML to the same filesystem where the Java application itself is loaded from should be fine from a security perspective; but creating objects based on XML submitted from the Internet, not so much.

HAMMERS FOR NAILS, SCREWDRIVERS FOR SCREWS

Using XMLDecoder securely is a matter of first deciding if you should use it at all. This in turn depends on how trusted the origin of the XML data is. If the data is user submitted, then it’s clearly untrusted. If it’s loaded from the filesystem then the question is how could an attacker write data to that location? Could they abuse a file upload feature in the application? How about XML injection through a different XML submission system?

Alvaro Muñoz has found similar RCE issues in the Spring O/X + XStream combination, with an example application and exploit available here. So that’s two XML serialisation libraries that could be used to create vulnerable applications.

If you’re confident that attackers (including legitimate users of the application as well as internal users) can’t write XML data to the trusted location, then it should be safe to use XMLDecoder, and Spring X/O + XStream.

But if the XML data comes from an untrusted location, e.g. user submitted data, or data submitted by a third party, or if you’re unsure of the trust level of the data, then use a stricter data binding library like JAXB or Castor with a mapping description. The mapping method used should restrict which classes can be instantiated over XML, so that you can define simple Java beans to act as the mapped-to classes.