利用 SQL 二阶注入

一、利用 SQL 二阶注入

另一种不同的SQL注入是“二阶”SQL注入，这种的事件时序通常如下所示:

(1)攻击者在HTTP请求中提交某种经过构思的输入。

(2)应用程序存储该输入(通常保存在数据库中)以便后面使用并响应请求。

(3)者提交第二个(不同的)请求。

(4)为处理第二个请求，应用程序会检索已经存储的输入并处理，从而导致攻击者注入的

SOL 查询被执行。

(5)如果可行的话，会在应用程序对第二个请求的响应中向攻击者返回查询结果。

二阶 SOL注入跟等价的一阶 SOL注入一样功能强大。不过它是一种更细微的，通常更难被检测到。

以下是一个二阶SQL注入的案例示例：假设有一个在线购物应用程序，用户可以在网站上添加商品到购物车，并进行结账。

应用程序使用以下SQL查询来更新购物车中的商品数量：

UPDATE cart SET quantity = <new_quantity> WHERE user_id = <user_id> AND product_id = <product_id>

应用程序对用户输入进行了过滤，以防止SQL注入。然而，在实现过滤时，应用程序使用了不安全的方式来拼接用户输入到SQL查询中，如下所示：

new_quantity = request.getParameter("quantity")
user_id = request.getSession().getAttribute("user_id")
product_id = request.getParameter("product_id")
 
sql = "UPDATE cart SET quantity = " + new_quantity + " WHERE user_id = " + user_id + " AND product_id = " + product_id

利用二阶SQL注入攻击来执行恶意的SQL代码。他们添加了一个商品到购物车，并在商品的名称字段中注入恶意的SQL代码，如下所示：

Product Name: '); UPDATE users SET status = 0 WHERE username = 'admin' --

当应用程序尝试更新购物车中的商品数量时，它会执行以下SQL查询：

UPDATE cart SET quantity = 5 WHERE user_id = 1234 AND product_id = 5678; UPDATE users SET status = 0 WHERE username = 'admin' --'

由于应用程序没有正确验证和过滤商品名称字段，注入的恶意SQL代码成功地更新了用户表中的数据，将管理员账户的状态设置为0，实现了恶意的目标。

这个案例展示了二阶SQL注入如何利用应用程序中的数据存储和传递来执行恶意的SQL代码。为了防止这种，开发人员应该使用参数化查询或预编译语句来处理SQL查询，以确保用户输入被正确地转义和处理。此外，应用程序还应该实施严格的访问控制和权限管理，最小化数据暴露的风险。  

二、寻找二阶

二阶 SQL 注入比一阶 SQL 注入更难检测，因为这种漏洞是在一个请求中提交,却在应用程序对另一个请求的处理中执行。

那些发现大多数基于输入的漏洞时所使用的核心技术--通常使用各种构造好的输入来重复提交独立的请求并监视响应中的异常--并不适用于发现二阶 SQL 注入。

与上述技术不同，我们需要在一个请求中提交构思好的输入，然后逐步跟踪应用程序中其他可能使用该输入的功能以便寻找异常。某些情况下，相关输入只有一个实例(例如，用户的显示名称)，这时测试每个有效载荷可能需要逐步跟踪应用所有的功能。

当今的自动扫描器无法很有效地发现二阶SOL注入。不过，手动测试人员可以凭借对功能的理解和对经常出错位置的直觉判断来降低任务的复杂度。大多数情况下,可以使用下面的系统方法来识别二阶:

(1) 在筹划好应用程序的内容和功能后进行复查，寻找所有用户能够控制的数据项，这些数据项会被应用程序持久保存并被后面的功能重用。单独操作每个数据项并为每个实例执行接下来的步骤。

(2) 在数据项中提交一个简单的值,数据项在SQL查询中被不安全地使用时很可能会引发问题，例如，单引号或者使用单引号引起来的字母数字型字符串。如有必要，请快速检查所有包含多个阶段的过程(比如用户注册)以保证数据值完全持久地存在于应用程序中。

(3) 如果发现应用程序的输入过滤器阻止了输入,请使用前面介绍的技术以尝试战胜前台输入过滤器。

(4) 快速检查应用程序中所有存在显式使用数据项的功能以及可能存在隐式使用数据项的功能。寻找所有能够表明是由输入引发了问题的异常行为，比如数据库错误消息、HTTP500状态代码、更隐秘的错误消息、受损的功能、丢失或毁坏的数据等。

(5) 对于识别出来的每个潜在问题,尝试开发一种概念验证来确认是否存在SQL注入。请注意，有缺陷的持久数据可能以间接受到的方式(例如，整型转换错误或后续数据验证失败)来引发异常条件。尝试使用两个引号标识来提供相同的输入并查看异常是否消失。尝试使用数据库专用的结构(比如字符串连接函数和版本标识)来确认正在修改 SQL 查询。如果异常条件是盲的(例如，不返回查询结果或任何错误消息)，请尝试使用时间延迟技术来确认漏洞的存在。

应该意识到，有些二阶 SOL 注入是纯盲的，它们不会对应用程序响应的任何内容产生可识别的影响。

例如，如果应用程序的一个函数以不安全方式编写登录的持久数据并且优雅地处理所有异常，那么使用我们刚刚介绍的步骤可能就无法发现该。

要想检测到这种类型的缺陷，需要先使用步骤(1)中的各种输入(在SQL,查询中不安全地使用这些输入时会触发时间延迟)来重复上述步骤，之后再监视应用程序所有的功能以发现异常延迟。

要想有效实现该目标，需要使用一种语法，而该语法是当前正在使用的数据库类型和当前正在执行的查询(SELECT、INSERT 等)所专用的。实际上这是一种需要长期练习才能掌握的技能。