The biggest cause of vulnerabilities in Java serialization is that the class is part of the serialization format, so an attacker can cause the serialization to produce classes that you aren't expecting.

Json.NET seems to allow the same behavior, but has it disabled by default.

> In fact the only kind that is not vulnerable is the default: TypeNameHandling.None

I'm rusty on C#, but I believe the equivalent would probably be [Serializable] types being read from a Stream using a BinaryFormatter or SoapFormatter. A malicious stream could include any known types in the system marked as [Serializable], and as they are deserialized any associated static constructor/no argument constructor/property setters could be called.

In the JSON case linked, I presume there is a root type given when you are attempting to deserialize a document. However, if one of the properties of that type is ambiguous (say System.Object), and the deserialization algorithm looks for a 'type' property in the JSON with a class name to determine what is instantiated, then there can be all sorts of unintentional types that might be built by the processing of that malicious JSON.

They moved away from that. Many newer parts of the .NET framework (e.g. SOAP 1.2 implementation in WCF) use data contract serializers by default. With them, a complete list of known types must be provided to deserializer, it's typically done with [KnownType] attribute.

Yes it’s just as vulnerable (example [1]), but I think .net serialization is exposed less often to untrusted inputs than Java with its myriad of enterprise software.

[1] https://googleprojectzero.blogspot.co.uk/2017/04/exploiting-...

Full disclosure, I’m the author of that blog post.

There is a dangerous form https://docs.microsoft.com/en-us/dotnet/standard/serializati...

> Binary serialization can be dangerous. Never deserialize data from an untrusted source and never round-trip serialized data to systems not under your control.

The killed it in .NET Core 1.x; but brought it back in .NET Core 2.x due to back compat and interop complaints

> The killed it in .NET Core 1.x; but brought it back in .NET Core 2.x due to back compat and interop complaints

I've been using .NET binary serialization for dirt cheap local snapshots for the purpose of undo/redo. It's perfect for this.

There are plenty of other options though, such as JSON, MessagePack, Protocol Buffers etc. And BinaryFormatter has always performed poorly against 3rd party libs, especially other binary formatters such MessagePack

Do any of these options support proper handling of cycles in the object graph out of the box?

Yes.

Using the Newtonsoft library you can configure it using `JsonSerializerSettings.ReferenceLoopHandling`, and with with protobuf-net you set `AsReference` on your class's `ProtoContractAttribute`. I don't think MessagePack-CSharp or msgpack-cli support cyclic references tho.

This is the entire point of NSSecureCoding as well. You must provide the list of allowed types and any unexpected ones trigger errors.