Akka.Serialization: add type include / exclude for polymorphic serializers

[Aaronontheweb]

One of the issues with polymorphic serialization is that since it relies on reflection to directly instantiate CLR types, bad actors can submit malicious input that gets instantiated inside an ActorSystem and runs what would otherwise by unauthorized code. This is a classic problem with the BinaryFormatter serializer that's existed in .NET Framework for years, but it's generally a type of hazard for really any reflection-based serializer.

Akka.NET isn't particularly susceptible to this issue as Akka.Remote and Akka.Persistence are almost always used inside closed environments that aren't exposed to public networks. Our documentation, for years, has given guidance that Akka.Remote generally shouldn't be exposed to public networks and in the event that it is, you should be using certificate based authentication on both sides of the connection via TLS.

That being said, it's a good idea for us to mitigate this issue the same way both the original Scala Akka implementation does for their default "Jackson" JSON serializer and other popular .NET projects, such as MsgPack for C#, have done it - to filters to prevent or allow only a narrow band of types from being deserialized.

Here's what MsgPack's implementation looks like: https://github.com/neuecc/MessagePack-CSharp/blob/4142e346ead283997c46f7257f36a3037177bccf/src/MessagePack/Formatters/TypelessFormatter.cs#L97

And here's a range of types that should generally be filtered out from deserialization based on some research HP conducted on .NET reflection-based serialization https://stackoverflow.com/a/49041203/377476

Approach

The approach I think is best:

1. Add a check inside the NewtonSoftJsonSerializer to see if an incoming message of a particular type is allowed or disallowed, depending on configuration;
2. If it's disallowed, throw an SerializationException with a specific error message containing the type name / disallow reason - this should be logged by Akka.Remote or Akka.Persistence;
3. Have NewtonSoftJsonSerializer ship with a default set of excluded types - i.e. from those lists above, automatically check for those upon deserialization;
4. Allow the user to specify their own include / exclude rules via the NewtonSoftJsonSerializerSetup and the HyperionSerializerSetup classes at startup, since those are readily available and make it easy to configure these types of bindings programmatically.
5. Optional: Allow users to totally disable type filtering via configuration in order to improve performance, since this feature does impose a per-message deserialization cost. IMHO this is kind of a silly option - if you care about performance, you should migrate to schema-based serialization using custom Google Protocol Buffer, MsgPack, etc types and avoid the overhead of reflection in the first place. But, if someone has a bunch of legacy data sitting inside Akka.Persistence and they're not worried about this issue affecting them it might be worthwhile to give users the ability to turn this off.

Any suggestions?

To Dos

1. Add Hyperion Support
2. Integrate Hyperion Support into Akka.Serialization.Hyperion + document it
3. Integrate methodology into Newtonsoft.Json Serializer in Akka.Actor

[Aaronontheweb]

For the Hyperion implementation of this, probably best to add the filtering inside Hyperion itself rather than inside the HyperionSerializer in Akka.NET - that way it becomes a feature of that library we merely configure from inside Akka.NET, rather than an Akka.NET-specific feature.

[Aaronontheweb]

Also, our network security documentation needs a facelift - don't think we've touched that since Akka.NET v1.2.0.

[Danthar]

For the Hyperion implementation of this, probably best to add the filtering inside Hyperion itself rather than inside the HyperionSerializer in Akka.NET - that way it becomes a feature of that library we merely configure from inside Akka.NET, rather than an Akka.NET-specific feature.

Yup. That would be the better way to implement this.

No suggestions otherwise. LGTM

[Aaronontheweb]

First step for Hyperion is complete - actually implementing this feature inside the Serializer: akkadotnet/Hyperion#242

Still need to do a new Hyperion release, expose this through Akka.Serialization.Hyperion, and then document how to enable it.

Then we'll need to repeat this process for the Newtonsoft.Json serializer.

[Aaronontheweb]

Stage 2 is underway: #5208 - this will be released in Akka.NET v1.4.24