[
https://issues.apache.org/jira/browse/SLING-5288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998939#comment-14998939
]
Alexander Klimetschek commented on SLING-5288:
----------------------------------------------
For performance reasons I would use a hash set of strings (fully qualified
class names) to do the check against and pass that into the object stream
already, as you don't want to build the set every time. (I think in an osgi
environment you have to use the names and checking for Class equality might not
work as these could change over time.)
I would also have the class validator be an interface that just does
"allows(Class class)", then provide one impl that does the above simple
whitelist check, and pass that to the safe object stream. This way applications
can provide their own whitelist logic.
> Restrict which classes can be deserialized
> ------------------------------------------
>
> Key: SLING-5288
> URL: https://issues.apache.org/jira/browse/SLING-5288
> Project: Sling
> Issue Type: Bug
> Components: General
> Reporter: Bertrand Delacretaz
>
> To avoid a recently reported Java deserialization vulnerability [1], we
> should restrict which classes are accepted when deserializing binaries.
> I have created a prototype SafeObjectInputStream at [2], which refuses to
> operate on classes that are outside a whitelist.
> We probably also need a wrapper for ObjectInputStreams provided by the
> environment, that looks a bit harder to create, for now we can already
> discuss this prototype to see if we want to pursue the idea.
> [1]
> https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/safe-object-input-stream
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
