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>

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.

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

Example 1: The following Axis client 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>

Bean property names and values need to be validated before populating any bean. Bean population functions let developers to set a bean property or a nested property. Attackers can leverage this functionality to access special bean properties such as class.classLoader that enable them to override system properties and potentially execute arbitrary code.

Example 1: The following code sets a user-controlled bean property without proper validation of the property name or value:

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

The Apache Ivy automated dependency management system allows users to specify a version status, known as a dynamic revision, for a dependency instead of listing the specific. If an attacker is able to compromise the dependency repository or trick the build system into downloading dependencies from a repository under the attacker's control, then a dynamic revision specifier may be all that's needed for the build system to silently download and run the compromised dependency. Beyond the security risks, dynamic revisions also introduce an element of risk on the code quality front: Dynamic revisions place the security and stability of your software under the control of the third-parties who develop and release the dependencies your software uses.

At build time, Ivy connects to the repository and attempts to retrieve a dependency that matches the status listed.

Ivy accepts the following dynamic revision specifiers:

- latest.integration: Selects the latest revision of the dependency module.
- latest.[any status]: Selects the latest revision of the dependency module with at minimum the specified status. For example, latest.milestone will select the latest version that is either a milestone or a release, and latest.release will only select the latest release.
- Any revision that ends in +: Selects the latest sub-revision of the dependency module. For example, if the dependency exists in revisions 1.0.3, 1.0.7 and 1.1.2, a revision specified as 1.0.+ will select revision 1.0.7.
- Version ranges: Mathematical notation for ranges, such as < and >, can be used to match a range of versions.

Example 1: The following configuration entry instructs Ivy to retrieve the latest release version of the clover component:

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

If the repository is compromised, an attacker could simply upload a version that meets the dynamic criteria to cause Ivy to download a malicious version of the dependency.

Several tools exist within the Java development world to aid in dependency management: both Apache Ant and Apache Maven build systems include functionality specifically designed to help manage dependencies and Apache Ivy is developed explicitly as a dependency manager. Although there are differences in their behavior, these tools share the common functionality that they automatically download external dependencies specified in the build process at build time. This makes it much easier for developer B to build software in the same manner as developer A. Developers just store dependency information in the build file, which means that each developer and build engineer has a consistent way to obtain dependencies, compile the code, and deploy without the dependency management hassles involved in manual dependency management. The following examples illustrate how Ivy, Ant, and Maven can be used to manage external dependencies as part of a build process.

Developers specify external dependencies in an Ant target using a <get> task, which retrieves the dependency specified by the corresponding URL. This approach is functionally equivalent to scenario where a developer documents each external dependency as an artifact included with the software project, but is more desirable because it automates the retrieval and incorporation of the dependencies when a build is performed.

Example 1: The following excerpt from an Ant build.xml configuration file shows a typical reference to an external dependency:

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

Two distinct types of attack scenarios affect these systems: An attacker could either compromise the server hosting the dependency or compromise the DNS server the build machine uses to redirect requests for hostname of the server hosting the dependency to a machine controlled by the attacker. Both scenarios result in the attacker gaining the ability to inject a malicious version of a dependency into a build running on an otherwise uncompromised machine.

Regardless of the attack vector used to deliver the Trojan dependency, these scenarios share the common element that the build system blindly accepts the malicious binary and includes it in the build. Because the build system has no recourse for rejecting the malicious binary and existing security mechanisms, such as code review, typically focus on internally-developed code rather than external dependencies, this type of attack has a strong potential to go unnoticed as it spreads through the development environment and potentially into production.

Although there is some risk of a compromised dependency being introduced into a manual build process, by the tendency of automated build systems to retrieve the dependency from an external source each time the build system is run in a new environment greatly increases the window of opportunity for an attacker. An attacker need only compromise the dependency server or the DNS server during one of the many times the dependency is retrieved in order to compromise the machine on which the build is occurring.

Several tools exist within the Java development world to aid in dependency management: both Apache Ant and Apache Maven build systems include functionality specifically designed to help manage dependencies and Apache Ivy is developed explicitly as a dependency manager. Although there are differences in their behavior, these tools share the common functionality that they automatically download external dependencies specified in the build process at build time. This makes it much easier for developer B to build software in the same manner as developer A. Developers just store dependency information in the build file, which means that each developer and build engineer has a consistent way to obtain dependencies, compile the code, and deploy without the dependency management hassles involved in manual dependency management. The following examples illustrate how Ivy, Ant, and Maven can be used to manage external dependencies as part of a build process.

Under Ivy, instead of listing explicit URLs from which to retrieve the dependencies, developers specify the dependency names and versions and Ivy relies on its underlying configuration to identify the server(s) from which to retrieve the dependencies. For commonly used components this saves the developer from having to researching dependency locations.

Example 1: The following excerpt from an Ivy ivy.xml file shows how a developer can specify multiple external dependencies using their name and version:

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

Two distinct types of attack scenarios affect these systems: An attacker could either compromise the server hosting the dependency or compromise the DNS server the build machine uses to redirect requests for hostname of the server hosting the dependency to a machine controlled by the attacker. Both scenarios result in the attacker gaining the ability to inject a malicious version of a dependency into a build running on an otherwise uncompromised machine.

Regardless of the attack vector used to deliver the Trojan dependency, these scenarios share the common element that the build system blindly accepts the malicious binary and includes it in the build. Because the build system has no recourse for rejecting the malicious binary and existing security mechanisms, such as code review, typically focus on internally-developed code rather than external dependencies, this type of attack has a strong potential to go unnoticed as it spreads through the development environment and potentially into production.

Although there is some risk of introducing a compromised dependency into a manual build process because the tendency of automated build systems to retrieve the dependency from an external source each time the build system runs in a new environment increases the window of opportunity for an attacker. An attacker need only compromise the dependency server or the DNS server during one of the many times the dependency is retrieved in order to compromise the machine on which the build is occurring.

Several tools exist within the Java development world to aid in dependency management: both Apache Ant and Apache Maven build systems include functionality specifically designed to help manage dependencies and Apache Ivy is developed explicitly as a dependency manager. Although there are differences in their behavior, these tools share the common functionality that they automatically download external dependencies specified in the build process at build time. This makes it much easier for developer B to build software in the same manner as developer A. Developers just store dependency information in the build file, which means that each developer and build engineer has a consistent way to obtain dependencies, compile the code, and deploy without the dependency management hassles involved in manual dependency management. The following examples illustrate how Ivy, Ant, and Maven can be used to manage external dependencies as part of a build process.

Under Maven, instead of listing explicit URLs from which to retrieve the dependencies, developers specify the dependency names and versions and Maven relies on its underlying configuration to identify the server(s) from which to retrieve the dependencies. For commonly used components this saves the developer from having to researching dependency locations.

Example 1: The following excerpt from a Maven pom.xml file shows how a developer can specify multiple external dependencies using their name and version:

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

Two distinct types of attack scenarios affect these systems: An attacker could either compromise the server hosting the dependency or compromise the DNS server the build machine uses to redirect requests for hostname of the server hosting the dependency to a machine controlled by the attacker. Both scenarios result in the attacker gaining the ability to inject a malicious version of a dependency into a build running on an otherwise uncompromised machine.

Regardless of the attack vector used to deliver the Trojan dependency, these scenarios share the common element that the build system blindly accepts the malicious binary and includes it in the build. Because the build system has no recourse for rejecting the malicious binary and existing security mechanisms, such as code review, typically focus on internally-developed code rather than external dependencies, this type of attack has a strong potential to go unnoticed as it spreads through the development environment and potentially into production.

Although there is some risk of a compromised dependency being introduced into a manual build process, by the tendency of automated build systems to retrieve the dependency from an external source each time the build system is run in a new environment greatly increases the window of opportunity for an attacker. An attacker need only compromise the dependency server or the DNS server during one of the many times the dependency is retrieved in order to compromise the machine on which the build is occurring.