class whitelisting for deserialization

[tombentley]

As discussed in this mailing list thread, for applications which deserialize untrusted data there's some security merit in being able to say at compile time what classes you expect to have to deserialize. This could be handled entirely by serialization libraries, but putting it in the serialization API makes it trivial for serialization library authors to implement.

Specifically this could be done by adding a functional parameter to deserialization():

shared DeserializationContext<Id> deserialization<Id>(Boolean whitelisted(ClassModel<> clazz) => true)

If the serialization API was asked to instantiate any class for which whitelisted() returned false an exception would be thrown.

[tombentley]

Discuss.

[tombentley]

I've implemented this on the s11n branch, which will be merged for 1.2.2, so reassigning.

[simonthum]

Hi Tom,

great you took it up! I find it well done and it has instructive tests. From a security perspecive it would maybe need some helpers e.g. to whitelist "org.myorg." and "ceylon." easily enough to get used in practice, but that can be done any time.

I would, however, suggest adding a serialization (i.e. not de-serialization) counterpart. This would make it easy to support older API versions, e.g. my server needs to support on old client that I know cannot handle certain types. By blacklisting types or evaluating their apiLevel tags during serialization I could help ensure my backwards compatibility guarantees in simple unit tests.

[quintesse]

Btw, this was reassigned to 1.2.3

[simonthum]

Regarding my last comment, the serialization counterpart could be informed by #6075 output, or the tool could even produce white/blacklisting code from API diffs for those who don't like maintaining compatibility level annotations.

[quintesse]

@tombentley is this still for 1.2.3?