Return to PatternsAndPracticesSecurityWiki



Web Services (ASMX) 1.1 Security Checklist


Note: See online on MSDN: http://msdn.microsoft.com/library/en-us/dnnetsec/html/CL_SecuWeb.asp

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

Microsoft Corporation

June 2003


Design Considerations

* The authentication strategy has been identified.
* Privacy and integrity requirements of SOAP messages have been considered.
* Identities that are used for resource access have been identified.
* Implications of code access security trust levels have been considered.

Input Validation

* Input to Web methods is constrained and validated for type, length, format, and range.
* Input data sanitization is only performed in addition to constraining input data.
* XML input data is validated based on an agreed schema.

Authentication

* Web services that support restricted operations or provide sensitive data support authentication.
* If plain text credentials are passed in SOAP headers, SOAP messages are only passed over encrypted communication channels, for example, using SSL.
* Basic authentication is only used over an encrypted communication channel.
* Authentication mechanisms that use SOAP headers are based on Web Services Security (WS Security) using the Web Services Enhancements WSE).

Authorization

* Web services that support restricted operations or provide sensitive data support authorization.
* Where appropriate, access to Web service is restricted using URL authorization or file authorization if Windows authentication is used.
* Where appropriate, access to publicly accessible Web methods is restricted using declarative principle permission demands.

Sensitive Data

* Sensitive data in Web service SOAP messages is encrypted using XML encryption OR messages are only passed over encrypted communication channels (for example, using SSL.)

Parameter Manipulation

* If parameter manipulation is a concern (particularly where messages are routed through multiple intermediary nodes across multiple network links). Messages are digitally signed to ensure that they cannot be tampered with.

Exception Management

* Structured exception handling is used when implementing Web services.
* Exception details are logged (except for private data, such as passwords).
* SoapExceptions are thrown and returned to the client using the standard <Fault> SOAP element.
* If application-level exception handling is required a custom SOAP extension is used.

Auditing and Logging

* The Web service logs transactions and key operations.

Proxy Considerations

* The endpoint address in Web Services Description Language (WSDL) is checked for validity.
* The URL Behavior property of the Web reference is set to dynamic for added flexibility.

Administration Considerations

* Unnecessary Web service protocols, including HTTP GET and HTTP POST, are disabled.
* The documentation protocol is disabled if you do not want to support the dynamic generation of WSDL.
* The Web service runs using a least-privileged process account (configured through the <processModel> element in Machine.config.)
* Custom accounts are encrypted by using Aspnet_setref.exe.
* Tracing is disabled with:
<trace enabled="false" />
* Debug compilations are disabled with:
<compilation debug="false" explicit="true" defaultLanguage="vb">




Return to SecurityChecklists
Microsoft Communities