-
Bug
-
Resolution: Tracked Elsewhere
-
High
-
None
-
5.10.6, 6.0.0-beta3
-
1
-
Severity 2 - Major
-
Hi Team
We have several configurations stored in Bandana. Since the new Beta3 we retrieve everywhere an exception similar to this: java.lang.RuntimeException: XStream error: Class net.getunik.confluence.skin.core.designs.DesignConfiguration has not been whitelisted.
The class net.getunik.confluence.skin.core.designs.DesignConfiguration is our class and the error is thrown during reading and writing the configuration.
Because we can't find what we can change an this error wasn't in the last milestone, I like to ask you, what we need to change that our add-ons will work again.
every tip is welcome 
- is duplicated by
-
-
- Closed
-
- mentioned in
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page")
Page
Failed to load
[CONFSERVER-43826] XStream error: ... has not been whitelisted
Ok Thank you for all that information.
As you know, adding a properties file manually will kill our Marketplace sales 
But it's good to know that we have to move forward to remove such storing implementations. (We already planed to move to AO with the most of our configurations, because they are Maps or to simple Strings in the bandana)
If we don't use Xstream in the future anymore and add manual parsing the old stored class structure for the migration to AO will be a good idea.
Thank you.
oliver.straesser@getunik.com As you might already be aware, XStream < 1.4.9 is vulnerable to XXE attacks, where deserializing objects from XML can lead to arbitrary code execution. XStream should never be used to process arbitrary object graphs, and the workaround you've used above is also vulnerable to the same issue, and will break once we upgrade to a release of XStream with the XXE fix enabled.
The whitelist error you are receiving from bandana above is due to our fix for this issue. I realise that for the typical way we use XStream in Bandana, this is not a direct threat to the security of Confluence. It is just protecting us from attackers finding some way to exploit this vulnerability to escalate their access.
Sadly, there is currently no programmatic way of declaring your classes to be safe for deserialization. However, you can configure the xstream.whitelist.extra system property to include a comma separated list of package prefixes that your plugin requires to be serializable. Administrators installing your add-on will also have to do the same.
In a release soon, we will support storing json configuration globally for your plugin which can safely read and write to specific objects using Jackson or Gson. Watch for json site-level properties (https://jira.atlassian.com/browse/CRA-281) to ship as part of the Confluence Java API and REST API, to match the content-level and space-level properties already available. Once that is available, I recommend you move to that, and away from using Bandana to store your configuration.
Hi
We found a way arround. If we instantiate a local XStream class and cast the stored value after we retrieved it as string from bandana and same on storing, it works.
New:
import org.springframework.beans.factory.InitializingBean; public class DesignManager implements InitializingBean { private XStream xStream; private DesignConfiguration getConfig() { DesignConfiguration config = null; try { Serializableserializable = (Serializable) bandanaManager.getValue(confluenceBandanaContext, BD_KEY); if (serializable instanceof DesignConfiguration) { config = (DesignConfiguration) serializable; } else if (serializable instanceof String) { config = (DesignConfiguration) xStream.fromXML((String) serializable); } } catch (Exception e) { logger.warn("Error converting DesignConfiguration", e); } return config; } private void saveConfig(DesignConfiguration config) { String configXml = xStream.toXML(config); bandanaManager.setValue(confluenceBandanaContext, BD_KEY, configXml); } @Override public void afterPropertiesSet() throws Exception { xStream = new XStream(); xStream.setClassLoader(getClass().getClassLoader()); } }
For example in the past
private void saveConfig(DesignConfiguration config) {
bandanaManager.setValue(confluenceBandanaContext, BD_KEY, config);
}
This throws the error.
I hope that you can just confirm me, that this is a right solution for this exception - as I told I found nothing helpful. Next to this it could be a short KB article to help other developers.
Tracking the fix for this issue over at https://jira.atlassian.com/browse/CONF-43832. Resolving this one as a duplicate.