SOAP 消息级别的加密可确保实现真正的端到端机密性。SOAP 消息可以通过多种传输协议（例如 HTTPS、HTTP、TCP、SMTP、UDP 等）发送。消息级别加密可确保消息的机密性，无论其传输协议如何。Web 服务中的一个常见情况是在服务之间中继 SOAP 消息，因此消息级别加密意味着消息发送方和接收方无需担心任何中继点之间的所有传输安全。

示例 1：下列 Apache Axis 2 Rampart 客户端配置不要求对入站消息进行加密，因为 <items> 标签不包含 Encrypt 指令：

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

任何未签名的消息部分都有可能在接收者未察觉修改的情况下被拦截和修改。若未经签名，接收者将无法通过加密验证消息内容的来源。

以下客户端配置指示 Axis 2 发送未签名请求：

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

安全时间戳指示消息的安全数据的新鲜度。如果攻击者拦截了一条消息并在稍后重新传输该消息，则接收方可以拒绝重放攻击，因为时间戳将指示该消息是过时的。时间戳可以选择性包含到期属性，该属性会对安全语义有效期设置硬性限制。

为了防止攻击者篡改时间戳，应对时间戳进行签名。如果未对时间戳进行签名，攻击者就可以拦截 SOAP 消息，修改时间戳，然后在接收方不知情的情况下发送消息。在这些情况下，攻击者可能会欺骗接收方接受恶意消息。

以下 Apache Axis 2 Rampart 配置忽略了 <items> 标签中的 Timestamp 指令，因此客户端发送的请求不含时间戳。

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

WS-Security 是 SOAP 扩展，旨在确保端到端消息完整性和机密性，且不受传输协议影响。若未使用 WS-Security，消息依赖传输安全模式确保完整性和机密性。如果服务将消息转发到其他服务，消息将暴露在转发点之间使用的最弱传输机制之下。WS-Security 可消除传输安全依赖项，将安全模式内置到消息本身。

Apache Axis 2 配置文件中缺少 OutflowSecurity 参数表示未启用出站消息安全模式。

使用密码类型 PasswordText 可能表明采用明文的形式传输实际密码。WS-Security UsernameToken Profile 表明 UsernameToken <Password> 标签中发送的文本不限于实际密码，反而可能包含密码派生。但是，开发人员往往发送实际密码而非密码派生。发送未加密密码甚至密码散列会将凭据暴露给所有采用流量探测器的用户。

安全时间戳表示消息新鲜度。如果攻击者拦截了一条消息并在稍后重新传输该消息，则接收方可以拒绝重放攻击，因为时间戳将指示该消息是过时的。时间戳可以选择性包含到期属性，该属性会对安全语义有效期设置硬性限制。

为了防止攻击者篡改时间戳，应对时间戳进行签名。如未设置签名时间戳，攻击者可能拦截 SOAP 消息、修改时间戳并在接收者毫不知情的情况下发送消息。在这些情况下，攻击者可能会诱骗收件人接受恶意邮件。

以下客户端配置指示 Axis 2 接受未签名时间戳：

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

安全时间戳表示消息新鲜度。如果攻击者拦截了一条消息并在稍后重新传输该消息，则接收方可以拒绝重放攻击，因为时间戳将指示该消息是过时的。时间戳可以选择性包含到期属性，该属性会对安全语义有效期设置硬性限制。

为了防止攻击者篡改时间戳，应对时间戳进行签名。如未设置签名时间戳，攻击者可能拦截 SOAP 消息、修改时间戳并在接收者毫不知情的情况下发送消息。在这些情况下，攻击者可能会诱骗收件人接受恶意邮件。

以下客户端配置指示 Axis 2 发送未签名时间戳：

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

在未加密通道上发送明文密码会将凭据暴露给可以探查 SOAP 消息的攻击者。

示例 1：下列 Axis 2 客户端配置使用了 UsernameToken（密码）：

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

未启用 Rampart WS-Security 模块。WS-Security 是 SOAP 扩展，旨在确保端到端消息完整性和机密性，且不受传输协议影响。若未使用 WS-Security，消息依赖传输安全模式确保完整性和机密性。如果服务将消息转发到其他服务，消息将暴露在转发点之间使用的最弱传输机制之下。WS-Security 可删除传输安全依赖项，将安全模式内置到消息本身。

当在服务器配置文件中将 axis.development.system 设置为 true 时，系统行为与开发环境一致。在 SOAP 响应中发送堆栈跟踪，这可能会泄漏有关系统或应用程序的信息。

当 axis.disableServiceList 设置为 false 时，如果对 servlet 根目录执行 GET，Apache Axis 将返回可用服务列表。服务列表可能包含显示为不可公开访问的功能列表。

使用密码类型 PasswordText 可能表明采用明文的形式传输实际密码。The WS-Security UsernameToken Profile 表明 UsernameToken <Password> 标签中发送的文本不限于实际密码。也可以改用密码衍生。但是，开发人员往往发送实际密码而非密码派生。发送未加密密码甚至密码散列会将凭据暴露给所有采用流量探测器的用户。

使用 UsernameToken 的服务提供商可能接受采用明文的形式发送的密码。在未加密通道上发送明文密码会将凭据暴露给可以探查 SOAP 消息的攻击者。

示例 1：下列 Axis 服务提供程序配置使用了 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>

使用密码类型 PasswordText 可能表明采用明文的形式传输实际密码。The WS-Security UsernameToken Profile 表明 UsernameToken <Password> 标签中发送的文本不限于实际密码。也可以改用密码衍生。但是，开发人员往往发送实际密码而非密码派生。发送未加密密码甚至密码散列会将凭据暴露给所有采用流量探测器的用户。

通过未加密通道发送明文密码或密码散列可能会使凭据暴露于可以探查 SOAP 消息的攻击者面前。

示例 1：下列 Axis 客户端配置使用了 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 属性的名称和值在填充任何 bean 之前都需要进行验证。Bean 填充功能允许开发人员设置 bean 属性或嵌套属性。攻击者可以利用此功能访问特殊的 bean 属性，例如 class.classLoader，此类属性将允许攻击者覆盖系统属性并可能会执行任意代码。

示例 1：以下代码在未正确验证属性名称或值的情况下设置用户控制的 bean 属性：

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

Apache Ivy 自动化依赖项管理系统允许用户为依赖项指定版本状态（称为动态修订），而不是列出特定版本。如果攻击者能够危及依赖项存储库或诱骗编译系统从攻击者控制的存储库下载依赖项，那么编译系统可能只需提供动态修订说明符即可静默下载并运行受损的依赖项。除安全风险之外，动态修订还会引发代码质量风险：动态修订将软件安全性和稳定性控制权交到开发和发布软件所使用的依赖项的第三方的手中。

编译时，Ivy 连接存储库并尝试检索与列出的状态匹配的依赖项。

Ivy 接受以下动态修订说明符：

- latest.integration：选择最新修订版依赖项模块。
- latest.[any status]：选择至少为指定状态的最新修订版依赖项模块。例如，latest.milestone 将选择作为里程碑或发布版本的最新版本，latest.release 只会选择最新发布版本。
- 任何以 + 结尾的修订版本：选择最新子修订版依赖项模块。例如，如果修订版本 1.0.3、1.0.7 和 1.1.2 中存在依赖项，则指定为 1.0.+ 的修订版本将选择修订版本 1.0.7。
- 版本范围：范围的数学符号（例如 < 和 >）可用于匹配一系列版本。

示例 1：以下配置条目指示 Ivy 检索最新发布版 Clover 组件：

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

如果存储库受损，攻击者可以直接上传符合动态标准的版本，诱使 Ivy 下载恶意版本依赖项。

可通过 Java 开发环境中的几个工具来帮助进行依赖项管理：Apache Ant 和 Apache Maven 编译系统都包含专门用来管理依赖项的功能，而 Apache Ivy 则是明确作为依赖项管理器而开发的。尽管这些工具在行为方式上存在差异，但它们都有一种通用的功能，即会自动下载在编译过程中指定的外部依赖项。这样一来，两个不同的开发人员用同一种方式来编译软件就容易得多。开发人员只需在编译文件中存储依赖项信息即可，这意味着，每个开发人员和编译工程师都可通过同一种方式来获得依赖项、编译代码并进行部署，而不需要手动进行繁琐的依赖项管理。以下示例演示了如何使用 Ivy、Ant 和 Maven 在编译过程中管理外部依赖项。

开发人员在 Ant 目标中使用 <get> 任务指定外部依赖项，检索由相应 URL 指定的依赖项。此方法的功能等同于开发人员将各外部依赖项记录为软件项目附带的工件，但效果更加理想，因为它在执行编译时会自动检索及合并依赖项。

示例 1：Ant build.xml 配置文件中的以下代码摘录展示了典型的外部依赖项引用方法：

<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"/>

以下两种不同类型的攻击场景会对这些系统产生影响：攻击者可能攻击托管依赖项的服务器，也可能攻击编译计算机用于将托管依赖项的服务器主机名的请求重定向到攻击者控制的计算机的 DNS 服务器。在这两种场景下，攻击者可将恶意版本依赖项注入基于未受攻击的计算机运行的编译系统中。

无论用于传递特洛伊木马依赖项的攻击向量如何，这些场景都有一个共同特点，即编译系统盲目接受恶意二进制代码并将其纳入编译系统。由于编译系统无法拒绝恶意二进制代码，且现有安全机制（例如，代码审查）通常侧重于内部开发的代码而非外部依赖项，此类攻击很可能会被忽视，因为它会通过开发环境扩展并可能投入生产环境。

尽管将受损依赖项引入手动编译过程存在一定风险，但自动编译系统倾向于每次在新环境中运行编译系统时从外部数据源检索依赖项，这会大大增加攻击者的攻击机会。攻击者只需在多次检索依赖项时选择一次攻击依赖项服务器或 DNS 服务器，以便攻击执行编译的计算机。

可通过 Java 开发环境中的几个工具来帮助进行依赖项管理：Apache Ant 和 Apache Maven 编译系统都包含专门用来管理依赖项的功能，而 Apache Ivy 则是明确作为依赖项管理器而开发的。尽管这些工具在行为方式上存在差异，但它们都有一种通用的功能，即会自动下载在编译过程中指定的外部依赖项。这样一来，两个不同的开发人员用同一种方式来编译软件就容易得多。开发人员只需在编译文件中存储依赖项信息即可，这意味着，每个开发人员和编译工程师都可通过同一种方式来获得依赖项、编译代码并进行部署，而不需要手动进行繁琐的依赖项管理。以下示例演示了如何使用 Ivy、Ant 和 Maven 在编译过程中管理外部依赖项。

在 Ivy 下，开发人员不会列出从中检索依赖项的显式 URL，而是指定依赖项名称和版本，Ivy 依赖其底层配置识别从中检索依赖项的服务器。对于常用组件，开发人员将不必研究依赖项位置。

示例 1：Ivy ivy.xml 文件中的以下代码摘录展示了开发人员如何使用依赖项名称和版本指定多个外部依赖项：

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

以下两种不同类型的攻击场景会对这些系统产生影响：攻击者可能攻击托管依赖项的服务器，也可能攻击编译计算机用于将托管依赖项的服务器主机名的请求重定向到攻击者控制的计算机的 DNS 服务器。在这两种场景下，攻击者可将恶意版本依赖项注入基于未受攻击的计算机运行的编译系统中。

无论用于传递特洛伊木马依赖项的攻击向量如何，这些场景都有一个共同特点，即编译系统盲目接受恶意二进制代码并将其纳入编译系统。由于编译系统无法拒绝恶意二进制代码，且现有安全机制（例如，代码审查）通常侧重于内部开发的代码而非外部依赖项，此类攻击很可能会被忽视，因为它会通过开发环境扩展并可能投入生产环境。

尽管将受损依赖项引入手动编译过程存在一定风险，但自动编译系统倾向于每次在新环境中运行编译系统时从外部数据源检索依赖项，这会增加攻击者的攻击机会。攻击者只需在多次检索依赖项时选择一次攻击依赖项服务器或 DNS 服务器，以便攻击执行编译的计算机。

可通过 Java 开发环境中的几个工具来帮助进行依赖项管理：Apache Ant 和 Apache Maven 编译系统都包含专门用来管理依赖项的功能，而 Apache Ivy 则是明确作为依赖项管理器而开发的。尽管这些工具在行为方式上存在差异，但它们都有一种通用的功能，即会自动下载在编译过程中指定的外部依赖项。这样一来，两个不同的开发人员用同一种方式来编译软件就容易得多。开发人员只需在编译文件中存储依赖项信息即可，这意味着，每个开发人员和编译工程师都可通过同一种方式来获得依赖项、编译代码并进行部署，而不需要手动进行繁琐的依赖项管理。以下示例演示了如何使用 Ivy、Ant 和 Maven 在编译过程中管理外部依赖项。

在 Maven 下，开发人员不会列出从中检索依赖项的显式 URL，而是指定依赖项名称和版本，Maven 依赖其底层配置识别从中检索依赖项的服务器。对于常用组件，开发人员将不必研究依赖项位置。

示例 1：Maven pom.xml 文件中的以下代码摘录展示了开发人员如何使用依赖项名称和版本指定多个外部依赖项：

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

以下两种不同类型的攻击场景会对这些系统产生影响：攻击者可能攻击托管依赖项的服务器，也可能攻击编译计算机用于将托管依赖项的服务器主机名的请求重定向到攻击者控制的计算机的 DNS 服务器。在这两种场景下，攻击者可将恶意版本依赖项注入基于未受攻击的计算机运行的编译系统中。

无论用于传递特洛伊木马依赖项的攻击向量如何，这些场景都有一个共同特点，即编译系统盲目接受恶意二进制代码并将其纳入编译系统。由于编译系统无法拒绝恶意二进制代码，且现有安全机制（例如，代码审查）通常侧重于内部开发的代码而非外部依赖项，此类攻击很可能会被忽视，因为它会通过开发环境扩展并可能投入生产环境。

尽管将受损依赖项引入手动编译过程存在一定风险，但自动编译系统倾向于每次在新环境中运行编译系统时从外部数据源检索依赖项，这会大大增加攻击者的攻击机会。攻击者只需在多次检索依赖项时选择一次攻击依赖项服务器或 DNS 服务器，以便攻击执行编译的计算机。