無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

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。

範例 1：以下內容來自 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 時造成一次危害，便會危害執行建置的機器。

以下狀況都可能導致檔案洩露：
1. 資料從一個不可信賴的來源進入程式。


2. 此資料將用於動態地建構路徑。

範例 1：以下程式碼採用不可信賴的資料，並使用該資料來建立在伺服器端轉送中使用的路徑。

...
String returnURL = request.getParameter("returnURL");
	RequestDispatcher rd = request.getRequestDispatcher(returnURL);
	rd.forward();
...

範例 2：以下程式碼採用不可信賴的資料，並使用該資料來建立在伺服器端轉送中使用的路徑。

...
	<% String returnURL = request.getParameter("returnURL"); %>
	<jsp:include page="<%=returnURL%>" />
	...

如果攻擊者所提供 URL 的要求參數符合敏感檔案位置，他們也會能夠檢視該檔案。例如，"http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" 會讓他們能夠檢視應用程式的 applicationContext.xml。
攻擊者在擁有 applicationContext.xml 之後，便可找到並下載 applicationContext.xml 中所參照的配置檔案，甚至也可能下載類別或 jar 檔案。這讓攻擊者能夠取得應用程式的相關敏感資訊，並使其成為其他類型攻擊的目標。

以下狀況都可能導致檔案洩露：
1. 資料從一個不可信賴的來源進入程式。


2. 此資料將用於動態地建構路徑。

範例 1：以下程式碼採用不可信賴的資料，並使用該資料來建立在伺服器端轉送中使用的路徑。

...
	String returnURL = request.getParameter("returnURL");
	return new ModelAndView(returnURL);
	...

如果攻擊者所提供 URL 的要求參數符合敏感檔案位置，他們也會能夠檢視該檔案。例如，"http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" 會讓他們能夠檢視應用程式的 applicationContext.xml。
攻擊者在擁有 applicationContext.xml 之後，便可找到並下載 applicationContext.xml 中所參照的配置檔案，甚至也可能下載類別或 jar 檔案。這讓攻擊者能夠取得應用程式的相關敏感資訊，並使其成為其他類型攻擊的目標。

在 Spring Webflow 中，會使用檢視解析程式來將檢視名稱翻譯為實際的轉譯技術。通常，檢視解析程式都會限制使用字首與字尾之檔案的類型及位置。不過，使用要求參數來指定檢視名稱卻能規避這項機制。
範例 1：下列 Spring Webflow 組態使用要求參數來指定檢視名稱。

<webflow:end-state id="finalStep" view="${requestParameters.url}"/>
<webflow:view-state id="showView" view="${requestParameters.test}">

預設的 Spring Webflow 檢視解析程式原本只允許解析 "/WEB-INF/views/" 中的 jsp 檔案。

<bean class="org.springframework.web.servlet.view.
               InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/" />
    <property name="suffix" value=".jsp" />
</bean>

攻擊者卻可使用下列 URL 來檢視 applicationContext.xml 檔案："http://www.yourcorp.com/webApp/logic?url=../applicationContext.xml;x="
InternalResourceViewResolver 會採用其所設定的字首，然後串連檢視屬性中傳送的值，並於最後加上字尾。
產生的相對 URL (即 "/WEB-INF/views/../applicationContext.xml;x=.jsp") 將傳遞至伺服器端的要求發送器。分號可讓攻擊者將 ".jsp" 字尾轉換為路徑參數。這種攻擊可以用於揭露 Web 應用程式根目錄下的任何檔案。

以下狀況都可能導致檔案洩露：
1. 資料從一個不可信賴的來源進入程式。


2. 此資料將用於動態地建構路徑。

範例 1：以下程式碼採用不可信賴的資料，並使用該資料來建立在伺服器端轉送中使用的路徑。

...
	String returnURL = request.getParameter("returnURL");
	return new ActionForward(returnURL);
	...

如果攻擊者所提供 URL 的要求參數符合敏感檔案位置，他們也會能夠檢視該檔案。例如，"http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" 會讓他們能夠檢視應用程式的 applicationContext.xml。
攻擊者在擁有 applicationContext.xml 之後，便可找到並下載 applicationContext.xml 中所參照的配置檔案，甚至也可能下載類別或 jar 檔案。這會讓攻擊者能夠取得應用程式的相關敏感資訊，並使其成為其他類型攻擊的目標。

程式會參照未唯一識別的使用者定義類別。.NET 載入這種未安全識別的類別時，CLR 類型載入器會以指定的順序在下列位置中搜尋類別：

- 如果該類型的組件是已知組件，載入器便會搜尋組態設定檔案的重新導向位置、GAC、目前使用組態資訊的組件，以及應用程式基本目錄。

- 如果組件未知，則載入器會搜尋目前的組件、mscorlib，以及由 TypeResolve 事件處理常式所回傳的位置。

此 CLR 搜尋順序可以使用陷阱來修改，例如 Type Forwarding 機制和 AppDomain.TypeResolve 事件。

如果攻擊者透過建立含有相同名稱的替代類別，並將該類別放置在 CLR 會先載入的替代位置，來攻擊 CLR 搜尋順序，CLR 便會無意間執行攻擊者提供的程式碼。

範例 1：以下 WCF 組態設定檔案的 <behaviorExtensions/> 元素會指示 WCF 將自訂行為類別加入特定的 WCF 延伸中。

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="myBehavior" type="MyBehavior" />
       </behaviorExtensions>
    </extensions>
</system.serviceModel>

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。