在刪除API函數中避免SQL注入

我試圖構建一個android應用程序，並且該應用程序的一部分涉及需要同步到服務器的數據庫上的CRUD選項。我對CRU位進行了排序，但我試圖以避免SQL注入的方式執行刪除操作。在刪除API函數中避免SQL注入

我已經用了我所有的其他查詢預處理語句，但我想知道的是沒有下面的方法是否安全：

我已經定義上刪除查詢是有效的表的清單，以及並在這些表中列出可以出現在tableKey字段中的主鍵。然後，我使用tableKeyValue字段中提供的值使用準備好的語句，並將操作限制爲針對單個用戶的ID進行操作的操作。

從SQL注入的角度來看，這種方法是安全的嗎，還是應該爲每個要刪除的表設置特定的API端點，並且只是通過一個傳統準備語句中使用的Id值？

for ($i = 0; $i < count($deleteArray); $i++) { 
     if (in_array($deleteArray[$i]['tableName'], $this->TABLE_ARRAY) && in_array($deleteArray[$i]['tableKey'], $this->KEY_ARRAY)) { 
      $deleteStmtSQL = "DELETE FROM ".$deleteArray[$i]['tableName']." WHERE ".$deleteArray[$i]['tableKey']." = ? AND userId = ?"; 
      $deleteStmtSth = $this->dbh->prepare($deleteStmtSQL); 
      $deleteStmtData = array(
       $deleteArray[$i]['tableKeyValue'], 
       $userId 
      ); 
      $deleteStmtSth->execute($deleteStmtData); 
      $j++; 
     } 
    }

來源

2014-10-09 Jonathan Windridge

我會爭辯說，除非該函數能夠在內部保證'$ deleteArray'總是包含安全值，否則這些值作爲可執行SQL代碼的任何隱式信任都是潛在的SQL注入漏洞。 – David 2014-10-09 19:12:33

@David這就是爲什麼我要求澄清我想 - 如果我檢查'$ deleteArray [$ i] ['tableName']'和'$ deleteArray [$ i] ['tableKey']'是部分預先批准的，已關閉的值列表，那麼是否仍然存在SQL注入風險？ – 2014-10-09 19:41:19

這肯定會減輕風險，但在那一點上我想知道它是否引入了比爲不同表格創建單獨操作更復雜的問題。有那麼多桌子，它是禁止的？也許一個對象可以公開許多特定於表的方法（使用硬編碼的值），並將其發佈到執行發佈代碼的私有方法中？這樣，*函數*不保證安全性，*對象*是。只要用於構建該查詢的變量範圍很小並且一目瞭然便於維護，它就應該沒問題。 – David 2014-10-09 19:44:26

基於從LXG和大衛的意見，這是解決方案，我想出了：

我通過在tableName，tableKey和tableKeyValue到一個通用的方法，其中確認後， tableName和tableKey匹配起來，各遍的tableKeyValue到私有方法

（例如deleteFromTableXByKey($tableKeyValue)然後使用準備語句，只服用密鑰作爲一個值。

如果傳遞給tableName和tableKey的父函數的值與預定義列表不匹配，則它們將通過而不會進一步交互，並返回錯誤消息。

來源

2014-10-18 22:00:47

在刪除API函數中避免SQL注入

回答

相關問題