安全小白的pikachu靶场学习笔记（二）---sql注入（I）

应该会把这个系列给写完，记录自己的学习心得以及毕设收获，也欢迎大佬们批评指正，也希望能给同样的新手小白一些指引~

---

一、sql注入是什么？

pikachu中对sql注入进行了简单介绍：

哦,SQL注入漏洞，可怕的漏洞。

在owasp发布的top10排行榜里，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞里面首当其冲的就是数据库注入漏洞。
一个严重的SQL注入漏洞，可能会直接导致一家公司破产！
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”**拼接**到SQL语句中后，被当作SQL语句的一部分执行。 从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。
在构建代码时，一般会从如下几个方面的策略来防止SQL注入漏洞：
1.对传进SQL语句里面的变量进行过滤，不允许危险字符传入；
2.使用参数化（Parameterized Query 或 Parameterized Statement）；
3.还有就是,目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了"拼接"的方式,所以使用时需要慎重! 
SQL注入在网络上非常热门，也有很多技术专家写过非常详细的关于SQL注入漏洞的文章，这里就不在多写了。

在我的理解里sql注入漏洞就是构造攻击载荷，这种攻击载荷一旦输入到后台，会被拼接成一条有害的sql语句，攻击后端数据库，导致比较严重的危害。

二、通关操作

1.数字型注入（post）

首先在pikachu中随机选择一个数字提交

然后在bp中抓包，发送到repeater模块

在repeater模块中构造payload:id =1 or 1=1，然后点send，就可以把数据库中所有的用户邮箱爆出来：

这里就是利用了or 1=1这个语句恒成立构造sql语句，让所有id的信息全部暴露出来了。

2.字符型注入（get）

这个更简单一点，post型需要用Bp抓包发送到repeater模块进行修改，而get型直接在输入框进行构造即可：
构造payload:kobe’ or 1=1#

解释一下为什么这么构造而不是kobe or 1=1。
因为原本的程序会自动给你输入的字段加上一对单引号使得sql语句能够被查询
如：正常输入kobe
那么传入后台的语句就是：

select 字段1，字段2 from 表名 where usrname='kobe';

而如果我只是简单输入kobe or 1=1的话，传入后台的语句就是：

select 字段1，字段2 from 表名 where usrname='kobe or 1=1';

可以看到 kobe or 1=1就被当成了一个整体传输，那么自然系统只会返回“用户名不存在”

所以我们构造paylload kobe’ or 1=1#
传到后台就是：
select 字段1，字段2 from 表名 where usrname=‘kobe’ or 1=1#';
这样子的话，首先kobe’标志着一条语句的结束，而#把剩下的那个单引号给注释掉了，最终就能够执行两条sql语句。

3.搜索型注入

后台的查询语句如图：

因此其实和前面字符型注入差不多，也是考虑闭合即可，输入Payload:kobe’ or 1=1#

成功爆库
给出作者大大的总结ppt:

4.xx型注入

还是先作弊看一看源码

可以发现程序员是用()作了闭合
这里的知识点就是：开发人在拼sql时，他可能用各种各样的方式进行拼接，所以我们的核心点就是去构造合法的闭合。
因为是用（）闭合，因此我们的payload也用）闭合
构造payload:

kobe') or 1=1#

这里我们是看了源码去构造，但是在实际攻击中，我们看不到源码，因此要多积累这些闭合手段，然后根据经验去测试，多次尝试。

---

总结

本文对pikachu的sql注入板块前4种类型的注入进行了讲解，后续还会写文章继续讲剩下的。其实分这么多种型号的sql注入也没那么必要，你只要知道sql注入的闭合方式和可利用的构造payload就可以了，关键是多练多尝试。