SQL 命令中使用的特殊元素的不正确中和

Question

由 Content Provider 使用 CursorLoaders 管理的我的应用数据位于 SQLite 数据库中。 根据 Veracode 静态扫描报告，它很容易发生 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 的重点，所以维护这种方法没有意义。

添加代码 sn-p。在第 307 行报告检测到 SQL Injection 缺陷的点：

我应该如何对特殊字符进行输入验证？ 请帮忙，让我更好地理解它。

Answer 1

selectionArgs 参数中的值不需要转义，并且它们不得转义，因为转义字符最终会出现在数据库中。

Veracode 看到的 SQL 代码有三种不同的情况：

• 不能是用户输入的值（例如源代码中的字符串字面量）；
• 是用户输入的值（因为直接来自，例如，某个编辑框）；
• 可能是用户输入的值，因为该工具无法确定来源。

出于营销原因，付费工具往往会尽可能夸大问题数量。因此 Veracode 将第三种情况的所有实例都报告为问题。

在这种情况下，Veracode 不知道selection 来自哪里，所以它会抱怨。如果该值由您的程序构造并且从不包含任何用户输入（即，所有用户输入值都移动到? 参数），那么这是误报，您必须告诉 Veracode 闭嘴。