SQL Injection 錯誤會在以下情況中出現：

1. 資料從一個不可信賴的來源進入程式。



2. 此資料將用來動態建構 HQL 查詢。

範例 1：以下程式碼會動態構建並執行一個 HQL 查詢，該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。

    ...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String query = "FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	List items = sess.createQuery(query).list();
	...

此查詢欲執行以下程式碼：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name' OR 'a'='a」，那麼查詢將變成以下內容：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

	SELECT * FROM items;

由於查詢必須只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'; DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 Example 1 中的方法。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，實作拒絕清單總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動去除在 SQL 查詢中特殊字元的輸入有一定的幫助，但無法完全保護您的應用程式免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 SQL injection 攻擊，但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳送到參數的指令類型。但是，雖然有許多的限制方法，仍有許多危險的指令可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分盜取情況，但無法保護您的應用程式免於 SQL Injection 攻擊。

SQL Injection 錯誤會在以下情況中出現：

1.資料從一個不可信賴的來源進入程式。

2.資料用來動態建構 SQL 查詢。



iBatis Data Map 可讓您指定 SQL 陳述式中的動態參數，並以使用 # 字元來做為典型的定義方式，如下所示：

    <select id="getItems" parameterClass="MyClass" resultClass="items">
        SELECT * FROM items WHERE owner = #userName#
    </select>

變數名稱周圍的 # 字元表示 iBatis 將使用 userName 變數建立參數化查詢。不過，iBatis 也可讓您使用 $ 字元，將變數直接串連至 SQL 陳述式，製造執行 SQL injection 的機會。

範例 1：以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可用來搜尋符合指定名字的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。

    <select id="getItems" parameterClass="MyClass" resultClass="items">
        SELECT * FROM items WHERE owner = #userName# AND itemname = '$itemName$'
    </select>

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串 name' OR 'a'='a，那麼查詢將變成以下內容：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

	SELECT * FROM items;

由於查詢必須只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'; DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開陳述式的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，一般攻擊者仍然可以使用類似 Example 1 中所示的訣竅進行攻擊。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，對於實作拒絕清單方法，總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的欄位當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動在 SQL 查詢中避開特殊字元的輸入有一定作用，但無法完全保護您的應用程式免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然預存程序可防止某些類型的 SQL Injection 攻擊，但是對於大多數的攻擊還是無能為力。預存程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳遞到參數的陳述式類型。但是，雖然有許多的限制方法，仍有許多危險的陳述式可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分攻擊，但是並不能完全協助您的應用系統抵禦 SQL injection 的攻擊。

SQL Injection 錯誤會在以下情況中出現：

1. 資料從一個不可信賴的來源進入程式。



2. 資料用來動態建構 SQL 或 JDOQL 查詢。

範例 1：以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。

...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String sql = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	Query query = pm.newQuery(Query.SQL, sql);
	query.setClass(Person.class);
	List people = (List)query.execute();
	...

此查詢欲執行以下程式碼：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name' OR 'a'='a」，那麼查詢將變成以下內容：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

	SELECT * FROM items;

由於查詢必須只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'; DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 Example 1 中的方法。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，實作拒絕清單總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動去除在 SQL 查詢中特殊字元的輸入有一定的幫助，但無法完全保護您的應用程式免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 SQL injection 攻擊，但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳送到參數的指令類型。但是，雖然有許多的限制方法，仍有許多危險的指令可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分盜取情況，但無法保護您的應用程式免於 SQL Injection 攻擊。

下列情況下會發生與 LINQ 有關的注入錯誤：

1. 資料從一個不可信賴的來源進入程式。

2. 此資料將用來動態建構查詢。
範例 1：以下程式碼動態地建構並執行 LINQ 查詢，以搜尋符合指定名稱的項目。查詢僅會顯示 owner 與目前已驗證使用者名稱相符的項目。

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

var items = dataContext.ExecuteCommand<Item>(query);
...

此查詢欲執行以下程式碼：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name' OR 'a'='a」，那麼查詢將變成以下內容：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

	SELECT * FROM items;

由於查詢必須只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'); DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 Example 1 中的方法。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 LINQ injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 LINQ 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，對於實作拒絕清單方法，總是存在一些漏洞，所以無法有效避免 LINQ injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動去除在 LINQ 查詢中特殊字元的輸入有一定的幫助，但無法完全保護您的應用程式免於 LINQ Injection 攻擊。

另外一個處理 LINQ Injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 LINQ Injection 攻擊，但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 LINQ Injection 攻擊的方式是，限制可以傳送到參數的指令類型。但是，雖然有許多的限制方法，仍有許多危險的指令可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分攻擊情況，但無法保護您的應用程式免於 LINQ Injection 攻擊。

SQL Injection 錯誤會在以下情況中出現：

1.資料從一個不可信賴的來源進入程式。

2.資料用來動態建構 SQL 查詢。



MyBatis Mapper XML 檔案可讓您指定 SQL 陳述式中的動態參數，並使用 # 字元來進行典型定義，如下所示：

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
    </select>

用括號括住變數名稱的 # 字元表示 MyBatis 將使用 userName 變數建立參數化查詢。不過，MyBatis 也可讓您使用 $ 字元，將變數直接串連至 SQL 陳述式，製造執行 SQL injection 的機會。

範例 1：以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可用來搜尋符合指定名字的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
        AND itemname = ${itemName}
    </select>

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串 name' OR 'a'='a，那麼查詢將變成以下內容：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name' OR 'a'='a';

加上 OR 'a'='a' 條件會使 WHERE 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

    SELECT * FROM items;

由於查詢理應只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'; DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name';

    DELETE FROM items;

    --'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開陳述式的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，一般攻擊者仍然可以使用類似 Example 1 中所示的訣竅進行攻擊。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name';

    DELETE FROM items;

    SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，對於實作拒絕清單方法，總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的欄位當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動逸出在 SQL 查詢中字元的輸入有一定的幫助，但無法保證應用程式能免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然預存程序可防止某些類型的 SQL Injection 攻擊，但是對於大多數的攻擊還是無能為力。預存程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳遞到參數的陳述式類型。但是，雖然有許多的限制方法，仍有許多危險的陳述式可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分攻擊，但是並不能完全協助您的應用系統抵禦 SQL injection 的攻擊。

SQL Injection 錯誤會在以下情況中出現：

1. 資料從一個不可信賴的來源進入程式。

2. 資料用來動態建構 SQL 查詢。
範例 1：以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示 owner 與目前已驗證使用者名稱相符的項目。

...
	string userName = ctx.GetAuthenticatedUserName();
	string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";
	List items = sess.CreateSQLQuery(query).List();
	...

此查詢欲執行以下程式碼：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 ItemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 ItemName 中輸入字串「name' OR 'a'='a」，那麼查詢將變成以下內容：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

	SELECT * FROM items;

由於查詢必須只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 ItemName 中輸入字串「name'; DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 Example 1 中的方法。如果攻擊者輸入「name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，實作拒絕清單總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動去除在 SQL 查詢中特殊字元的輸入有一定的幫助，但無法完全保護您的應用程式免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 SQL injection 攻擊，但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳送到參數的指令類型。但是，雖然有許多的限制方法，仍有許多危險的指令可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分盜取情況，但無法保護您的應用程式免於 SQL Injection 攻擊。

SQL Injection：PartiQL 問題會在以下情況中發生：

1.資料從一個不可信賴的來源進入程式。

2.資料用來動態建構 PartiQL 查詢。
範例 1：以下程式碼動態地建構並執行了一個 PartiQL 查詢，該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示 owner 與目前已驗證使用者名稱相符的項目。

...
String userName = identity.getUser();
String itemName = apiGatewayProxyRequest.getQueryStringParameters('item');
String statement = String.format("SELECT * FROM items WHERE owner = '%s' AND itemname = '%s'", userName, itemName);
ExecuteStatementRequest executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.setStatement(statement);
ExecuteStatementResponse executeStatementResponse = dynamoDBClient.executeStatement(executeStatementRequest);
return displayResults(executeStatementResponse.items());
...

此查詢欲執行以下程式碼：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串 name' OR 'a'='a，那麼查詢將變成以下內容：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：
避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，對於實作拒絕清單方法，總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的欄位當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

在 PartiQL 查詢中手動避開輸入特殊字元有一定作用，但無法完全保護您的應用程式免於 PartiQL Injection 攻擊。

SQL Injection 錯誤會在以下情況中出現：

1. 資料從一個不可信賴的來源進入程式。

在此案例中，Fortify Static Code Analyzer 無法判斷資料來源是否可信賴。

2. 資料用來動態建構 SQL 查詢。

範例 1：以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。

...
        String userName = ctx.getAuthenticatedUserName();
        String itemName = request.getParameter("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        ResultSet rs = stmt.execute(query);
...

此查詢欲執行以下程式碼：

        SELECT * FROM items
        WHERE owner = <userName>
        AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name' OR 'a'='a」，那麼查詢將變成以下內容：

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

        SELECT * FROM items;

由於查詢必須只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'; DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        --'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 Example 1 中的方法。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        SELECT * FROM items WHERE 'a'='a';

有人認為在行動環境中，典型的 Web 應用程式弱點 (例如 SQL Injection) 不會產生影響，因為使用者為何會攻擊自己呢？但是請謹記，行動平台的本質是從多種來源下載，並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高，這必然會擴大行動應用程式的受攻擊面，將程序之間的通訊包括在內。

範例 3：以下程式碼改寫 Example 1 以適用於 Android 平台。

...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，實作拒絕清單總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動去除在 SQL 查詢中特殊字元的輸入有一定的幫助，但無法完全保護您的應用程式免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 SQL injection 攻擊，但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳送到參數的指令類型。但是，雖然有許多的限制方法，仍有許多危險的指令可以傳入儲存的程序中。所以再次強調，儲存過程在某些情況下可以避免這種攻擊，但是並不能完全保護您的應用系統抵禦 SQL injection 的攻擊。

使用編碼函數 (例如 mysql_real_escape_string()) 可阻止部分，但不是所有 SQL injection 弱點。依賴此類編碼函數等同於使用安全性較差的拒絕清單來防止 SQL injection，可能會讓攻擊者修改陳述式的意義或是執行任意 SQL 指令。由於並非隨時都可以靜態確定輸入將在動態解譯程式碼指定段落中的何處顯示，Fortify Secure Coding Rulepacks 可能會將已驗證的動態 SQL 資料呈現為「SQL Injection: Poor Validation」問題，即便驗證足以阻止當前內容中的 SQL Injection 也是如此。

SQL Injection 錯誤會在以下情況中出現：

1. 資料從一個不可信賴的來源進入程式。



2. 資料用來動態建構 SQL 查詢。

範例 1： 以下範例示範資料庫的配置如何修改 mysqli_real_escape_string() 的行為。 SQL 模式設為「NO_BACKSLASH_ESCAPES」時，反斜線字元會被視為正常字元，而不是逸出字元[5]。 由於 mysqli_real_escape_string() 將此納入考量，所以以下查詢容易受到 SQL injection 攻擊，究其原因，是資料庫配置導致 " 不再逸出為 \"。

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

如果攻擊者將 password 欄位留白並針對 userName 輸入 " OR 1=1;-- ，則引號不會逸出並產生如下查詢：

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

由於 OR 1=1 會使 where 子句的評估永遠為 True，且雙連字符號會使陳述式的其餘部分被視為註解，查詢便會從邏輯上等同於以下大為簡化的查詢：

  SELECT * FROM users;

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，實作拒絕清單總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動在 SQL 查詢中避開特殊字元的輸入有一定作用，但無法完全保護您的應用程式免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。 雖然儲存的程序可避免某些類型的 SQL injection 攻擊，但是對於大多數的攻擊還是無能為力。 儲存的程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳送到參數的陳述式類型。 但是，雖然有許多的限制方法，仍有許多危險的陳述式可以傳入儲存的程序中。 所以再次強調，儲存的程序可以避免部分攻擊，但是並不能完全協助您的應用系統抵禦 SQL injection 的攻擊。

與 SubSonic 有關的 SQL 注入錯誤會在以下情況下出現：

1. 資料從一個不可信賴的來源進入程式。

2. 此資料將用來動態建構查詢。
範例 1：以下程式碼動態地建構並執行了一個 SubSonic 查詢，該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示 owner 與目前已驗證使用者名稱相符的項目。

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

IDataReader responseReader = new InlineQuery().ExecuteReader(query);
...

此查詢欲執行以下程式碼：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name' OR 'a'='a」，那麼查詢將變成以下內容：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

	SELECT * FROM items;

由於查詢必須只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'); DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 Example 1 中的方法。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SubSonic injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SubSonic 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，對於實作拒絕清單方法，總是存在一些漏洞，所以無法有效避免 SubSonic SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動去除在 SubSonic 查詢中特殊字元的輸入有一定的幫助，但無法完全保護您的應用程式免於 SubSonic SQL Injection 攻擊。

另外一個處理 SubSonic Injection 攻擊的最常建議的方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 SubSonic Injection 攻擊，但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 SubSonic SQL injection 攻擊的方式是，限制可以傳送到參數的指令類型。但是，雖然有許多的限制方法，仍有許多危險的指令可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分攻擊情況，但無法保護您的應用程式免於 SubSonic Injection 攻擊。

String Termination Error 會在以下情況發生：

1.資料藉由某函數進入程式，而此函數沒有以 Null 終端子做為輸出的結束。

2.傳送到某函數的資料需要以 Null 終端子做為其輸入的結束。
範例 1：以下程式碼從 cfgfile 中讀取，並使用 strcpy() 將輸入內容複製到 inputbuf 中。此程式碼錯誤地假設 inputbuf 將永遠包含一個 Null 終端子。

#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null-terminate
strcpy(pathbuf,inputbuf); //requires null-terminated input
...

如果從 cfgfile 讀取的資料按預期在磁碟上以 Null 結束，則 Example 1 中的程式碼所執行的操作是準確無誤的。但是如果攻擊者能夠修改輸入的資訊，以使其不包含預期的 null 字元，那麼呼叫 strcpy() 將在記憶體中連續地進行複製，直到遇到任意的 null 字元，複製才會終止。這就可能會導致目標 Buffer Overflow，而且，如果攻擊者可能控制緊跟 inputbuf 的記憶體內容，則應用程式就可能受到 Buffer Overflow 攻擊。

範例 2：在以下程式碼中，readlink() 擴展了儲存在緩衝區 path 上的符號連結的名稱，使緩衝區 buf 包含符號連結所參照之檔案的絕對路徑。而最終長度值將由 strlen() 來計算。

...
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(buf);
...

Example 2 中的程式碼所執行的操作將會出錯，這是因為藉由 readlink() 讀入 buf 的值將不會以 Null 結束。在測試過程中，類似於這樣的弱點可能不會被捕捉到，因為 buf 中未使用的內容或是對這些內容進行即時跟蹤的記憶體可能都是 null，因此使得 strlen() 看上去似乎執行了正確的操作。然而在一般情況下，strlen() 將持續橫越記憶體，直到在堆疊中遇到任意的 null 字元才會終止，這就會使 length 的值遠遠大於實際 buf 的大小，進而在隨後的使用過程中可能會造成 Buffer Overflow。

範例 3：以下程式碼使用 snprintf() 複製使用者輸入字串，然後將其放入多個輸出字串中。儘管提供了額外的護欄，但與 sprintf() 相比，特別是最大輸出尺寸的規格，當指定的輸出大小大於預期輸入時，snprintf() 函數仍然容易受到字串終止錯誤的影響。字串終止錯誤可能會導致下游問題，例如記憶體洩漏或緩衝區溢位。

...
char no_null_term[5] = getUserInput();

char output_1[20];
snprintf(output_1, 20, "%s", no_null_term);

char output_2[20];
snprintf(output_2, 20, "%s", no_null_term);


printf("%s\n", output_1);
printf("%s\n", output_2);
...

Example 3 中的程式碼說明了記憶體洩漏。當 output_2 以 no_null_term 填入時，snprintf() 必須從 no_null_term 的位置讀取直到遇到 Null 字元或達到指定的大小限制為止。由於 no_null_term 中沒有終止，因此 snprintf 會繼續讀入 output_1 的資料，最終到達第一次呼叫 snprintf() 所提供的 Null 終止字元。記憶體洩漏的情況透過 output_2 的 printf() 得到印證，其中包含兩次 no_null_term 的字元順序。

一般來說，字串即代表記憶體中包含資料的某個區域，以 null 字元做為結束。以前的字串處理方法通常就是依賴此 null 字元來決定字串的長度。如果將不包含 Null 終端子的緩衝區資訊傳送給這樣一個函數，此函數讀取的內容將不只是這個緩衝區資訊。

惡意使用者通常會對應用程式注入預期外長度的資料或者是其他內容，達到利用這類弱點的目的。為了達到這個目的，他們可能會直接向程式輸入惡意的資訊，或是間接修改應用程式的資源，如組態設定檔案等。如果攻擊者能夠使應用程式讀取超出緩衝區邊界的資訊，那麼他就可以利用 Buffer overflow，在系統中注入或是執行任何程式碼。

一個或多個 Action Field 沒有對應的驗證定義項目。每個欄位應有參照 ActionClass-validation.xml 的明確驗證程序。

當開發人員移除或重新命名操作表單對應後，很容易忘記去更新驗證邏輯。缺少驗證器定義項目是驗證邏輯未受到適當維護的其中一種跡象。

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因損壞記憶體而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界線檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

ActionClass-validation.xml 中有多個欄位驗證器定義使用相同名稱。相同名稱的重複驗證定義，會導致運作方式不正常。

範例 1：以下項目顯示兩個重複的欄位驗證器定義。

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

在這個 Struts2 Action 定義中發現一個以上的 ActionClass-validation.xml 檔案。對每個在 ActionClass 表單中定義的 Struts2 Action 而言，Struts2 會就必要的驗證限制，搜尋相對應的 ActionClass-validation.xml。單一 Action 包含部署在內若給定多個驗證定義，可能會導致非預期的結果。

如果兩個驗證表單具有相同的名稱，Struts Validator 會任意選擇一個表單來進行輸入驗證，而放棄另外一個。這可能不是程式設計師所期望的。而且，這表示沒有維護驗證邏輯，並表示可能存在其他未察覺的驗證錯誤。

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因損壞記憶體而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界線檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

在 validators.xml 發現超過一個驗證器參照。多個相同名稱的驗證定義，會導致運作方式不正常。

如果兩個類別定義為相同的名稱，Struts Validator 會任意選擇一個表單來進行輸入驗證，而放棄另外一個。這可能不是程式設計師所期望的。而且，這表示沒有維護驗證邏輯，並表示可能存在其他未察覺的驗證錯誤。

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

Struts2 的自訂驗證器都必須先定義於 validators.xml 中，才能用於動作驗證器定義。若有驗證器定義遺失，表示驗證方式不是最新的。

範例 1：validators.xml 中找不到下列動作驗證器。

<validators>
    <validator name="required" class="com.opensymphony.xwork2.validator.validators.RequiredFieldValidator"/>
</validators>

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

在 J2EE 應用程式中，未經檢查的輸入是弱點產生的主因。未經檢查的輸入資料會導致許多弱點的產生，包括 Cross-Site Scripting、Process Control 和 SQL injection。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

為了避免此類攻擊，應在應用程式處理輸入資料之前使用 Struts Validation 框架來檢查所有程式的輸入資料。使用 Fortify Static Code Analyzer 來確保 Struts Validator 的配置不存在任何弱點。

驗證器的範例用法包括進行檢查並確保：

- 在電話號碼欄位中只包含電話號碼的有效字元

- Boolean 值只有「T」或者「F」

- 未限定格式的字串必須有合理的長度，並且由有效的字元組成

找到一個 Struts2 Validation 檔案但沒有相符的 Struts2 Action。對每個 ActionClass 而言，Struts2 會搜尋相對應的 ActionClass-validation.xml 中必要的驗證限制。在此案例中，在 ActionClass-validation.xml 表單中找到一個驗證檔案，但是 ActionClass 不符合 Struts2 組態設定檔案中定義的 Action。

當開發人員移除或重新命名操作表單對應後，很容易忘記去更新驗證邏輯。存在 Unused Validation Form，是驗證邏輯未受到適當維護的一個跡象。

Struts2 Validator 定義參照不存在的動作欄位。

當開發人員移除或重新命名操作表單對應後，很容易忘記去更新驗證邏輯。存在落單驗證器定義，是驗證邏輯未受到適當維護的一個跡象。

如果兩個驗證表單具有相同的名稱，Struts Validator 會任意選擇一個表單來進行輸入驗證，而放棄另外一個。這可能不是程式設計師所期望的。而且，這表示沒有維護驗證邏輯，並表示可能存在其他未察覺的驗證錯誤。

範例 1：具有相同名稱的兩個驗證表單。

<form-validation>
    <formset>
        <form name="ProjectForm">
        ...
        </form>
        <form name="ProjectForm">
        ...
        </form>
    </formset>
</form-validation>

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。