Policy Advisor for WSE 3.0

Policy Advisor is a security tool for Web Services Enhancements 3.0 for Microsoft .NET (WSE). It examines the configuration and policy files for one or more WSE endpoints, highlights typical security risks, and provides some remedial advice. Moreover, it summarizes the associated trace files (when present), showing message flows between endpoints.

Policy Advisor can be used for reviewing the security of WSE installations. It generates a report that describes errors such as weak or apparently inconsistent security properties, highlights settings that are useful during test but inappropriate in production, and raises some questions to be determined during security reviews. The absence of warnings does not in itself provide strong security guarantees; nonetheless, Policy Advisor can find issues that may otherwise be missed.

This version of Policy Advisor is specific to WSE 3.0; it has the following new features:

• It supports the new Turnkey Security Assertions.
• It summarizes message flows between multiple endpoints.
• It analyzes multiple configuration, policy, and trace files, as listed in an endpoint file.
• It groups advice by query (instead of policy) to provide a compact report even if many policies are analyzed at once.
• It needs no installation; PolicyAdvisor.xml is simply an XSL stylesheet for viewing endpoint files.

Using Policy Advisor

To analyze the files associated with one or more endpoints, create an endpoint file with a text editor, save it in the same directory as PolicyAdvisor.xml, and open it with Internet Explorer.

To view this documentation, open PolicyAdvisor.xml itself with Internet Explorer.

WSE Endpoint Files

Policy Advisor is an XSL stylesheet for viewing endpoint files. An endpoint file is an XML document holding a sequence of elements, grouped as a single element, where ep is the namespace http://schemas.microsoft.com/pa/2005/10/endpoints.

Each endpoint file should include the XML directive so that opening the file with Internet Explorer generates a report by calling the PolicyAdvisor.xml stylesheet.

Each element describes a single WSE endpoint, such as a client or server project. The element may have the following attributes, each of which is optional.

• name: A name for identifying the endpoint in the report generated by Policy Advisor.
• path: A base path for the following attributes.
• config: The configuration file for this endpoint. The concatenation of path and config is the path to the configuration file.
• policyCache: The policy file for this endpoint. The concatenation of path and policyCache is the path to the policy file.
• input: An existing trace of input messages for this endpoint, used (when present) to illustrate its message flow. The concatenation of path and input is the path to the trace file.
• output: An existing trace of output messages for this endpoint, used (when present) to illustrate its message flow. The concatenation of path and output is the path to the trace file.

Caution: if any of these paths cannot be resolved to a file, the browser will fail to generate a report and display instead an error message such as the system cannot locate the resource specified. Relative paths are resolved with respect to the directory holding the endpoint file.

Limitations

• Some elements and attributes assume default values when absent; Policy Advisor may not always correctly determine these defaults.
• In message flows, responses may sometimes precede requests in the message listing, as messages are sorted by timestamp with a one-second granularity.

Appendix

Policy Advisor performs a series of queries that may trigger specific advice, listed below.

1. Test root certificates are allowed.
2. Replay detection is not enabled for a SecurityTokenManager of type UsernameToken.
3. Certificates are not verified up to a trusted root authority.
4. Detailed errors are enabled.
5. This policy includes a plaintext password.
6. This policy would enable a credit-taking attack. It is disallowed by WSE.
7. This policy enables a credit-taking attack on the encrypted body of a request message.
8. This policy enables a dictionary attack on an encrypted request, response, or fault whose message body has low entropy.
9. This policy does not guarantee correlation between a request and the corresponding response or fault message.
10. This policy encrypts the request body, but does not encrypt the response body.
11. This policy does not encrypt the request, response, or fault body.
12. This policy encrypts the request or response body, but does not encrypt the fault body.
13. This policy encrypts the request, response, or fault body but does not sign it.
14. This policy has two protection elements for the same action.
15. This policy has no explicit default protection element.
16. This policy accepts a request, response, or fault with an unauthenticated body.
17. This policy accepts a request, response, or fault with unauthenticated addressing headers.
18. This policy accepts a request, response, or fault with unauthenticated timestamp.
19. This policy does not require compatibility between the SOAPAction HTTP header and the wsa:Action SOAP header.

For each query, we give the triggering condition, a description of the risk, and some remedial advice.

1. Test root certificates are allowed.

   Risk: Any usage of X.509 certificates for signing or encrypting is unsafe. An active attacker can generate valid test certificates, then for instance use these certificates to sign any message.

   Advice: Do not use test keys in production: set the attribute allowTestRoot="false" in the element of the WSE configuration file.

2. Replay detection is not enabled for a SecurityTokenManager of type UsernameToken.

   Risk: The same username token may be accepted many times, leading to replay attacks. The risk is mitigated if username tokens are used only to establish security contexts, as the handshake establishing the security context prevents replays.

   Advice: Consider enabling the WSE replay detection cache by including an element such as in the element for the SecurityTokenManager. Note that the WSE cache does not detect replays on distinct servers in a server farm.

3. Certificates are not verified up to a trusted root authority.

   Risk: The policy does not prescribe checking that X.509 certificates have an issuer chain that extends to a trusted root authority; hence any usage of X.509 certificates for signing or encrypting fully trusts the current content of the local certificate store.

   Advice: Set the attribute verifyTrust="true" in the element of the WSE configuration file.

4. Detailed errors are enabled.

   Risk: An attacker may intentionally trigger errors to gather information on the endpoint implementation, potentially enabling further attacks.

   Advice: In production, include the element in the element of the WSE configuration file.

5. This policy includes a plaintext password.

   Risk: The password may be leaked if the source of the policy file is disclosed.

   Advice: Use code to discover the password, either from the user, or from some secure store. For further information, see the WSE documentation for the element.

6. This policy would enable a credit-taking attack. It is disallowed by WSE.

   Risk: Messages are encrypted then signed, so an attacker may intercept a message, remove the original signature, and generate a new envelope with the same encrypted body and its own signature. From the receiver's viewpoint, the resulting message is valid, and its body is attributed to the attacker.

   Advice: Use either messageProtectionOrder="SignBeforeEncrypt" or messageProtectionOrder="SignBeforeEncryptAndEncryptSignature" with the mutualCertificate10Security assertion.

7. This policy enables a credit-taking attack on the encrypted body of a request message.

   Risk: Messages are encrypted then signed, so an attacker may intercept a message, remove the original supporting signature, and generate a new envelope with the same encrypted body and its own signature. From the receiver's viewpoint, the resulting message is valid, and its body is attributed to the attacker.

   Advice: If the body of the request cannot be guaranteed to identify the holder of the X.509 certificate used to sign the request, use either messageProtectionOrder="SignBeforeEncrypt" or messageProtectionOrder="SignBeforeEncryptAndEncryptSignature" with the mutualCertificate11Security assertion.

8. This policy enables a dictionary attack on an encrypted request, response, or fault whose message body has low entropy.

   Risk: The message body is encrypted, but the cryptographic hash of the plaintext message body is also included in the signature. Hence, an attacker that intercepts the message may obtain this hash and compare it to the hash of a large number of potential message bodies. Once two hashes match, the attacker has broken confidentiality of the message body.

   Advice: If the body cannot be guaranteed to have high entropy (that is, if the body does not always include some fresh, secret cryptographic value), use either messageProtectionOrder="EncryptBeforeSign" or messageProtectionOrder="SignBeforeEncryptAndEncryptSignature".

9. This policy does not guarantee correlation between a request and the corresponding response or fault message.

   Risk: The mutualCertificate10Security assertion relies on the unencrypted message identifier for correlation. An attacker may intercept a request, send some other request with the same identifier, obtain a response from the server, and forward that response to the original requester.

   Advice: Use establishSecurityContext="true" with mutualCertificate10Security.

10. This policy encrypts the request body, but does not encrypt the response body.

    Risk: Inasmuch as responses depend on requests, an attacker that intercepts the response learns partial information about the request.

    Advice: Consider encrypting responses as well as requests.

11. This policy does not encrypt the request, response, or fault body.

    Risk: An attacker that intercepts the message obtains any information included in its body.

    Advice: Ensure the message body never contains any confidential information, or encrypt the message body.

12. This policy encrypts the request or response body, but does not encrypt the fault body.

    Risk: Although useful during test, there is a risk of information disclosure in production.

    Advice: In production, consider encrypting faults as well as requests and responses.

13. This policy encrypts the request, response, or fault body but does not sign it.

    Risk: An attacker may intercept, rewrite, and forward the message to recipients that may misinterpret its content.

    Advice: Sign every message body whose integrity is relevant for security.

14. This policy has two protection elements for the same action.

    Risk: The level of protection is ambiguous.

    Advice: Select one element, and remove the other.

15. This policy has no explicit default protection element.

    Risk: The WSE default level of protection applies, and may be inappropriate here.

    Advice: Consider adding an explicit default protection element.

16. This policy accepts a request, response, or fault with an unauthenticated body.

    Risk: An attacker may intercept messages and freely rewrite their bodies.

    Advice: Sign the message, or confirm that message integrity is never required for this kind of message.

17. This policy accepts a request, response, or fault with unauthenticated addressing headers.

    Risk: The processing of messages usually depends on their addressing headers. An attacker may intercept messages and freely rewrite those headers, thereby causing the message to be accepted and misinterpreted by some unintended recipient.

    Advice: Sign the addressing headers as well as the body, or confirm that the processing of the message never depends on any addressing header.

18. This policy accepts a request, response, or fault with unauthenticated timestamp.

    Risk: The attacker may intercept the message and replay it several times with different timestamps, thereby causing the message to be accepted several times if replay protection is based on the timestamp.

    Advice: Sign the timestamp if it is used to protect against replays.

19. This policy does not require compatibility between the SOAPAction HTTP header and the wsa:Action SOAP header.

    Risk: There is a risk of redirection attacks on SOAP requests that include an unauthenticated SOAPAction HTTP header, but do not include the WS-Addressing SOAP header.

    Advice: Include in the policy.