An unsigned timestamp can leave a SOAP message open to tampering and replay attacks.
Security timestamps indicate the "freshness" of message security semantics. So if a message is intercepted an retransmitted at a later time, the receiver can reject stale messages. 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 and modify the timestamp without the receiver's knowledge. Under these circumstances, an attacker can potentially trick a recipient into accepting a malicious message.
The following service provider configuration tells Axis 2 to send unsigned timestamps:
<service>
...
<parameter name="OutflowSecurity">
<action>
<items>Timestamp Encrypt</items>
...
</action>
</parameter>
</service>
[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A10 Insecure Configuration Management
[2] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A6 Security Misconfiguration
[3] Standards Mapping - FIPS200 - (FISMA) CM
[4] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 345
[5] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Insufficient Authentication
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.10
[7] Securing SOAP Messages with Rampart Apache Software Foundation
[8] Web Sericces Security: SOAP Message Security 1.1 OASIS