binary formatter clean up

[Rick-Anderson]

Moved from #19442

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

---

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

API:

See https://github.com/dotnet/dotnet-api-docs/pull/4508

• [x] https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.binary.binaryformatter - to link to this document
• [x] 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
• [x] 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)
• [x] https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.typefilterlevel - clarifying that a TypeFilterLevel shouldn’t be used for security
• [x] https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer
• [x] https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.losformatter
• [x] https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.objectstateformatter
• [x] 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

dotnet repo:

• [x] 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
• [x] 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"

previous-versions:

• [ ] 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

  Edit 9/13/23 - This article already contains the following Caution block. What else is needed here?

  Do not assume that controlling deserialization is the only security your application requires. In distributed applications, even a high degree of control over serialization does not prevent unauthorized clients from intercepting the communication and using it in some way, even if that is merely showing the data to others. Therefore, although the Low deserialization level provides some protection against certain types of attack based on automatic deserialization, you must still evaluate whether to use authentication and encryption to help protect your data. For details, see Security.

visualstudio:

• [x] https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2300
• [x] https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2301
• [x] https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2302 - to clarify that SerializationBinder is not recommended as a long-term mitigation strategy
• [x] https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2310
• [x] https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2311
• [x] https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2312 - same as above, but for NetDataContractSerializer

Not on the list, but I added

• https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/serialization-and-deserialization5dxse167.Caution(en-us,VS.100).gifCaution: Do not assume that controlling deserialization is the only security your application requires. In distributed applications, even a high degree of control over serialization does not prevent unauthorized clients from intercepting the communication and using it in some way, even if that is merely showing the data to others. Therefore, although the Low deserialization level provides some protection against certain types of attack based on automatic deserialization, you must still evaluate whether to use authentication and encryption to help protect your data. For details, see Security.

[charlesroddie]

I'm not sure if this is the best place to comment, but there is a rather strange suggestion that users should switch from byte[] serialization to string serialization (as the recommended alternatives) for reasons that have something to do with security. That is nonsense of course. You should really include a form of binary serialization as a suggested alternative. CBOR will do well, especially as there is such a serializer in dotnet/runtime now. Moving from byte[] to string formats should be a decision based on whether there is a need for human readability.