運行用戶提供的SELECT查詢有哪些危險？

Question

如果我限制用戶的輸入SQL語句，以便它以SELECT開頭，那麼在這種情況下是否可以運行任何注入攻擊？我是否留下了不同的安全漏洞（除了訪問架構有權訪問的所有數據之外）？

編輯 如果我也禁用分號（;）會怎麼樣？

Answer 1

總之，是的。給出一個簡單的SQL注入攻擊選擇：

var sqlCommand = "SELECT * FROM Table1 WHERE Field = '" & fieldValue & "';"; 

可以通過使用替代變量fieldValue的值修改以下內容：

fieldValue = "'; DELETE FROM Table1 WHERE 0 = 0 OR '' <> '"; 

，當運行該腳本將導致兩個語句是創建和執行：

SELECT * FROM Table1 WHERE Field = ''; DELETE FROM Table1 WHERE 0 = 0 OR '' <> ''; 

這只是一個簡單的例子，任何數量的語句可以運行，插入，更新，刪除等...

要在您的編輯擴大有關改變fieldValue變量，像剝分號，是：

fieldValue = "' OR 1 = 1 OR '' <> '"; 

你最終會得到如下：

SELECT * FROM Table1 WHERE Field = '' OR 1 = 1 OR '' <> ''; 

其中，如果這是用戶表可能會冒着允許提升權限或以不正確的用戶身份登錄的風險。

Answer 2

是的。如果您允許您的用戶將SQL輸入到網站中（這是您談論SQL注入攻擊時的典型案例），那麼您正打開自己的攻擊之門。不管是限制單個字符還是限制它只以SELECT語句開始，SQL最終都有很多方法可以解析輸入（而且網絡有更多）來捕獲每個可能的惡意查詢阻止最可能的非惡意的。

始終解析您的輸入。理想情況下，使用框架或至少一組存儲過程（不會動態構建和執行查詢）來訪問數據庫。

告訴我們更多關於您嘗試解決的問題，我們可以提供更多幫助。編輯（發表評論）：如果你想爲你的支持人員創建一個內部工具，你需要創建一個具有基本搜索功能的工具。給用戶下拉選擇他們想要搜索的字段，並將輸入傳遞到存儲過程或框架中以最大限度地降低風險。如果您認爲您的支持人員可以編寫SQL，只需讓他們登錄數據庫 - 在Management Studio等數據庫訪問工具中限制用戶訪問「SELECT」語句比保護網站更容易。

Answer 3

是，SQL注入攻擊可以選擇啓動：

SELECT * FROM USERS; DROP TABLE USERS 

Answer 4

是，注入攻擊的仍然可以通常由攻擊者使用在SELECT語句上的「去哪兒」條款發生。即他們可能能夠使用它獲得完整的細節。

Answer 5

解析SQL並找出訪問權限仍然有風險。例如，如果某人通過了以下事情會怎麼樣？

"select * from table_1; drop table X;" 

您可以像某些用戶建議的那樣使用存儲過程並綁定輸入。

還要確保您用於連接您的應用程序/客戶端的數據庫用戶只有「SELECT」權限。我相信這比確保所有SQL只是選擇更有效。 （順便說一句，實施起來很棘手）。