SQL Injection

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

2. 資料用於動態地建立 SQL 查詢。
範例 1：以下程式碼動態建構並執行 SQL 查詢，該查詢是用來搜尋屬於使用者的發票。此查詢會將顯示的項目限制為與目前已驗證之使用者的名稱相同的使用者。

...
v_account = request->get_form_field( 'account' ).
v_reference = request->get_form_field( 'ref_key' ).

CONCATENATE `user = '` sy-uname `'` INTO cl_where.
IF v_account IS NOT INITIAL.
CONCATENATE cl_where ` AND account = ` v_account INTO cl_where SEPARATED BY SPACE.
ENDIF.
IF v_reference IS NOT INITIAL.
CONCATENATE cl_where "AND ref_key = `" v_reference "`" INTO cl_where.
ENDIF.

SELECT *
    FROM invoice_items
    INTO CORRESPONDING FIELDS OF TABLE itab_items
    WHERE (cl_where).
...

此程式碼要執行的查詢如下 (假設 v_account 和 v_reference 不是空白)：

        SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
        WHERE user = sy-uname
        AND account = <account>
        AND ref_key = <reference>.

但是，由於該查詢是由串聯固定基礎查詢字串和使用者輸入字串所動態建構而成，因此會成為 SQL injection 攻擊的目標。如果攻擊者為 v_reference 輸入字串 "abc` OR MANDT NE `+"，為 v_account 輸入字串「1000」，那麼查詢將會變更為：

                SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
        WHERE user = sy-uname
        AND account = 1000
        AND ref_key = `abc` OR MANDT NE `+`.

新增 OR MANDT NE `+` 條件會導致 WHERE 子句永遠評估為 true，因為用戶端欄位永遠不可能等於文字 +，所以此查詢邏輯上可等同於以下較簡化的查詢：

        SELECT * FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items.

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

範例 2：在此範例中，我們將考慮在程式中使用 ADBC API，以允許員工更新其地址。

        PARAMETERS: p_street TYPE string,
                    p_city TYPE string.

		Data: v_sql TYPE string,
			  stmt TYPE REF TO CL_SQL_STATEMENT.

v_sql = "UPDATE EMP_TABLE SET ".

"Update employee address. Build the update statement with changed details
IF street NE p_street.
CONCATENATE v_sql "STREET = `" p_street "`".
ENDIF.
IF city NE p_city.
CONCATENATE v_sql "CITY = `" p_city "`".
ENDIF.

l_upd      = stmt->execute_update( v_sql ).

如果感到不滿的員工輸入字串，例如為參數 p_street 輸入 "ABC` SALARY = `1000000"，則應用程式允許使用修訂的薪資更新資料庫！

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

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

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

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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



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

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

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var username:String = String(params["username"]);
        var itemName:String = String(params["itemName"]);
        var query:String = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName;
          
        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.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 的攻擊。

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

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

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...

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

	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 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

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

...
ctx.getAuthUserName(&userName); {
CString query = "SELECT * FROM items WHERE owner = '"
				 + userName + "' AND itemname = '"
				 + request.Lookup("item") + "'";
dbms.ExecuteSQL(query);
...

範例 2：或者，也可以使用下列程式碼利用 SQLite 取得相似的結果：

...
sprintf (sql, "SELECT * FROM items WHERE owner='%s' AND itemname='%s'", username, request.Lookup("item"));
printf("SQL to execute is: \n\t\t %s\n", sql);
rc = sqlite3_exec(db,sql, NULL,0, &err);
...

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

	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 表中的項目，而不考慮指定的擁有者為何。

範例 3：此範例會檢查不同的惡意值傳送到建立的查詢以及在 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]。所以，在此案例中，SQL 查詢中最後的一個單引號將會被作為註釋處理。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 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 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

2. 資料用於動態地建立 SQL 查詢。
範例 1：以下程式碼動態地建構並執行一個 SQL 查詢，該查詢是用來搜尋與所指定的名字相符的項目。此查詢將顯示的項目限制在，與目前被驗證的使用者的名稱相同的所有者。

...
ACCEPT USER.
ACCEPT ITM.
MOVE "SELECT * FROM items WHERE owner = '" TO QUERY1.
MOVE "' AND itemname = '" TO QUERY2.
MOVE "'" TO QUERY3.

STRING
  QUERY1, USER, QUERY2, ITM, QUERY3 DELIMITED BY SIZE
  INTO QUERY
END-STRING.
  
EXEC SQL
  EXECUTE IMMEDIATE :QUERY
END-EXEC.
...

以下為此程式碼將執行的查詢：

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

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itm 中輸入字串「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 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

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

...
<cfquery name="matchingItems" datasource="cfsnippets">
    SELECT * FROM items 
     WHERE owner='#Form.userName#'   
       AND itemId=#Form.ID#
</cfquery>
...

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

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemId = <ID>;

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

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

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

	SELECT * FROM items;

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

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

	SELECT * FROM items 
	WHERE owner = 'hacker'
	AND itemId = '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 = 'hacker'
	AND itemId = '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 的攻擊。

使用 Java J2EE PersistenceAPI 執行透過不可信賴來源的輸入來建立的動態 SQL 陳述式，可能會讓攻擊者修改指令的意義或是執行任意的 SQL 指令。

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

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



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

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

...
	final server = await HttpServer.bind('localhost', 18081);
    server.listen((request) async {
        final headers = request.headers;
        final userName = headers.value('userName');
        final itemName = headers.value('itemName');
        final query = "SELECT * FROM items WHERE owner = '"
            + userName! + "' AND itemname = '"
            + itemName! + "'";
        db.query(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';

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

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

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

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

透過來自不可信賴來源的輸入建構動態 SQL 陳述式可讓攻擊者修改陳述式的意義，或是執行任意的 SQL 指令。

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

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

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

  ...
  rawQuery := request.URL.Query()
  username := rawQuery.Get("userName")
  itemName := rawQuery.Get("itemName")
  query := "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";"

  db.Exec(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';

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

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

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

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

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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



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

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

	...
	var username = document.form.username.value;
	var itemName = document.form.itemName.value;
	var query = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";";
	db.transaction(function (tx) {
		tx.executeSql(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';

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

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

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

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

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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



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

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

	...
	$userName = $_SESSION['userName'];
	$itemName = $_POST['itemName'];
	$query = "SELECT * FROM items WHERE owner = '$userName' AND itemname = '$itemName';";
	$result = mysql_query($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';

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

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

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

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

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

2. 資料用於動態地建立 SQL 查詢。
範例 1：以下程式碼動態建立並執行了 SQL 查詢，該查詢是用來搜尋與所指定的名字相符的項目。此查詢將顯示的項目限制在，與目前被驗證的使用者的名稱相同的所有者。

procedure get_item (
     itm_cv IN OUT ItmCurTyp,
     usr in varchar2,
     itm in varchar2)
is
     open itm_cv for ' SELECT * FROM items WHERE ' ||
                   'owner = '''|| usr || '''' ||
                   ' AND itemname = ''' || itm || '''';
     end get_item;

以下為此程式碼將執行的查詢：

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

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果一個使用者名稱為 wiley 的攻擊者為 itm 輸入字串「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 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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



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

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

	...
	userName = req.field('userName')
	itemName = req.field('itemName')
	query = "SELECT * FROM items WHERE owner = ' " + userName +" ' AND itemname = ' " + itemName +"';"
	cursor.execute(query)
	result = cursor.fetchall()
	...

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

	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 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

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

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

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

...
  userName = getAuthenticatedUserName()
  itemName = params[:itemName]
  sqlQuery = "SELECT * FROM items WHERE owner = '#{userName}' AND itemname = '#{itemName}'"
  rs = conn.query(sqlQuery)
...

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

  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 表中的項目，而不考慮指定的擁有者為何。

由於 Ruby 不是靜態輸入，因此也支援在靜態輸入的語言中可能無法使用的插入 SQL 查詢的其他點。
範例 2：以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。

...
  id = params[:id]
  itemName = Mysql.escape_string(params[:itemName])
  sqlQuery = "SELECT * FROM items WHERE id = #{userName} AND itemname = '#{itemName}'"
  rs = conn.query(sqlQuery)
...

在此案例中，要執行的預期 SQL 查詢為：

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

您可以看到這次我們防止了在 itemName 內指定單引號的攻擊者，並且似乎遏止了 SQL injection 弱點。不過，由於 Ruby 不是靜態輸入的語言，因此，雖然 id 預期為某些變數的整數，但由於其是從使用者輸入指定的，因此也未必是數字。如果攻擊者可將 id 的值變更為 1 OR id!=1--，則由於沒有檢查 id 實際上是否為數字，SQL 查詢現在變為：

SELECT * FROM items WHERE id=1 OR id!=1-- AND itemname = 'anyValue';

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的指令，並視為註釋不予執行 [4]。鑒於此，現在只要執行包含下列內容的 SQL 查詢：

SELECT * FROM items WHERE id=1 OR id!=1;

我們現在只要選取表格中的全部內容，無論 id 的值是否等於 1，顯然該值等於表格內的全部內容。

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

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

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

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

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

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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



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

範例 1： 以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可搜尋符合指定名稱的使用者。 查詢僅會顯示項目所有者與提供作為路徑參數之使用者名稱相符的項目。

  def doSQLQuery(value:String) = Action.async { implicit request =>
    val result: Future[Seq[User]] = db.run {
      sql"select * from users where name = '#$value'".as[User]
    }
    ...
  }

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

	SELECT * FROM users 
	WHERE name = <userName>

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

	SELECT * FROM users 
    WHERE name = 'name' OR 'a'='a';

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

	SELECT * FROM users;

這種簡化的查詢會允許攻擊者略過下列要求：查詢必須僅傳回由指定使用者所擁有的使用者；查詢現在會回傳儲存在 users 表格中的所有項目，無論它們的指定使用者是誰。

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

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

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

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

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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

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

...
let queryStatementString = "SELECT * FROM items WHERE owner='\(username)' AND itemname='\(item)'"
var queryStatement: OpaquePointer? = nil
if sqlite3_prepare_v2(db, queryStatementString, -1, &queryStatement, nil) == SQLITE_OK {
    if sqlite3_step(queryStatement) == SQLITE_ROW {
    ...
    }
}
...

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

    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 表中的項目，而不考慮指定的擁有者為何。

範例 3：此範例會檢查不同的惡意值傳送到建立的查詢以及在 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]。所以，在此案例中，SQL 查詢中最後的一個單引號將會被作為註釋處理。在不允許以此方式使用註釋的資料庫中，攻擊者通常會使用類似 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 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

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

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



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

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

	...
	username = Session("username")
	itemName = Request.Form("itemName")
	strSQL = "SELECT * FROM items WHERE owner = '"& userName &"' AND itemname = '" & itemName &"'"
	objRecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
	...

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

	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 的攻擊。