BinaryFormatter risks (#4508)

* BinaryFormatter risks

* BinaryFormatter risks

* BinaryFormatter risks

* Apply suggestions from code review

Co-authored-by: Genevieve Warren <[email protected]>

* work

* Update xml/System.Runtime.Serialization/SerializationBinder.xml

Co-authored-by: Genevieve Warren <[email protected]>

* work

* Apply suggestions from code review

Co-authored-by: Genevieve Warren <[email protected]>

Co-authored-by: Genevieve Warren <[email protected]>

Author: Rick-Anderson

includes/binaryformatter.md

@@ -0,0 +1,2 @@
+> [!WARNING]
+> `BinaryFormatter` is insecure and can't be made secure. For more information, see the [BinaryFormatter security guide](/dotnet/standard/serialization/binaryformatter-security-guide).

xml/System.Runtime.Serialization.Formatters.Binary/BinaryFormatter.xml

@@ -53,7 +53,10 @@
     <remarks>
       <format type="text/markdown"><![CDATA[  
   
-## Remarks  
+## Remarks
+
+[!INCLUDE[binaryformatter](~/includes/binaryformatter.md)]
+
  The <xref:System.Runtime.Serialization.Formatters.Soap.SoapFormatter> and <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter> classes implement the <xref:System.Runtime.Remoting.Messaging.IRemotingFormatter> interface to support remote procedure calls (RPCs), and the <xref:System.Runtime.Serialization.IFormatter> interface (inherited by the <xref:System.Runtime.Remoting.Messaging.IRemotingFormatter>) to support serialization of a graph of objects. The <xref:System.Runtime.Serialization.Formatters.Soap.SoapFormatter> class also supports RPCs with <xref:System.Runtime.Serialization.Formatters.ISoapMessage> objects, without using the <xref:System.Runtime.Remoting.Messaging.IRemotingFormatter> functionality.  
   
  During RPCs, the <xref:System.Runtime.Remoting.Messaging.IRemotingFormatter> interface allows the specification of two separate object graphs: the graph of objects to serialize, and an additional graph that contains an array of header objects that convey information about the remote function call (for example, transaction ID or a method signature).  
@@ -65,7 +68,7 @@
  The serialization procedure for a method response is identical to that of a method call, except the first object of the object graph must support the <xref:System.Runtime.Remoting.Messaging.IMethodReturnMessage> interface. To deserialize a method response, use the <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse%2A> method. To save time, details about the caller object are not sent to the remote object during the method call. These details are instead obtained from the original method call, which is passed to the <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse%2A> method in the <xref:System.Runtime.Remoting.Messaging.IMethodCallMessage> parameter. The first object in the graph returned by the <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse%2A> method supports the <xref:System.Runtime.Remoting.Messaging.IMethodReturnMessage> interface.  
   
 > [!IMPORTANT]
->  Using binary serialization to deserialize untrusted data can lead to security risks. For more information, see [Data Validation](https://www.owasp.org/index.php/Data_Validation).  
+>  Using binary serialization to deserialize untrusted data can lead to security risks. For more information, see [Data Validation](https://www.owasp.org/index.php/Data_Validation) and the [BinaryFormatter security guide](/dotnet/standard/serialization/binaryformatter-security-guide).
   
 ## Unpaired Surrogates  
  Any unpaired surrogate characters are lost in binary serialization. For example, the following string contains a high surrogate Unicode character `(\ud800`) in between the two `Test` words:  
@@ -289,11 +292,15 @@
         <ReturnType>System.Runtime.Serialization.SerializationBinder</ReturnType>
       </ReturnValue>
       <Docs>
-        <summary>Gets or sets an object of type <see cref="T:System.Runtime.Serialization.SerializationBinder" /> that controls the binding of a serialized object to a type.</summary>
+        <summary>(Insecure) Gets or sets an object of type <see cref="T:System.Runtime.Serialization.SerializationBinder" /> that controls the binding of a serialized object to a type.</summary>
         <value>The serialization binder to use with this formatter.</value>
         <remarks>
           <format type="text/markdown"><![CDATA[  
-  
+
+## BinaryFormatter is insecure
+
+[!INCLUDE[binaryformatter](~/includes/binaryformatter.md)]
+
 ## Examples  
  [!code-cpp[SerializationBinder Example#1](~/samples/snippets/cpp/VS_Snippets_Remoting/SerializationBinder Example/CPP/serializationbinder.cpp#1)]
  [!code-csharp[SerializationBinder Example#1](~/samples/snippets/csharp/VS_Snippets_Remoting/SerializationBinder Example/CS/serializationbinder.cs#1)]

xml/System.Runtime.Serialization.Formatters.Soap/SoapFormatter.xml

@@ -30,7 +30,9 @@
 ## Remarks  
   
 > [!NOTE]
->  Beginning with the .NET Framework 2.0, this class is obsolete. Use <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter> instead.  
+>  Beginning with the .NET Framework 2.0, this class is obsolete.
+
+[!INCLUDE[binaryformatter](~/includes/binaryformatter.md)]
   
  The <xref:System.Runtime.Serialization.Formatters.Soap.SoapFormatter> and <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter> classes implement the <xref:System.Runtime.Remoting.Messaging.IRemotingFormatter> interface to support remote procedure calls (RPCs), and the <xref:System.Runtime.Serialization.IFormatter> interface (inherited by the <xref:System.Runtime.Remoting.Messaging.IRemotingFormatter>) to support serialization of a graph of objects. The <xref:System.Runtime.Serialization.Formatters.Soap.SoapFormatter> class also supports RPCs with <xref:System.Runtime.Serialization.Formatters.ISoapMessage> objects, without using the <xref:System.Runtime.Remoting.Messaging.IRemotingFormatter> functionality.  
   

xml/System.Runtime.Serialization.Formatters/System.Runtime.Serialization.Formatters - Shortcut.lnk

@@ -40,13 +40,16 @@
     <remarks>
       <format type="text/markdown"><![CDATA[  
   
-## Remarks  
- .NET Framework remoting provides two levels of automatic deserialization, Low and Full. The Low deserialization level helps protect against deserialization attacks by deserializing only the types associated with the most basic remoting functionality. The Full deserialization level supports automatic deserialization of all types that remoting supports in all situations. For a list of the .NET Framework remoting types that Low and Full support, see [Automatic Deserialization in .NET Framework Remoting](https://docs.microsoft.com/previous-versions/dotnet/netframework-4.0/5dxse167(v=vs.100)).  
+## Remarks
+
+[!INCLUDE[binaryformatter](~/includes/binaryformatter.md)]
+
+ .NET Framework remoting provides two levels of automatic deserialization, Low and Full. The Full deserialization level supports automatic deserialization of all types that remoting supports in all situations. For a list of the .NET Framework remoting types that Low and Full support, see [Automatic Deserialization in .NET Framework Remoting](https://docs.microsoft.com/previous-versions/dotnet/netframework-4.0/5dxse167(v=vs.100)).  
   
  You can set the members of this enumeration programmatically or by using an application configuration file. For examples, see [Automatic Deserialization in .NET Framework Remoting](https://docs.microsoft.com/previous-versions/dotnet/netframework-4.0/5dxse167(v=vs.100)).  
   
 > [!CAUTION]
->  Do not assume that controlling deserialization is the only security your application requires. In distributed applications, even a high degree of control over serialization might not prevent malicious clients from intercepting the communication and using it in some way, even if that is merely showing data to others. Therefore, although the Low deserialization level provides some protection against certain types of attack based upon automatic deserialization, you must still evaluate whether to use authentication and encryption to help protect the confidentiality of your data.  
+>  Do not assume that controlling deserialization is the only security your application requires. In distributed applications, even a high degree of control over serialization might not prevent malicious clients from intercepting the communication and using it in some way, even if that is merely showing data to others.  
   
  ]]></format>
     </remarks>

xml/System.Runtime.Serialization.Formatters/TypeFilterLevel.xml

@@ -23,7 +23,11 @@
     <summary>Serializes and deserializes an instance of a type into XML stream or document using the supplied .NET Framework types. This class cannot be inherited.</summary>
     <remarks>
       <format type="text/markdown"><![CDATA[  
-  
+
+## Security
+
+<xref:System.Runtime.Serialization.NetDataContractSerializer> is insecure. For more information, see the [BinaryFormatter security guide](/dotnet/standard/serialization/binaryformatter-security-guide).
+ 
 ## Remarks  
  The <xref:System.Runtime.Serialization.NetDataContractSerializer> differs from the <xref:System.Runtime.Serialization.DataContractSerializer> in one important way: the <xref:System.Runtime.Serialization.NetDataContractSerializer> includes CLR type information in the serialized XML, whereas the <xref:System.Runtime.Serialization.DataContractSerializer> does not. Therefore, the <xref:System.Runtime.Serialization.NetDataContractSerializer> can be used only if both the serializing and deserializing ends share the same CLR types.  
   

xml/System.Runtime.Serialization/NetDataContractSerializer.xml

@@ -44,11 +44,15 @@
     <summary>Allows users to control class loading and mandate what class to load.</summary>
     <remarks>
       <format type="text/markdown"><![CDATA[  
-  
+
+## Insecure serializers
+
+[!INCLUDE[binaryformatter](~/includes/binaryformatter.md)]
+
 ## Remarks  
  During serialization, a formatter transmits the information required to create an instance of an object of the correct type and version. This information generally includes the full type name and assembly name of the object. The assembly name includes the name, version, and strong name (see [Strong-Named Assemblies](/dotnet/standard/assembly/strong-named)) hash of the assembly. By default, deserialization uses this information to create an instance of an identical object (with the exception of any assembly loading restricted by the security policy). Some users need to control which class to load, either because the class has moved between assemblies or a different version of the class is required on the server and client.  
   
- <xref:System.Runtime.Serialization.SerializationBinder> can also be used for security. There might be some security exploits when you are trying to deserialize some data from an untrusted source. The binder gives you an opportunity to inspect what types are being loaded in your application domain. You can then either maintain list of denied types or a list of allowed types and restrict which types are being loaded and instantiated. In addition you should be mindful of what information is being put out on the wire, you may want to secure (use transport or message security) when sending type names or other data on the wire.  
+ <xref:System.Runtime.Serialization.SerializationBinder> can not be used for security. There might be some security exploits when you are trying to deserialize some data from an untrusted source. The binder gives you an opportunity to inspect what types are being loaded in your application domain, but this doesn't guarantee an exploit is not possible. For more information see the [BinaryFormatter security guide](/dotnet/standard/serialization/binaryformatter-security-guide). You can then either maintain list of denied types or a list of allowed types and restrict which types are being loaded and instantiated. In addition, be mindful of what information is being put out on the wire. You may want to use transport or message security when sending type names or other data on the network.  
   
 > [!WARNING]
 >  Only use <xref:System.Runtime.Serialization.SerializationBinder> if you are completely sure of what information is being serialized. Malicious types can cause unexpected behavior.  

xml/System.Runtime.Serialization/SerializationBinder.xml

@@ -20,7 +20,11 @@
     <remarks>
       <format type="text/markdown"><![CDATA[  
   
-## Remarks  
+## Remarks
+
+> [!WARNING]
+> `LosFormatter` is insecure and can't be made secure. For more information, see the [BinaryFormatter security guide](/dotnet/standard/serialization/binaryformatter-security-guide).
+
  The limited object serialization (LOS) formatter is designed for highly compact ASCII format serialization. This class supports serializing any object graph, but is optimized for those containing strings, arrays, and hash tables. It offers second order optimization for many of the .NET Framework primitive types.  
   
  This is a private format and remains consistent only for the lifetime of a Web request.  

xml/System.Web.UI/LosFormatter.xml

@@ -29,7 +29,10 @@
     <remarks>
       <format type="text/markdown"><![CDATA[  
   
-## Remarks  
+## Remarks
+
+[!INCLUDE[binaryformatter](~/includes/binaryformatter.md)]
+
  The <xref:System.Web.UI.ObjectStateFormatter> class serializes and deserializes object state graphs in a compact format.  
   
  <xref:System.Web.UI.ObjectStateFormatter> is used by the <xref:System.Web.UI.PageStatePersister> class and classes that derive from it to serialize view state and control state. It is also used by the <xref:System.Web.UI.LosFormatter> class to provide object state graph formatting for various parts of the ASP.NET infrastructure.