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:
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.
Policy Advisor is an XSL stylesheet for viewing endpoint files. An endpoint file is an XML document holding a sequence of <ep:endpoint> elements, grouped as a single <ep:endpoints> element, where ep is the namespace http://schemas.microsoft.com/pa/2005/10/endpoints.
Each endpoint file should include the XML directive <?xml-stylesheet href="PolicyAdvisor.xml" type="text/xsl"?> so that opening the file with Internet Explorer generates a report by calling the PolicyAdvisor.xml stylesheet.
Each <ep:endpoint> 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.
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.
Policy Advisor performs a series of queries that may trigger specific advice, listed below.
For each query, we give the triggering condition, a description of the risk, and some remedial advice.
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 <x509> element of the WSE configuration file.
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 <replayDetection enabled="true" windowInSeconds="300" /> in the <add> element for the SecurityTokenManager. Note that the WSE cache does not detect replays on distinct servers in a server farm.
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 <x509> element of the WSE configuration file.
Risk: An attacker may intentionally trigger errors to gather information on the endpoint implementation, potentially enabling further attacks.
Advice: In production, include the element <detailedErrors enabled="false" /> in the <diagnostics> element of the WSE configuration file.
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 <username> element.
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.
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.
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".
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.
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.
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.
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.
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.
Risk: The level of protection is ambiguous.
Advice: Select one element, and remove the other.
Risk: The WSE default level of protection applies, and may be inappropriate here.
Advice: Consider adding an explicit default protection element.
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.
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.
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.
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 <Action> SOAP header.
Advice: Include <requireActionHeader /> in the policy.