SQL命令中使用的特殊元素的不正确中和 [英] Improper Neutralization of Special Elements used in an SQL Command

查看:187
本文介绍了SQL命令中使用的特殊元素的不正确中和的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

由内容提供者使用CursorLoaders管理的我的App数据在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);
}

如上面的代码所示,我正在以类似的方式进行操作. 我也在此处阅读了文档

StringEscapeUtils.escapeSql 这是一种令人误解的方法,仅处理可能的最简单的SQL案例.由于SQL不是Lang的重点,因此维护此方法没有任何意义.

添加代码段.在307行报告检测到SQL Injection 缺陷的点:

我应该如何对特殊字符进行输入验证? 请帮助,以使我更好地理解它.

解决方案

不需要对selectionArgs参数中的值进行转义,并且不得进行转义,因为转义字符最终会结束在数据库中.

Veracode可以看到三种不同的SQL代码情况:

    用户输入的
  • 不能为的值(例如源代码中的字符串文字);
  • 是用户输入的
  • (因为这些值直接来自例如某些编辑框);
  • 用户可能会输入
  • 可能是 的值,因为该工具无法确定来源.

出于市场营销的原因,付费工具往往会尽可能增加问题的数量.因此,Veracode将第三个案例的所有实例报告为问题.

在这种情况下,Veracode不知道selection的来源,因此会抱怨.如果该值是由您的程序构造的,并且从不包含任何用户输入(即,所有用户输入值都移至了?参数),则这是一个误报,您必须告诉Veracode关闭. >

My App data managed by the Content Provider using CursorLoaders is in SQLite database. According to Veracode Static Scan report , it is prone to SQL Injections.

But according to docs,

To avoid this problem, use a selection clause that uses ? as a replaceable parameter and a separate array of selection arguments. When you do this, the user input is bound directly to the query rather than being interpreted as part of an SQL statement. Because it's not treated as SQL, the user input can't inject malicious SQL.

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

As shown in above code, I am doing in similar way. Also I read same in The Mobile Application Hacker's Book

If this is not sufficient measure to prevent SQL injections, how do I sanitize the sql query from the special characters? Every read suggests using parameterized PreparedStatements. Is it not default with Content Providers?

An alternative to SQLiteStatement is to use the query, insert, update, and delete methods on SQLiteDatabase as they offer parameterized statements via their use of string arrays.

I found this as a solution :

But then I read docs from here that

StringEscapeUtils.escapeSql This was a misleading method, only handling the simplest of possible SQL cases. As SQL is not Lang's focus, it didn't make sense to maintain this method.

Adding the code snippet. Report points at Line 307 where SQL Injection flaw is detected:

How should I do input validation for the special characters? Please help, to make me understand it better.

解决方案

Values in selectionArgs parameters do not need to be escaped, and they must not be escaped because the escape characters would end up in the database.

There are three different cases of SQL code seen by Veracode:

  • values that cannot be user input (such as string literals in the source code);
  • values that are user input (because the come directly from, e.g., some edit box);
  • values that might be user input, because the tool cannot determine the source.

For marketing reasons, paid-for tools tend to inflate the problem numbers as much as possible. So Veracode reports all instances of the third case as problems.

In this case, Veracode does not know where selection comes from, so it complains. If that value is constructed by your program and never contains any user input (i.e., all user-input values are moved to ? parameters), then this is a false positive, and you must tell Veracode to shut up.

这篇关于SQL命令中使用的特殊元素的不正确中和的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆