I came across this exception while updating xstream (1.4.8) lib to the latest version in one of our web applications. The exception was being thrown in a pojo from a dependent jar that was compiled using an older version of xstream (1.3.1). I recompiled and built the new jar (dependent jar) using the xstream-1.4.8 and deployed the war file again, but still get the same exception. Initially I thought this was due to version mismatch, I'm not sure now whats causing this exception and there's not much documentation online. Any thoughts?
Thanks, Karthik
The actual call that throwing the exception:
TestList list = (TestList)xs.fromXML(new StringReader(testData));
where testData is xml string
TestList.java class
@XStreamAlias("Assets")
public class TestList extends ParentObject {
@XStreamImplicit(itemFieldName = "item")
protected List<Item> item= new ArrayList<Item>();
public void add(Item item) {
item.add(item);
}
public List<Item> getItems() {
if(item== null)
return new ArrayList<Item>();
else
return item;
}
@Override
public String getStringData() {
StringBuilder builder = new StringBuilder();
for (Item item : items) {
builder.append(item.getStringData());
builder.append("---------------\n");
}
return builder.toString();
}
@Override
public String getDataType() {
// TODO Auto-generated method stub
return null;
}
Item.java class:
@XStreamAlias("Item")
public class Item extends ParentItem {
@XStreamAsAttribute
public String access_test;
@XStreamAsAttribute
public int test_num;
@XStreamAsAttribute
public int test_type;
@XStreamAsAttribute
public boolean tst_item;
@XStreamAsAttribute
public int test_test_est;
@XStreamAlias("eset_test")
public List<Integer> eset_test;
And of course I have the getters and setters that I am not including here.
Exception:
com.thoughtworks.xstream.security.ForbiddenClassException: com.test.cp.test123.pojo.TestList
at com.thoughtworks.xstream.security.NoTypePermission.allows(NoTypePermission.java:26)
at com.thoughtworks.xstream.mapper.SecurityMapper.realClass(SecurityMapper.java:74)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:47)
at com.thoughtworks.xstream.core.util.HierarchicalStreams.readClassType(HierarchicalStreams.java:29)
at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:133)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1206)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1190)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:1061)
Using it as a security framework
You need to configure the security framework in XStream.
It is designed to prevent attacks to your deserialization entry point. If you can state that no unfriendly third party will ever use it, you are safe with the solutions provided so far.
I tend to be in the cautious side of the line. So I just allowed the basics, those that are mine, and some I use.
The basics
As stated in other answers, start by using the default
Those that are mine
These I allowed by package:
Some I use
For specific classes that I use, they can be allowed to feed your parser on a "by class" fashion.
To get rid of the exception in the question, the OP may choose to add something like:
Conclusion
XStream allows you to tune the security of the deserialization of your classes as tight as you want it to be. It probably is enough with the bare minimum. But it is not enough to not ask yourself the question: "how tight need I this security to be?" Once you've reflected about the matter, act accordingly.