Initial contents for BinaryFormatter security guide

[GrabYourPitchforks]

Summary

This represents the initial contents for the BinaryFormatter security guide, which will be linked to from https://aka.ms/binaryformatter and is part of the long-term BinaryFormatter obsoletion strategy.

This is intended to be a living document and will eventually grow to include very detailed guidance for specific scenarios, including code samples. By "living document" I mean that we'll probably update it on a monthly cadence until we're satisfied that the guidance covers the necessary use cases. (See #19442 (comment) for a partial list of topics.)

If this repo isn't the proper place for such a document please let me know and I can figure out where else to put it. But given all of the other serialization-related content in this repo, it seemed like a natural fit.

I'm pushing the contents here now so that we can iterate on the formatting or wording if needed. There is already signoff on the high-level concepts covered by the document.

Todo before checkin

• Update the table at the top, including with keywords and a real asset id
• Add links from BinaryFormatter API page and related docs to this
• Include code samples for using XmlSerializer and JsonSerializer
• Fix wording in other docs to clarify that BinaryFormatter cannot be made safe, even with a custom binder (see Initial contents for BinaryFormatter security guide #19442 (comment) for initial list)

/cc @Rick-Anderson @gewarren

[GrabYourPitchforks]

Topics we'll want to cover, with samples:

• Serializing Exception graphs
• Polymorphic deserialization with System.Text.Json
• Reasoning about cycles, data complexity, algorithmic attacks
• Deserializing dictionaries safely
• Dangerous Type.GetType calls

[GrabYourPitchforks]

Docs we need to update because they give improper security guidance:

• https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.binary.binaryformatter - to link to this document
• https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.binary.binaryformatter.binder - to clarify that a SerializationBinder is not a long-term security solution
• https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.serializationbinder - to remove the "SerializationBinder can be used for security" line (w.r.t. BinaryFormatter / NetDataContractSerializer)
• https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/controlling-serialization-and-deserialization-with-serializationbinder - to clarify that this shouldn’t be used for security
• https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/5dxse167(v=vs.100) – clarifying that a TypeFilterLevel shouldn’t be used for security
• https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.typefilterlevel - clarifying that a TypeFilterLevel shouldn’t be used for security
• https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer
• https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.losformatter
• https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.objectstateformatter
• https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.soap.soapformatter - to clarify that these are all dangerous serializers and should link to this doc
• https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2300
• https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2301
• https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2302 - to clarify that SerializationBinder is not recommended as a long-term mitigation strategy
• https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2310
• https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2311
• https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2312 - same as above, but for NetDataContractSerializer
• https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/security-considerations-for-data – remove text "It is possible to make it secure by writing a secure, type-limiting type binder"

[Youssef1313]

There are some roslyn's analyzers related to this, for example CA2300 (and others too). You may like to reference them.

[HurricanKai]

In my opinion System.Buffers.Binary.BinaryPrimitives should be considered as an alternative next to XML & JSON for those that require binary data.
Especially considering the example of a data file, JSON/XML may not be a viable alternative, as JSON/XML documents can grow very large, and JSON/XML would simply bloat the file too much, also inflating potential load times.
BinaryPrimitives can only encode primitive types, which makes it a more complicated solution, but in some cases, this may be worth it.

[GrabYourPitchforks]

@HurricanKai good suggestion! I'd probably recommend BinaryReader and BinaryWriter instead of BinaryPrimitives since they're more friendly to streaming scenarios, but it still matches the overall spirit of your suggestion.

[Rick-Anderson]

Moved to #19445