Web Services (ASMX 1.1) Security Checklist

From Guidance Share
Jump to navigationJump to search

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


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.


Development Considerations

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">