最近一直很忙碌，即将进入本系列文章基础篇的最后几个篇章，本文主要讲述Android中存在的常见的SQL注入漏洞的方式，以及如何快速的挖掘SQL注入漏洞。

本文结构如下：

第二节讲述SQL注入的基本原理

第三节讲述常见的SQL注入漏洞并复现

第四节讲述Content Provider上的sql注入漏洞

第五节讲述DownProvider 上的sql注入漏洞

通过实施 SQL 注入，攻击者可以获得对应用程序或数据库的完全访问权限，从而可以不负责任地删除或更改重要数据。未正确验证用户输入的应用程序使它们容易受到 SQL 注入的攻击。 SQL 注入攻击 (SQLIA) 发生在攻击者能够通过操纵用户输入数据将一系列恶意 SQL 语句插入“查询”以供后端数据库执行时。使用这种类型的威胁，应用程序可以很容易地被黑客入侵并被攻击者窃取机密数据。

SQL攻击的原理图如下所示：

上图中攻击者将 SQL 语句添加到应用程序表单输入框中，以访问资源或更改存储在数据库中的数据。应用程序中缺少输入验证会导致攻击者成功。在 SQL 注入攻击中，攻击者通过应用程序注入字符串输入，从而改变或操纵 SQL 语句以使攻击者受益。

要学习SQL注入在Android上的使用，首先需要了解SQL注入的种类，SQL注入一般分为两种情况：有回显和无回显，有回显是指SQL语句返回的内容有显示在页面中；无回显是页面输出的内容并不是SQL语句返回的内容，而是“真”和“假”。

联合查询注入是在原有的查询条件下，通过union拼接上select语句，union可以用于合并两个和多个select语句的结果集

当union之前的select语句结果集为空时，查询结果将由union后的select语句控制。

联合查询语句构造步骤：

对于页面有回显，通常使用联合查询注入，可以快速爆出数据

示例：

报错注入经过构造的函数，让函数处理user()等不合规定的数据，引发mysql报错；几乎任何与数据库有关的操作经过sql拼接都可以产生报错注入；当执行的SQL语句出错时返回错误信息，在错误信息中返回数据库的内容

构造报错注入的语句：

报错注入一般使用在查询不回显数据，但会打印错误信息的页面中

布尔盲注以页面回显内容的不同作为判定依据，通过构造语句返回页面的“真”和“假”来判断数据库信息的正确性

布尔盲注提取数据的基本步骤：

若网页设置了无报错信息返回，在不回显数据+不返回报错信息的情况下，只剩下盲注方法可用，而布尔盲注使用在对真/假条件的返回内容很容易区分的页面中。

示例：

时间盲注通过构造语句，通过页面响应的时长来判断信息；时间盲注的关键点在于if()函数，通过条件语句进行判断，为真则立即执行，否则延时执行，通常使用sleep()等专用的延时函数来进行延时操作

时间盲注与布尔盲注的语句构造过程相似，通常在布尔盲注表达式的基础上使用if函数加入延时语句来构造。通常情况下，盲注需要逐个字符进行判断，极大增加了时间成本，而对于时间盲注来说，还需要额外的延迟时间来作为判断的标准

在布尔盲注永假条件所返回的内容与正常语句返回的内容很接近或相同，无法判断的情况下，可使用时间盲注

示例：

SQL注入的常见分类如上所述，由于本文主要针对Android上SQL注入讲解，这里就不再深入研究，这里引用博客：SQL注入漏洞分析，要深入了解朋友可以看原作者博客，里面还有一些案例讲解。

前面我们已经了解了SQL注入的基本分类，下面我们介绍一些SQL注入实际的测试技巧：

重言式攻击通过一个或多个条件SQL语句查询注入代码，使SQL命令计算为真条件，如(1=1)或（--）。一般可以用来绕过身份验证

例如：

Piggy-backed Queries是一种攻击，它使用查询分隔符（如“；”）向原始查询注入额外的查询语句，从而危及数据库。 在这种方法中，第一个查询是原始的，而随后的查询是注入的。 这次攻击是非常危险的

例如：

逻辑错误攻击利用数据库为错误查询返回的错误消息，这些数据库错误消息通常包含有用的信息，使攻击者能够发现应用程序和数据库架构中的易受攻击的参数。

联合查询注入称为语句注入攻击。 在此攻击中，攻击者在原始SQL语句中插入附加语句。 此攻击可以通过在Vulnerable参数中插入UNION查询或“；<SQL Statement>”形式的语句来完成。

在该技术中，攻击者主要关注数据库系统中存在的存储过程。 存储过程直接由数据库引擎运行。 它是一段可利用的代码。 存储过程为授权或未经授权的客户端提供true或false值。 对于SQLIA，攻击者将写入“； 关机； --“使用登录名或密钥。

利用推断攻击，攻击者可以改变数据库或应用程序的行为。 这种类型的攻击可以分为两种著名的技术，它们是：盲注入和定时攻击

当程序员忘记隐藏导致数据库应用程序不安全的错误消息时，就会发生这种类型的SQLIA，这种错误消息通过SQL语句询问一系列逻辑问题来帮助SQLIA危及数据库。

这种类型的攻击允许攻击者通过观察数据库响应中的定时延迟来从数据库中收集信息。 这类攻击利用if条件语句来达到延时的目的。 WAITFOR是分支上的关键字，它导致数据库将其响应延迟指定的时间。

当攻击者通过使用替代编码（如十六进制、ASCII和Unicode）修改注入查询时，就会发生此类攻击。 通过这种方式，攻击者可以逃离开发人员的过滤器，该过滤器扫描输入查询以查找特定的已知“坏字符”。

Android APP SQL注入漏洞一般位于APP的用户登录，充值页面，修改银行卡，提交留言反馈，商品购买，提现功能等地方

这里我们使用一个漏洞样本来详细的讲解APP SQL注入漏洞的情况

我们前面讲了，可以使用(1=1)或（--）来绕过身份验证，我们知道一般SQL语句登录构造如下：

然后判断返回的行数，如果有返回行，证明账号和密码是正确的，即登录成功，而这样的语句的话

那么我们可以在登录账户或密码后面加上（1=1），因为1=1登录条件永远成立，而--作为内嵌评论的开始字符，会导致后面内容只作为评论，这样就可以不去验证密码的有效性

我们打开应用

这里很显然是一个登录界面，APP会通过用户输入的账号和密码，去查询数据库中用户进行匹配，我们进一步进行静态分析

不难找到这句语句是APP进行数据库查询的语句，我们可以进行进一步分析

不难发现这里我们如果在不知道密码情况下，随意输入，APP会根据账号和密码构造一个有效的负载来避免检测

因此我们可以使用（1=1）和--两种方式来进行sql注入绕过验证

--

我们使用--来构造语句，无非是使得不会去检测密码的有效性，所以我们可以构造语句

这样会是的我们将查询语句构造成上面语句，APP就不会去验证密码，而我们又输入的是管理员账号，所以可以尝试进行sql注入绕过

构造账号和密钥：账号Admin' -- 密钥：Anything

这样就成功的绕过了验证，获得具体信息

我们还可以查询账号密钥相应的详细

同理我们使用（1=1）方式来进行注入

1=1

我们使用1=1来进行注入，无非是相在输入账户情况下，可以输入任意的密码，这样我们只需要使用(OR '1'='1')即可

可以构造SQL语句：

构造账号和密钥：账号：Admin' OR '1'='1 密钥：anything' OR '1'='1

同理成功进入 上面账号和密码可以为任意值

我们上面已经简单的绕过了该攻击，我们可以使用;来进行Piggy-backed查询，这样可以使得在登录系统的同时，再进行执行一条SQL语句

我们可以构造SQL语句：

上面的语句实现三个功能：构造任意的用户名，插入新的sql语句，使得验证码无效

构造用户名和密码：用户名：anyname' OR '1'='1'; INSERT INTO employee (NAME, ID) VALUES ('MUR','11451') -- 密码：anything

这里我们发现成功的登录，但是并没有插入用户名成功，经过分析，在大多数SQLiteDatabase API)中;被定义为终止，所以它之后的任何内容都应该被忽略，但是这也是在一些APP中可以进行测试的环节，当我们理解;作用后，很明显我们又可以得到一种绕过登录的方法，这里既然;后面都无效，是不是意味，我们只要输入正确账户，就可以登录

构造SQL语句：

构造账号和密码：账号Admin';，密码：Anything

同样成功登录

原本逻辑错误攻击是利用数据库为错误查询返回的错误消息，这些数据库错误消息通常包含有用的信息，使攻击者能够发现应用程序和数据库架构中的易受攻击的参数。而我们这里发现在数据字段校验时，通过插入多余的字段，来实现越权的功能

这里我们分析到数据库更新的语句

通过这里的更新语句我们可以很明显的得到构造的SQL

这里我们模拟一般的管理系统，很显然只能管理员对员工的一些信息进行修改，比如薪资，而员工只能修改一般的字段，我们这里通过普通用户模式登陆

可以很明显发现，这里的薪资是无法进行修改的，那我们通过添加字段利用逻辑错误来实现修改

构造SQL:

我们这里修改Phone的字段：

这样就多加了一个字段，但是我们对上面代码逻辑进行分析，发现只是对字符串进行读取，并未校验

点击更新

再次进入我们就发现薪资变为了我们预设的数字

当然利用上面的实现我们还能修改用户名，比如：

我们构造语句：

更新成功后，我们进入Bobby的信息，发现就被修改了

我们前面讲了三种常见类型的SQL注入的案例，但是我们在实际挖掘过程中，怎么初步的判断是否存在这类漏洞，并进行使用

我们打开另外一个样本APK

我们知道并不是所有APK样本，我们都能很轻易的获得源码，有些可能使用了加壳服务，但是测试上述的漏洞很容易

我们都知道SQL注入需要单引号配对，我们可以根据日志和错误提示来查看

首先我们先进行日志监听或使用ddms

然后我们输入一个单引号'

很明显说明这里是存在SQL注入，说明程序是有从Sqlite中获取信息，但由于我们输入'引号，没有配对，导致程序错误

然后我们再输入双引号''

程序正在搜索输入的数据，没有产生SQL错误。为了进一步确认，我们再加一个单引号，看看是否会引发SQL错误

程序再次报错，说明奇数个'会导致SQL错误，当引号刚好匹配时SQL查询正好会执行

然后我们就可以使用我们上面的漏洞来进行测试，我们使用一个万能语句，即无论正确错误都输入的语句

无论是ture还是flase我们都满足，即万能语句

这里我们就成功的爆出了相关信息

这里很显然是app接收了用户的输入，没有经过验证就直接加入到SQL查询语句

针对1-3的漏洞现象，样本中依次进行了安全防护

针对1-2的防护：

上图中2表示防护的代码

针对3的防护：

我们可以发现上传的防护方式，都使用了?, 问号?是 SQL 查询中的参数持有者，将使用 String ListArray 中给出的相应参数进行编译，即会对输入的参数进行转义和绑定，这样就可以有效的进行参数输入防护

我在Android APP漏洞之战（4）——Content漏洞详解已经初步介绍了Content Provider中存在的sql注入漏洞，我们知道Android中provider提供不同进程之间共享内容，而content在查询的过程中也会存在一些典型的Sql注入漏洞

Content Provider SQL注入漏洞产生的因如下：

我们挖掘Content Provider漏洞的步骤：

我们使用drozer扫描注入的位置：

然后我们执行以下命令，发现返回了报错信息，接着构造sql获取敏感数据

列出所有表信息：

获取具体表信息

列出该app的表信息

（1）不需要导出的Content Provider组件，建议显示设置组件的“android:exported”属性为false

（2）当组件可导出时，建议使用selectionArgs进行参数化组成SQL语句，例如：

我们可以发现Content Provider上的sql漏洞核心原理和上面是一样的

Android Download Provider是用来进行下载的一个重要组件，Android提供了一套处理其他App下载请求的机制，例如浏览器的下载、邮件附件的下载、OTA升级包下载等。其中Download Manager用来处理下载请求，DownloadManager下载过程中，会将下载的数据和下载的状态插入ContentProvider中，完成下载后使用ContentProvider来提供下载内容给请求方APP。

下载的流程关系图：

通过利用SQL注入漏洞，未授予任何权限的恶意应用程序可以绕过当前实现的所有访问控制机制，从下载提供程序检索所有条目。 此外，被授予有限权限的应用程序（如Internet）也可以从不同的URI访问所有数据库内容。 对于Gmail、Chrome或Google Play Store等应用程序，从该提供程序检索的信息可能包括潜在的敏感信息，如文件名、描述、标题、路径、URL（在查询字符串中可能包含敏感参数）等。

然而内部数据库中的某些列（例如CookieData）被认为是私有的，不能通过 Download Content Provider 直接访问，除非调用者具有不受限制的权限（URI 受signatureOrSystem访问级别保护）

利用 where 表达式中的 SQL 注入，绕过setStrict过滤器，将允许我们从内部数据库中提取内容，包括任何受限制的列下载

访问下载内容提供程序需要不同的权限，例如Internet或access_all_downloads，这取决于所请求的URI

例如：

但是可以针对下面URL，则无需任何权限：

我们可以在源码中查看对该URI的定义：

可以看出该URI，可以用于公共下载，但没有什么可以阻止攻击者注入SQL Selection子句来访问数据库中的任何行、列或表，包括受保护的列。这样我们就可以进行SQL注入

总结：

因此我们可以构造相关的sql注入语句：

这里需要从Google Chrome下载任何文件（即PDF文件）或从Gmail下载任何附件，确保提供程序包含一些数据，然后使用该语句

由于底层SQLiteQueryBuilder中强制使用严格模式，无法实现基于UNION语句的直接注入，但可以通过利用盲SQL注入提取所有信息：

也可以从request_headers表转储所有内容：

还可以使用盲SQL注入（如果启用此选项，则过程将稍微慢一些）来包含受限列，如UID、ETAG或CookieData

首先我们需要从google上下载一些数据

这里没有合适的案例，就不进行演示了

然后我们编写Poc:

预期效果显示（这里由于没找到合适案例，使用官方图片展示效果）：

同样是针对Download Provider，因为被授予android.permission.INTERNET权限的恶意应用可以在query()方法的sort参数（ORDER BY子句）中附加一个包含子查询语句的LIMIT子句，实施SQL注入攻击，从而检索Download Provider内部数据库的所有条目。

可以构造sql注入语句：

sort参数传入的值是ORDER BY子句后拼接的内容，为了利用此漏洞，可以在sort参数处构造：

这里详细的复现过程可以参考文章：Android Download Provider上的SQL注入——sort参数（CVE-2019-2196）

确保执行数据库操作前合理校验query()方法的sort参数。例如，确保sort参数不包含注入了LIMIT子句和潜在的恶意子查询语句的恶意payload，或者执行更严格的校验，比如要求参数仅包含以逗号分隔的现有数据列列表和字符串“asc”或“desc”。

DownloadProvider.java文件添加代码：

本文通过总结和学习，初步的将讲解了Android平台APP上的常见的Sql注入的方式，并使用一些案例进行了一一的列举，文中一部分漏洞没有找到合适的案例，大家可以参考对应作者的博客，后续相关的实验材料上传github和知识星球

github网址：WindXaa

sql注入漏洞：

DownLoad Provider漏洞：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！