All Java APIs of openBIS receive serialized Java objects send via HTTP. The attempt of deserializing any byte stream can be dangerous if there are classes in the class path which allow executing (by reflection) anything which is part of the byte stream. A concrete security vulnerability has been found (see http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability). It is caused by the class
org.apache.commons.collections.functors.InvokerTransformer which is in the 3rd-party library Apache Commons Collections.
White and Black Lists
In order to prevent openBIS from such kind of attacks deserialization is guarded by a white list of allowed classes and a black list of disallowed classes. Any attempt to deserialize an object of a not allowed class will lead to an exception and will be reported in the log file.
The default white and black lists should be fine for most cases. For example all openBIS classes are in the white list and the above mentioned
InvokerTransformer is in the black list. But configuration allows to extend these lists for two reasons:
- Further classes causing similar vulnerability might be found. They can be added immediately to the black list.
- Classes of 3rd party libraries used by core plugins might be needed as API parameters. They can be added to the white list.
Default white list
Default black list
Configuring White and Black Lists
disallowed-api-parameter-classes allows to extend the white list and the black list, respectively. These properties can be defined in
service.properties of AS and DSS and in
plugin.properties of DSS core plugins of types
processing-plugins. They contain a comma-separated list of regular expression for fully-qualified class names.