SQL Injection: Poor Validation

依賴 HTML、XML 和其他類型的編碼來驗證不可信賴的輸入，可能會讓攻擊者修改陳述式的意義或是執行任意 SQL 指令。

使用編碼函數 (例如 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 的攻擊。