A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, it might be possible to intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

When a timestamp expires, any security semantics sent with the timestamp should expire as well. Therefore, timestamps without an expiration could allow security semantics (such as UsernameToken credentials) to remain valid indefinitely.

WS-Security is an enhancement to SOAP that provides end-to-end message integrity and confidential regardless of the transport protocol. When WS-Security is not used, message rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and builds security into the message.

The absence of an <securityRequestGeneratorServiceConfig> tag in the IBM WebSphere WS-Security client deployment descriptor extension file indicates that outbound message security is not enabled.

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following client configuration tells WebSphere to accept unsigned timestamps:

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1152150778436">
        ...
        <securityResponseConsumerServiceConfig xmi:id="SecurityResponseConsumerServiceConfig_1212093287097">
            <addTimestamp xmi:id="AddTimestamp_1212093882250"/>
            ...
</com.ibm.etools.webservice.wscext:WsClientExtension>

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following client configuration tells WebSphere to send unsigned timestamps:

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1152150778436">
        ...
        <securityRequestGeneratorServiceConfig xmi:id="SecurityRequestGeneratorServiceConfig_1212078169562">
          <addTimestamp xmi:id="AddTimestamp_1212093882250"/>
          ...
</com.ibm.etools.webservice.wscext:WsClientExtension>

Sending plain text passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

Example 1: The following WebSphere client configuration uses the UsernameToken:

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1151349988084">
...
        <securityRequestGeneratorServiceConfig xmi:id="SecurityRequestGeneratorServiceConfig_1154318832968">
          <securityToken xmi:id="SecurityToken_1211395747219" name="basicauth" uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"/>
...
</com.ibm.etools.webservice.wscext:WsClientExtension>

The MessageProtectionOrder attribute allows you to specify the order in which signatures and encryption are applied (and whether or not the signatures should be encrypted). Setting the MessageProtectionOrder attribute to anything other than SignBeforeEncryptAndEncryptSignature constitutes a potential security problem.

The following is a list of possible alternatives to SignBeforeEncryptAndEncryptSignature and their associated problems.
SignBeforeEncrypt - The signature is applied to the unencrypted message, but the signature itself is not encrypted.
EncryptBeforeSign - Message contents are encrypted then signed.

Messages signed with a low entropy keys, such as passwords, are more vulnerable to brute-force attacks.

The <authorization> element specifies a list of authorization rules. If an <authorization> element exists and no rules apply to a sender, access is denied [1].
In this case, no <authorization> tag exists in the identified configuration file and anonymous access might be possible.

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following snippet from a WSE policy file is an example where timestamps are not include in SOAP faults:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
...
      <protection>
        <fault signatureOptions="IncludeAddressing, IncludeSoapBody" encryptBody="true" />

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following snippet from a WSE policy file is an example where timestamps are not include in SOAP message requests:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
...
      <protection>
        <request signatureOptions="IncludeAddressing, IncludeSoapBody" encryptBody="true" />

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following snippet from a WSE policy file is an example where timestamps are not included in SOAP message responses:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
...
      <protection>
        <response signatureOptions="IncludeAddressing, IncludeSoapBody" encryptBody="true" />