问题的引出

说到SQL注入，我们常说不使用字符串拼接，使用带占位符的参数化查询可以防SQL注入，那么，在Android content provider中是否也一样呢？下面我们来看一段android contentprovider中的数据库查询代码示例：

public void showBooks(View view) {

String content = "";

Uri bookUri = BookProvider.BOOK_CONTENT_URI;

String _id = "3";

String name = "Android";

Cursor bookCursor = getContentResolver().query(bookUri, new String[]{"_id", "name"}, "_id=? and name=?",

new String[] {_id, name}, null, null);

if (bookCursor != null) {

while (bookCursor.moveToNext()) {

Book book = new Book();

book.bookId = bookCursor.getInt(0);

book.bookName = bookCursor.getString(1);

content += book.toString() + "\n";

Log.e(TAG, "query book: " + book.toString());

mTvShowBooks.setText(content);

}

bookCursor.close();

}

}

其中的查询语句用sql语句表示为：

select _id,name from book where _id= ? and name = ?

理论上，这条语句是不应该存在sql注入的。但是，当使用如下drozer命令对selection进行注入时，发现是存在SQL注入的：

run app.provider.query content://org.vivo.book.provider/book --projection "'"

我们在代码中已经对selection参数使用了带占位符的参数化查询了，怎么还存在SQL注入呢？

仔细查看上图报错信息发现SQL语句变成了“select * from book where ‘”，查询条件已经变成我们输入的“’”单引号了。所以我们猜想，这里的SQL注入其实跟web sql注入不太相同。这里是直接将用户输入替代了原来的SQL语句，而不是简单的替换某个查询变量。为了验证这个猜想，我们分析了drozer的源代码。Drozer在执行上述SQL注入命令时，会解析输入的相应参数，然后调用下图中的query函数进行查询操作。

为了验证前面的猜想，我们在代码中添加打印语句，打印projection、selection等参数信息，再执行drozer命令，发现查询语句确实被替换了。

run app.provider.query content://org.vivo.book.provider/book --selection "1=1"

run app.provider.query content://org.vivo.book.provider/book --projection "1=1"

所以，不管我们怎么实现查询，只要有权限读取contentprovider uri，就可以实现SQL注入。

run app.provider.query content://org.vivo.book.provider/book/ --projection "* FROM sqlite_master --;"

我们的sql查询语句的结构通常如下：

SELECT [projection] FROM [table] WHERE [select clause]

需要注意的是，这里不仅select clause存在SQL注入情况，projection也会存在注入。

ContentProvider允许用户任意指定他们想要检索的projection，外部应用程序可以通过请求任意projection从中查询数据，如：

'Bobby Tables was here'; DROP TABLE Students; --

* FROM sqlite_master; --

* FROM non_public_table_I_found_out_about_using_previous_query; --

这就意味着，如果ContentProvider的某个uri暴露了，并且没有对projection参数进行过滤就带入查询的话，你的整个数据库就会暴露在外。

在导出的 ContentProviders 中实现 query、update 和 delete 时，如果将未经处理的输入传递给 SQL 语句，就会容易受到 SQL 注入攻击。恶意应用可能会提供蓄意创建的输入，进而访问隐私数据或损坏数据库内容。您可以通过以下方式解决此问题：

如果受影响的 ContentProvider 无需供其他应用使用，请执行以下操作：

您可以在清单中修改受影响的 ContentProvider 的 标记，以便设置 android:exported="false"。这样可以阻止其他应用将 Intent 发送到受影响的 ContentProvider。

您还可以设置 android:permission 属性，将 permission 设为 android:protectionLevel="signature"，从而阻止其他开发者编写的应用将 Intent 发送到受影响的 ContentProvider。

如果受影响的 ContentProvider 需要供其他应用使用，请执行以下操作：

您可以通过结合使用严格模式和投影映射来防止 SQLiteDatabase.query 受到 SQL 注入攻击。严格模式可防止出现恶意选择子句，投影映射可防止出现恶意投影子句。您必须同时使用这两项功能来确保查询安全无虞。

代码示例：

private static HashMap values = new HashMap<>();

// 关联Uri和Uri_Code

static {

sUriMatcher.addURI(AUTHORITY, "book", BOOK_URI_CODE);

sUriMatcher.addURI(AUTHORITY, "user", USER_URI_CODE);

values.put("_id", "_id");

values.put("name", "name");

}

public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {

SQLiteQueryBuilder qb = new SQLiteQueryBuilder();

qb.setTables(getTableName(uri));

qb.setStrict(true);

switch (sUriMatcher.match(uri)) {

case BOOK_URI_CODE:

qb.setProjectionMap(values);

break;

default:

break;

}

Cursor cursor = qb.query(mDb,

projection,

selection,

selectionArgs,

null,

null,

sortOrder);

return cursor;

}

您可以通过以下方式来防止 SQLiteDatabase.update 和 SQLiteDatabase.delete 受到 SQL 注入攻击：使用以“?”作为可替换参数的选择子句，并使用一组单独的选择参数。不应使用不信任的输入构建选择子句。

参考文档：

https://support.google.com/faqs/answer/7668308

关于找一找教程网

本站文章仅代表作者观点，不代表本站立场，所有文章非营利性免费分享。

本站提供了软件编程、网站开发技术、服务器运维、人工智能等等IT技术文章，希望广大程序员努力学习，让我们用科技改变世界。

[关于Android contentprovider sql注入问题]http://www.zyiz.net/tech/detail-99678.html