Apache Axis 2 provides developers with a utility to monitor incoming and outgoing SOAP messages through a Java applet. The SOAP Monitor will show all SOAP messages used to invoke a Web Service. Attackers may use the utility to eavesdrop on traffic between a Web Service and its clients.

If a service relays messages to other services, the messages are exposed to the weakest transport mechanism used between relay points. REST by itself does not include any security mechanisms, so this service relies on the transport layer for message integrity and confidentiality.

The following configuration enables REST:

<axisconfig name="AxisJava2.0">
...
    <parameter name="disableREST" locked="true">false</parameter>
...
</axisconfig>

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel. The <transportSender> tag should not specify http, because communication with this URL will not be encrypted.

WS-Security is an enhancement to 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 removes the transport security dependency and secures the message itself.

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

The following Apache Axis 2 Rampart 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>

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.

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

The following service provider configuration tells Axis 2 to accept unsigned messages:

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

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 service does not require requests to contain timestamps.

<service>
...
      <action>
        <items>Signature Encrypt</items>
...
</service>

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 configuration does not require outbound 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 integrity or origin of the message contents.

The following service provider configuration tells Axis 2 to send unsigned timestamps:

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

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 service does not send messages with timestamps.

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

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 removes the transport security dependency and secures the message itself.

. The absence of an OutflowSecurity parameter in the Apache Axis 2 configuration 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 service provider configuration tells Axis 2 to accept messages with unsigned timestamps:

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

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>