訊息中任何未經簽署的部分都有可能在接收者未察覺的情況下遭到攔截和修改。若沒有簽章，收件者將無法以加密的方式驗證訊息內容的來源。

下列用戶端組態要求 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，則會依賴傳輸安全性檢查訊息的完整性和保密性。如果一個服務將訊息傳遞至其他服務，則訊息會暴露在傳遞點之間最脆弱的傳輸機制中。WS-Security 可減少傳輸安全 dependency，並讓訊息本身即具備安全性。

Apache Axis 2 組態設定檔案中沒有 OutflowSecurity 參數，表示未啟用輸出訊息的安全性。

使用 PasswordText 類型的密碼時，可能表示實際的密碼以純文字傳送。WS-Security UsernameToken 設定檔說明 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，則會依賴傳輸安全性檢查訊息的完整性和保密性。如果一個服務將訊息傳遞至其他服務，則訊息會暴露在傳遞點之間最脆弱的傳輸機制中。WS-Security 可避免傳輸安全 dependency，並讓訊息本身即具備安全性。

當伺服器組態設定檔案的 axis.development.system 設為 true 時，系統的運作方式會如同在開發環境中一般。它會透過 SOAP 回應傳送堆疊追蹤，而這樣有可能洩露與系統或應用程式有關的資訊。

當 axis.disableServiceList 設定為 false，且 GET 在 servlet root 上執行時，Apache Axis 會回傳可用服務的清單。這份服務清單可能列出了不應公開存取的功能。

使用 PasswordText 類型的密碼時，可能表示實際的密碼以純文字傳送。WS-Security UsernameToken 設定檔說明 UsernameToken <Password> 標籤所傳送的文字，不受限於實際密碼。可以改用密碼衍生物。不過，開發人員通常會傳送實際密碼而不是密碼延伸。傳送未加密密碼或甚至雜湊密碼都可能將憑證暴露給網路資料攔截者。

使用 UsernameToken 的服務供應商可能會接受以純文字傳送的密碼。在未加密的通道上傳送純文字密碼，可能會使攻擊者攔截 SOAP 訊息以取得憑證。

範例 1：以下 Axis 服務供應商配置使用 UsernameToken：

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

使用 PasswordText 類型的密碼時，可能表示實際的密碼以純文字傳送。WS-Security UsernameToken 設定檔說明 UsernameToken <Password> 標籤所傳送的文字，不受限於實際密碼。可以改用密碼衍生物。不過，開發人員通常會傳送實際密碼而不是密碼延伸。傳送未加密密碼或甚至雜湊密碼都可能將憑證暴露給網路資料攔截者。

在未加密的通道上傳送純文字密碼或雜湊密碼，可能會使攻擊者攔截 SOAP 訊息以取得憑證。

範例 1：以下 Axis 用戶端配置使用 UsernameToken：

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

Bean 屬性名稱和值在填入任何 bean 之前皆需驗證。Bean 填寫功能允許開發人員設定 bean 屬性或巢狀屬性。攻擊者可利用此功能存取類似於 class.classLoader 的特別 bean 屬性，這些屬性允許攻擊者取代系統屬性，並可能執行任意程式碼。

範例：以下程式碼會設定使用者控制的 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 自動化 dependency 管理系統，使用者可為 dependency 指定版本狀態 (也稱為動態版本)，而非列出特定版本。如果攻擊者能夠危害 dependency 儲存庫，或欺騙 build system 從攻擊者控制的儲存庫下載 dependency，那麼 build system 只需下載動態修正說明符號，而該說明符號可能執行受危害的 dependency。除了安全性風險之外，動態修正還會為 Code Quality 帶來下列風險：動態修正使軟體的安全性和穩定性受控於第三方，即開發和發行軟體所使用的 dependency 的第三方。

在建置過程中，Ivy 會連接到儲存庫並企圖擷取與所列出狀態相符的 dependency。

Ivy 接受以下的動態修正說明符號：

- latest.integration：選擇 dependency 模組的最新修正。
- latest.[any status]：選擇至少處於指定狀態的 dependency 模組的最新修正。例如，latest.milestone 會選擇重要的修正版本，或是發行版本，而 latest.release 僅會選擇最新發行版本。
- 任何結尾為 + 的修正：選擇 dependency 模組的最新子修正。例如，如果 dependency 存在於 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 下載 dependency 的惡意版本。

Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

開發人員使用 <get> 工作，在 Ant 目標中指定外部 dependency，以擷取由相應的 URL 指定的 dependency。此方法與以下情形在功能上是相同的：開發人員證明每個外部 dependency 為軟體項目中附帶的人工項目，但卻是必要的，因為它可以在執行建置時自動擷取和合併 dependency。

範例：以下內容來自 Ant build.xml 組態設定檔案，顯示外部 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"/>

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

使用 Ivy 時，開發人員會指定 dependency 名稱和版本，而不是列出從中擷取 dependency 的明確 URL，Ivy 依靠其基本組態來識別要從中擷取 dependency 的伺服器。使用共同的元件使得開發人員節省了搜尋 dependency 位置的時間。

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

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

使用 Maven 時，開發人員會指定 dependency 名稱和版本，而不是列出從中擷取 dependency 的明確 URL，Maven 依靠其基本組態來識別要從中擷取 dependency 的伺服器。使用共同的元件使得開發人員節省了搜尋 dependency 位置的時間。

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

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

即使 Castor 在物件上建立鎖定，也無法阻止其他執行緒讀取或寫入該物件。跟預設共享模式比較起來，唯讀查詢的速度大約快了七倍。

範例 1：下列範例指定查詢模式為 SHARED，允許讀取與寫入權限。

results = query.execute(Database.SHARED);