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的重点，因此维护此方法没有意义。

添加代码段。第307行的报告点检测到SQL注入缺陷：

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

Answer 1

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

Veracode看到了三种不同的SQL代码案例：

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

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

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