Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
As specified in [MS-NRBF], the .NET Remoting Binary Format has constructs that could lead to security attacks. Such attacks are also possible in the SOAP encoding, where the Array sizes can be specified in the wire. To mitigate these attacks, it is recommended that implementers consider building implementations that use or encourage the use of HTTPS and that enforce use of HTTP authentication or TCP with authentication and encryption (as specified in [MS-NNS]). Alternatively, an implementation can allow the higher layer to configure an upper limit for the size.
The .NET Remoting Protocol allows Server Objects to be marshaled transparently when a graph of Data Values containing a Server Object is sent across. This inadvertent exposing of new service endpoints can result in security issues. To mitigate such attacks, it is recommended that implementers consider building implementations that require explicit opt-in by the application to enable the transparent marshaling.
De-serialization results in the creation of an instance of a Remoting Type whose information is provided in the message content. It might be unsafe to create an instance of certain Remoting Types. It is recommended that an implementation protect against attacks in which the message content includes unsafe Remoting Types. Such attacks can be mitigated by authentication. Alternatively, an implementation can allow the higher layer to configure a list of Remoting Types in an implementation-specific way and disallow de-serialization of any Remoting Type that is not in the list.