Download DOH BIT Web Services Code Review Checklist

Pennsylvania Department of Health
Bureau of Information Technology
Web Services Peer Review Checklist
Copyright © 2008 by the Commonwealth of Pennsylvania. All Rights Reserved.
Web Services Peer Review Checklist
Page 2 of 8
Table of Contents
1.
Introduction ....................................................................................................4
2.
Web Service Peer Review Checklist .................................................................4
3.
General Design Considerations ........................................................................4
4.
General Design Considerations ........................................................................4
4.1.
Threading .................................................................................................... 4
4.2.
One Way (Fire and Forget) Communication ...................................................... 5
4.3.
Asynchronous Web Methods ........................................................................... 5
4.4.
Web Methods ............................................................................................... 5
4.5.
Serialization ................................................................................................. 5
4.6.
Caching ....................................................................................................... 5
4.7.
State Management ........................................................................................ 5
4.8.
Attachments................................................................................................. 6
4.9.
Input Validation ............................................................................................ 6
4.10.
Authentication ........................................................................................... 6
4.11.
Authorization ............................................................................................ 6
4.12.
Sensitive Data ........................................................................................... 7
4.13.
Parameter Manipulation .............................................................................. 7
4.14.
Exception Management .............................................................................. 7
4.15.
Auditing and Logging ................................................................................. 7
4.16.
Proxy Considerations ................................................................................. 7
5.
Administration Considerations ........................................................................8
Version 1.0 – 6 February 2008
Web Services Peer Review Checklist
Page 3 of 8
Document History
Version
Date
Author
Status
Notes
1.0
2/6/2008
Frank Froment
Final
Adapted from PA-NEDSS
Version 1.0 – 6 February 2008
Web Services Peer Review Checklist
1.
Page 4 of 8
Introduction
This checklist has been adapted from the Microsoft MSDN Patterns and Practices web site
documents, "Improving Web Service Performance" and “Building Secure Web Services” and
their respective checklists. Detailed explanations for items contained within this checklist
can be found within the before mentioned documents.
2.
Web Service Peer Review Checklist
Before submitting your code for Peer Review the following checklist must be completed.
Submit this document and the “Code Review Process” form to the reviewer(s).
Author
Project Name (if applicable)
Object Name (if applicable)
Note: If an item(s) is not applicable, type "n/a" in place of the check box.
3.
General Design Considerations
Check
Description
Notes
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.
Design chunky interfaces to reduce round trips.
Prefer message-based programming to remote procedure call (RPC) style when
multiple web method calls are required to complete a single logical operation.
Use literal message encoding (default) for parameter formatting unless you are
required to use SOAP encoding for interoperability with platforms that do not support
the literal format.
Prefer the use of primitive types (int, string, etc) for Web Service parameters.
Avoid maintaining server state between calls.
Consider input validation for costly Web methods to reduce unnecessary processing
later on.
Consider your approach to caching.
Consider approaches for bulk data transfer and attachments.
Avoid calling local web services.
4.
4.1.
General Design Considerations
Threading
Version 1.0 – 6 February 2008
Web Services Peer Review Checklist
Check
Page 5 of 8
Description
Notes
Tune the thread pool using the formula for reducing contention.
Consider minIoThreads and minWorkerThreads for intermittent burst load.
4.2.
Check
One Way (Fire and Forget) Communication
Description
Notes
Consider using the OneWay attribute if you do not require a response.
4.3.
Check
Asynchronous Web Methods
Description
Notes
Use asynchronous Web methods for I/O operations.
Do not use asynchronous Web methods when you depend on worker threads.
4.4.
Check
Web Methods
Description
Notes
Prefer primitive parameter types.
Consider buffering.
Consider caching responses when returning small amounts or relatively static data
Enable session state only for Web methods that need it for successive calls to the web
service.
4.5.
Check
Serialization
Description
Notes
Reduce serialization with XmlIgnore.
Reduce round trips.
Consider XML compression.
4.6.
Check
Caching
Description
Notes
Consider output caching for less volatile data.
Consider providing cache-related information to clients.
Consider perimeter caching.
4.7.
Check
State Management
Description
Notes
Version 1.0 – 6 February 2008
Web Services Peer Review Checklist
Page 6 of 8
Avoid server affinity.
4.8.
Check
Attachments
Description
Notes
Consider using the maxRequestLength setting in the <httpRuntime> section of the
web.config file when a byte array parameter is used. This will help limit the web
services susceptibility to denial of service attacks.
Prefer Base64 encoding. Direct Internet Message Encapsulation (DIME) is a supported
part of Web Services Enhancements (WSE), but Microsoft® is not investing in this
approach long-term. DIME is limited because the attachments are outside the SOAP
envelope.
Check
Description
Notes
Avoid single-threaded apartment (STA) COM objects.
4.9.
Check
Input Validation
Description
Notes
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.
4.10.
Check
Authentication
Description
Notes
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).
4.11.
Check
Authorization
Description
Notes
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.
Version 1.0 – 6 February 2008
Web Services Peer Review Checklist
4.12.
Check
Page 7 of 8
Sensitive Data
Description
Notes
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.)
4.13.
Check
Parameter Manipulation
Description
Notes
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.
4.14.
Check
Exception Management
Description
Notes
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.
Exceptions are never handled, then rethrown without justification for doing so.
4.15.
Check
Auditing and Logging
Description
Notes
The Web service logs transactions and key operations.
4.16.
Proxy Considerations
Used for Clients, such as ASP.Net or Web Service applications, when calling a web service
Check
Description
Notes
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.
Any Web references have the “URL Behavior” property set to “Dynamic” and the
Web.config file is properly noted in the appSettings section.
Configure the maxconnection attribute.
Prioritize and allocate connections across discrete Web services.
Use a single identity for outbound calls.
Version 1.0 – 6 February 2008
Web Services Peer Review Checklist
Page 8 of 8
Consider UnsafeAuthenticatedConnectionSharing with Windows Integrated
Authentication.
Use PreAuthenticate with Basic authentication.
Consider calling Web services asynchronously when you have additional parallel work.
Use asynchronous invocation to call multiple unrelated Web services.
Call Web services asynchronously for UI responsiveness.
Set your proxy timeout appropriately.
Abort connections for ASP.NET pages that timeout before a Web services call
completes.
Consider the responseDeadlockInterval attribute.
5.
Administration Considerations
Check Description
Notes
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. Unless there is a business reason for this,
dynamic generation of the WSDL should be disabled as a security measure
to prevent exposing the functionality of the web service.
<webServices>
<protocols>
<remove name="Documentation"/>
</protocols>
</webServices>
Tracing is disabled with:
<trace enabled="false" />
Debug compilations are disabled with:
<compilation debug="false" explicit="true" defaultLanguage="vb">
Version 1.0 – 6 February 2008