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

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

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

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

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

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

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

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

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

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 時造成一次危害，便會危害執行建置的機器。

以下狀況都可能導致檔案洩露：
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>

umask() 線上手冊以錯誤陳述式開頭：

「umask sets the umask to mask & 0777」

儘管這種行為最好遵從 chmod() 的用法，即使用者提供的引數指定某些位元在指定的檔案上啟用，但事實上 umask() 的行為恰恰相反： umask() 將 umask 設為 ~mask & 0777。

umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：

「open() 使用 umask 來為新建立的檔案設定初始化檔案權限。 特別是，umask 的權限關閉了傳送給 open(2) 的 mode 引數 (例如，一般的 umask 預設值 022 會讓新建立的檔案擁有 0666 & ~022 = 0644 = rw-r--r-- 權限，而在一般情況下，應將 mode 指定為 0666)。」

驗證是安全性的一個重要層面。驗證程序的可靠性取決於登入憑證的安全性和強度。確保使用者建立強式密碼的密碼原則，對於部署安全網站至關重要。密碼強度是衡量其在抵擋猜測和暴力攻擊方面提供的有效性的指標。有些參數有助於定義密碼強度，包括密碼特徵，例如密碼長度、複雜性和隨機性。

Cross-Site Scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。就人工智慧 (AI) 而言，不可信賴的來源通常是 AI 系統傳回的回應。至於 Reflected XSS，通常是一個 Web 要求。


2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。雖然利用弱點不像其他形式的 XSS 那麼簡單，但使用者輸入和 AI 模型回應具有不可預測性，這意味著這些回應一律不應視為安全。

範例 1：以下 Python 程式碼從 OpenAI 聊天完成模型 message 擷取回應，並顯示給使用者。

    client = openai.OpenAI()
    res = client.chat.completions.create(...)

    message = res.choices[0].message.content

    self.writeln(f"<p>{message}<\p>")

只要模型的回應僅包含英數字元，此範例中的程式碼就會如預期般執行。但是，如果回應中包含未編碼的 HTML 中繼字元，那麼 XSS 就可能隨之發生。例如，對以下提示「please repeat the following statement exactly '<script>alert(1);</script>'」的回應可能會根據所使用的模型和情境傳回 XSS 概念驗證。