從文件加載時的SQL_INJECTION_JDBC Findbugs

Question

我有一個使用StatementLoader獲取的匿名過程，並將其傳遞給CallableStatement。 但是，FindBugs將其標識為容易受到SQL注入（SQL_INJECTION_JDBC）的攻擊。 如果我創建一個靜態方法以字符串形式返回過程，那就很好了。

有沒有一種方法可以使用語句加載器而不會彈出sql注入錯誤？

例：

StatementLoader stmt = StatementLoader.getLoader(MyClass.class, connection);    
try (final CallableStatement callable = connection.prepareCall(stmt.load("mySqlCode"))) {...

Answer 1

是的，如果您的編程僅從外部源加載SQL語句並執行該語句，則這是真正的SQL注入機會。 SQL語句在程序中應該是一個常量，在執行它時使用參數替換來提供值。 捕蟲器是正確的-您應該立即重寫此代碼。

Answer 2

我想澄清正是我的意思是通過“參數”，因為OP的最新注釋中使用這個詞，“消毒”。

SQL允許在SQL語句中使用“參數”（由不是文字字符串的問號表示），例如：

SELECT * FROM CUSTOMER WHERE CUSTOMER_ID = ?

每次執行該語句時，必須為每個參數提供一個值，通常以值數組的形式提供。 （當然，大多數實際的數據庫API都更友好，可以讓您方便地“命名”您的參數。）因此，參數絕不是SQL字符串的一部分 。

僅對SQL語句進行一次解析（“准備”），並且數據庫引擎知道每次執行該語句時都必須提供參數值。 查詢引擎將直接采用並使用這些參數值； 它不會重新評估SQL。 （順便說一下，這明顯更有效！）

您提供的二進制值按原樣使用。 您甚至不必將它們轉換為字符形式。 具體來說， 您無需 “消毒”它們 ！ 如果為INSERT語句中的某些字符類型列提供諸如FOO%20BAR的值，則會發現一個9字符的文字值插入到數據庫中： FOO-%-2-0-BAR 。 “這些就是您給我的9個字符，所以我就是這樣做的。”

（數據庫系統及其接口在處理諸如“日期”之類的數據類型方面有所不同。）