继续熟悉burpSuite及pikachu注入漏洞演示

看到源码，构造闭合
看不到源码，就结合经验和想象去尝试性地去做一些payload去测试，根据返回结果去判断
·用 or 1=1 判断是否存在注入

数字型注入

利用输入点先查到信息

前端输入逻辑

发送到repeater做重放测试

修改拼接 payload

所有的用户全部显示了出来

字符型注入

kobe’ or 1=1#’
形成闭合，最后的 ’ 被 # 注释掉了
演示：

搜索型注入

演示：

形成闭合，搜索成功

xx型注入

形成闭合，搜索成功~

结合字符型注入进行简单的测试

字符型注入提示输入username 判断是字符串，要么是’ 要么是 "
先用 " 测试一下

emmmmmmm 不对

再试试 ’

成功了！

用其他方法判断是否存在注入
看是否存在注入关键点：通过输入看返回结果，根据返回结果看我们的输入有没有参与到后台数据库sql里，如果有，就证明我们的输入可以拼接到sql里面去进行惭操作。
eg：

因为 and 1=1 为真，所以和单独输入kobe 结果一样

我们输入的payload and 1=1 是参与后台数据库的逻辑运算的，所以存在注入漏洞。

另一种方法，看报错。
输入特殊符号看会不会报错

输入 ’ 报错

说明我输入的 ’ 被拼接到数据库里面去了，所以就报错，通过报错就知道这个地方存在注入漏洞。

不管是什么类型，都是对SQL中的各种类型的输入进行闭合测试，构造合法SQL，欺骗后台执行。

注释符号小知识

get 和 post 区别

get 利用url传参，post通过我们的请求体系传参。

get 可以直接通过 url 进行 payload 测试。
post 需要用 burpSuite 去抓包，通过重放去修改数据包进行相关的注入测试。