应该会把这个系列给写完,记录自己的学习心得以及毕设收获,也欢迎大佬们批评指正,也希望能给同样的新手小白一些指引~
一、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就可以了,关键是多练多尝试。