二阶SQL注入漏洞

  • A+
所属分类:安全文章

二阶SQL注入原理

大家通常谈论的SQL注入都是一阶SQL注入漏洞,但是还有一种二阶SQL注入,原理跟一阶SQL注入相同,只是稍加复杂,而且更加难以发现,难以利用,今天我们来分析一下二阶SQL注入漏洞

首先,要明白一阶SQL注入漏洞是在单个HTTP请求响应中触发的,而二阶SQL注入漏洞则需要两个HTTP请求响应,第一次HTTP请求是精心构造的,为第二次HTTP请求触发漏洞做准备。

在第一个HTTP请求中,攻击者构造脏数据(带有单引号或注释符)存储到数据库中。
在第二个HTTP请求中,攻击者直接从数据库中读取脏数据,没有执行进一步的校验和处理就拼接到下一次SQL查询中,从而造成二阶SQL注入漏洞。

其实,归根结底还是一个信任问题。开发人员信任了从数据库中来的数据,而没有进行处理和净化。

网上有张图对二次注入解释的比较清楚,在这里引用一下:

image.png

关于转义函数,我们要重点关注addslashes(),mysql_escape_string()和mysql_real_escape_string()。这几个函数,在参数插入数据库时会对特殊字符进行转义,但是保存在数据库中时还是原始格式内容。

二次SQL注入实例

sqlilab是一个SQL注入练习靶场,全面涵盖了各种SQL注入场景,练习SQL注入技术,一定要刷sqlilab。(sqlilab项目下载地址:https://github.com/Audi-1/sqli-labs)
sqlilab中的第二十四关,考察的知识点是二次SQL注入,我们来分析一下这个漏洞和其中的代码:

image.png
登录的位置我们可以尝试是否存在SQL注入,尝试几次后发现行不通,无论输入什么SQL注入语句,都是无异常,如下图:

image.png

看了源码才知道,这里输入的用户名和密码都经过了mysql_real_escape_string()这个函数的处理。

image.png

查一下这个函数,它会对SQL语句中的某些特殊字符进行转义:

image.png

使用了这个函数,基本上注入是不太可能了。

如果仔细看的话,在登录页面下面还有两个功能,一个是忘记密码,一个是注册新用户。我们先注册一个venus用户,密码为111111,然后使用这个用户登录,登录成功界面如下:

image.png
登录之后,是一个让我们修改密码的功能。
我们看一下修改密码的源码并分析其中的逻辑:

image.png

可以看到$username是直接从session中获取的,并没有进行转义操作,而其他的几个变量如$curr_pass和$pass都已经经过mysql_real_escape_string函数处理。问题就出在$username这个参数上,session中的username是从数据库中获取到的。
而在这个例子中,我们可以通过注册账号往数据库中写入带有特殊字符的username,我们先看看注册用户的后台处理代码:

image.png
注册用户时,使用了mysql_escape_string()函数,前面提到过,这个函数会对特殊字符进行转义,但最终存储到数据库时还是保留了原始格式,我们可以注册一个venus’#用户来验证一下,密码是123123,注册完成登录:

image.png
注册成功之后,我们去数据库中查看下当前的用户名和密码:

image.png
前面的是系统内置的用户,15和16是我们刚才注册的用户。

OK,现在我们来修改venus’#的密码,然后再看看修改密码的SQL语句,这里我们将密码改为123456。
源码里的SQL语句如下:

image.png
将用户名拼接到SQL语句中之后,SQL语句就成为了如下所示:
UPDATE users SET PASSWORD='123456' where username='venus’#' and password='$curr_pass'

由于#号注释掉了后面的语句,所以,我们本来是修改的venus’#的密码,但实际上修改了venus的密码,而且venus’#的当前密码也可以随便输入。

image.png

image.png

现在我们再来看看数据库中venus用户的密码:

image.png
发现venus的密码改变了,而venus’#的密码没有变化。
我们现在用刚才修改的密码123456去登录venus这个用户

image.png
登录成功。
这就是典型的二次SQL注入漏洞。

二阶SQL注入防御

防御SQL注入最有效的方法还是预编译,尽量避免使用SQL语句拼接。
如果使用了SQL语句拼接,要对所有拼接到SQL语句的参数进行严格的净化和处理。

结语

通过上面的讲解和案例分析,相信大家对二阶SQL注入有了一定的了解。二阶SQL注入漏洞比一阶SQL注入更加隐蔽和难以发现,根据二阶SQL注入形成原因,挖掘的时候应该重点关注数据库写入操作,比如创建用户或者是某个请求中提交精心构造的输入,然后逐步跟踪应用程序中可能会使用该输入的地方,来查找应用程序是否会有异常。二阶SQL注入的危害不仅是上文提到的修改管理员账户的密码,根据场景的不同,它的危害跟普通的SQL注入一样。如果在以后的渗透中遇到二阶SQL注入,会继续跟大家分享。

相关推荐: CobaltStrike免杀:从便秘到舒畅

CobaltStrike免杀:从便秘到舒畅1概述有老哥看了前几天发的便秘帖子后,说鸡哥不讲武德,shellcode没发出来,卡巴都没有过,帖子就这样结束了。这次一起奉上,CS通杀所有常见杀软上线运行,相关文件以上传到:https://github.com/ma…