在SQL命令中使用特殊元素的不當中和

由Content Provider使用CursorLoaders管理的我的應用程序數據位於SQLite數據庫中。根據Veracode靜態掃描報告，它傾向於SQL注入。在SQL命令中使用特殊元素的不當中和

但根據docs，

要避免此問題，使用使用選擇條款？作爲可替換參數和單獨的選擇參數數組。當你這樣做時，用戶輸入直接綁定到查詢上，而不是被解釋爲SQL語句的一部分。由於它不被視爲SQL，因此用戶輸入無法注入惡意SQL。

public Loader<Cursor> onCreateLoader(int id, Bundle b) { 
    return new CursorLoader(getActivity(), 
      NewsFeedTable.CONTENT_URI, 
      NewsFeedTable.PROJECTION, 
      "_id = ?", 
      new String[]{tid}, 
      null); 
}

，如上面的代碼，我在做類似的方式。此外，我在The Mobile Application Hacker's Book

如果這是不夠的措施來防止SQL注入讀一樣的，我怎麼消毒從特殊字符的SQL查詢？每個閱讀建議使用參數化的PreparedStatements。內容提供商是否不默認？

到SQLiteStatement另一種方法是，爲他們提供通過其使用字符串數組的參數化的語句使用查詢，插入，更新和刪除SQLiteDatabase方法。

，我發現這是一個解決方案：

但後來我從here閱讀文檔是

StringEscapeUtils.escapeSql 這是一個誤導性的方法，只處理最簡單的可能SQL的案例。由於SQL不是Lang的重點，所以維護這種方法沒有意義。

添加代碼片段。第307行報告點，SQL注入缺陷被檢測到：

我應該如何對特殊字符進行輸入驗證？請幫助，讓我更好地理解它。

來源

2016-12-29 Priya

價值觀selectionArgs參數不需要進行轉義，他們不得進行轉義，因爲轉義字符會在數據庫中結束。

有由根據Veracode看出SQL代碼三種不同的情況：

值即不能用戶輸入（諸如在源代碼字符串文字）;
值是用戶輸入（因爲直接來自例如，一些編輯框）;
值可能是用戶輸入，因爲該工具無法確定源。

由於營銷原因，付費工具往往會盡可能地誇大問題數量。因此，Veracode將第三種情況的所有實例報告爲問題。

在這種情況下，Veracode不知道selection來自哪裏，所以它抱怨。如果該值由您的程序構建，並且從不包含任何用戶輸入（即所有用戶輸入值都移至?參數），則這是誤報，您必須告訴Veracode關閉。

來源

2017-01-05 11:47:37

這是一個非常需要的解釋。謝謝:) @ CL，但是我不清楚_sanitizing data_實際上意味着什麼，或者當函數（DatabaseUtils.sqlEscapeString（））說_SQL轉義string_時它做了什麼。我試過搜索它，但無法得到一些真實的例子或者某種程度上沒有得到它。你能解釋給我嗎？ – Priya

在SQL命令中使用特殊元素的不當中和

回答

相關問題