Return to PatternsAndPracticesSecurityWiki

---

Remoting 1.1 Security Checklist

Note: See online on MSDN: http://msdn.microsoft.com/library/en-us/dnnetsec/html/CL_SecuRem.asp
J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

Microsoft Corporation

June 2003

Design Considerations

* Remote components are not exposed to the Internet.
* The ASP.NET host and HttpChannel are used to take advantage of Internet Information Services (IIS) and ASP.NET security features.
* TcpChannel (if used) is only used in trusted server scenarios.
* TcpChannel (if used) is used in conjunction with custom authentication and authorization solutions.

Input Validation

* MarshalByRefObj objects from clients are not accepted without validating the source of the object.
* The risk of serialization attacks are mitigated by setting the typeFilterLevel attribute programmatically or in the application's Web.config file.
* All field items that are retrieved from serialized data streams are validated as they are created on the server side.

Authentication

* Anonymous authentication is disabled in IIS.
* ASP.NET is configured for Windows authentication.
* Client credentials are configured at the client through the proxy object.
* Authentication connection sharing is used to improve performance.
* Clients are forced to authenticate on each call (unsafeAuthenticatedConnectionSharing is set to "false").
* connectionGroupName is specified to prevent unwanted reuse of authentication connections.
* Plain text credentials are not passed over the network.
* IPrincipal objects passed from the client are not trusted.

Authorization

* IPSec is used for machine-level access control.
* File authorization is enabled for user access control.
* Users are authorized with principal-based role checks.
* Where appropriate, access to remote resources is restricted by setting rejectRemoteRequest attribute to "true".

Configuration Management

* Configuration files are locked down and secured for both the client and the server.
* Generic error messages are sent to the client by setting the mode attribute of the <customErrors> element to "On".

Sensitive Data

* Exchange of sensitive application data is secured by using SSL, IPSec, or a custom encryption sink.

Exception Management

* Structured exception handling is used.
* Exception details are logged (not including private data, such as passwords).
* Generic error pages with standard, user friendly messages are returned to the client.

Auditing and Logging

* If ASP.NET is used as the host, IIS auditing features are enabled.
* If required, a custom channel sink is used to perform logging on the client and the server.

---

Return to SecurityChecklists