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 may 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>

Service Providers that use the UsernameToken might accept passwords sent in plain text. Sending plain text passwords over an unencrypted channel can expose the credential to any attacker who can sniff the SOAP message.

Example 1: The following Axis 2 service provider configuration uses a UsernameToken:

<service>
...
    <parameter name="InflowSecurity">
      <action>
        <items>UsernameToken</items>
...
</service>

The Rampart WS-Security module is not enabled. WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages 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 eliminates the transport security dependency and builds security into the message itself.

WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages 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 eliminates the transport security dependency and builds security into the message itself.

The absence of an InflowSecurity parameter in the Apache Axis 2 configuration file indicates that inbound message security is not enabled.

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following Apache Axis 2 Rampart client configuration does not require inbound messages to be encrypted since the <items> tag does not contain an Encrypt directive:

<service>
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Signature</items>
			...
		</action>
	</parameter>
</service>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

The following client configuration tells Axis 2 to accept unsigned messages:

<axisconfig name="AxisJava2.0">
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

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.

The following Apache Axis 2 Rampart configuration omits the Timestamp directive from the <items> tag, so the client does not require responses to have timestamps.

<axisconfig name="AxisJava2.0">
...
   <parameter name="InflowSecurity">
      <action>
        <items>Signature Encrypt</items>
...
</axisconfig>

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following Apache Axis 2 Rampart client configuration does not require inbound messages to be encrypted since the <items> tag does not contain an Encrypt directive:

<service>
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Signature</items>
			...
		</action>
	</parameter>
</service>

Any part of a message that is not signed has the potential to be intercepted and modified without the modification being detected by the receiver. Without a signature, a receiver cannot cryptographically verify the origin of the message contents.

The following client configuration tells Axis 2 to send unsigned requests:

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

A Security timestamp indicates the freshness of a message's security data. 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 could intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may trick a recipient into accepting a malicious message.

The following Apache Axis 2 Rampart configuration omits the Timestamp directive from the <items> tag, so the client does not send requests with timestamps.

<axisconfig name="AxisJava2.0">
...
   <parameter name="OutflowSecurity">
      <action>
        <items>Signature Encrypt</items>
...
</axisconfig>

WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages 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 eliminates the transport security dependency and builds security into the message itself.

The absence of an OutflowSecurity parameter in the Apache Axis 2 configuration file indicates that outbound message security is not enabled.

Using a password type of PasswordText might be an indication that actual passwords are being transmitted in plain text. The WS-Security UsernameToken Profile states that text sent in the UsernameToken <Password> tag is not limited to actual passwords, but can contain password derivatives instead. However, it is common for developers to send actual passwords instead of password derivatives. Sending unencrypted passwords or even password hashes exposes the credentials to anyone with a traffic sniffer.

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 Axis 2 to accept unsigned timestamps:

<axisconfig name="AxisJava2.0">
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

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 Axis 2 to send unsigned timestamps:

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

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

Example 1: The following Axis 2 client configuration uses UsernameToken (a password):

<axisconfig name="AxisJava2.0">
...
    <parameter name="OutflowSecurity">
      <action>
        <items>UsernameToken</items>
        <user>bob</user>
        <passwordCallbackClass>org.apache.rampart.samples.PWCBHandler</passwordCallbackClass>
        <passwordType>PasswordText</passwordType>
      </action>
    </parameter>
...
</axisconfig>

The Rampart WS-Security module is not enabled. WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality 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 itself.

When axis.development.system is set to true in the server configuration file, the system behaves as if it is a development environment. It sends stack traces in SOAP responses that can leak information about the system or application.

When axis.disableServiceList is set to false, Apache Axis will return a list of available services when a GET is performed on a servlet root. The service list may contain a list of features that show not be publicly accessible.

Using a password type of PasswordText might be an indication that actual passwords are being transmitted in plain text. The WS-Security UsernameToken Profile states that text sent in the UsernameToken <Password> tag are not limited to being actual passwords. They can be password derivatives instead. However, it is common for developers to send actual passwords instead of password derivatives. Sending unencrypted passwords or even password hashes exposes the credentials to anyone with a traffic sniffer.

Service Providers that use the UsernameToken might accept passwords sent in plain text. Sending plain text passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

Example 1: The following Axis service provider configuration uses the UsernameToken:

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>