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: 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: 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.