Note that there are some explanatory texts on larger screens.

plurals
  1. POMalicious object injection with xstream
    text
    copied!<p>Can I safely use XStream to process XML coming from outside of my system ? What's the best practice when dealing with "potentially malicious XML" using xstream ?</p> <p>Let's say, I have a class somewhere in my code like this :</p> <pre><code> package hazard; class Dangerous { public Dangerous() { AtomicBomb.getInstance().nuke(); } } </code></pre> <p>A malicious user, might submit a XML file such as :</p> <pre><code> &lt;hazard.Dangerous/&gt; </code></pre> <p>and make XStream calls the nuke() method.</p> <p>This example is quite theoretical. As was pointed out, I do not expect constructor to do this kind of things. But can I be certain that no constructor in any lib available in the classpath is free from such issues (for example, allocate some ressource like a file descriptor).</p> <p>The point is that sending a XML file allows an attacker to create arbitrary objects. A more realistic approach might be using some class instead of another one.</p> <pre><code>public class Foo&lt;T implements Bar&gt; { private T t; // Getters/setters ... } public interface Bar { public void bar(); } public class Bar1 implements Bar { // ... } public class Bar2 implements Bar { // ... } </code></pre> <p>With the (malicious) XML input :</p> <pre><code>&lt;foo&gt; &lt;!-- I expect bar1 --&gt; &lt;package.Bar2/&gt; &lt;/foo&gt; </code></pre> <p>Now with the Java code :</p> <pre><code>Bar&lt;Foo1&gt; bar = (Bar&lt;Foo1&gt;) xstream.fromXML(xml); // I expect to have a bar1 but I have a bar2. bar.getT().foo(); </code></pre> <p>At first glance, the solution is to provide a custom Mapper (the job being done in the realClass() method).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload