webug4.0通关笔记---(第一天：布尔注入)

布尔注入

页面在执行sql语句后，只会显示两种结果，Tuer or False 也就意味着,它不需要报错,不需要知道准确的字段个数, 归根结底它只关心一点: 我们的sql到底有没有被执行成功

如果还没有搭建webug靶场，可以参考我写的这边教学，进行搭建https://blog.csdn.net/liver100day/article/details/115857058

在本次注入中，我们会频繁的使用到下面命令：

length(str)：返回str字符串的长度
substr(str, pos, len)：str:要截取的字符串，pos：开始截取的位置，len：截取的长度 将str从pos位置开始截取len长度的字符进 行返回。注意这里的pos位置是从1开始 的，不是数组的0开始
mid(str,pos,len):str:要截取的字符串，pos：开始截取的位置，len：截取的长度 截取字符串
ascii(str)：返回字符串str的最左面字符的ASCII代码值。
ord(str):返回字符串str的最左面字符的ascii码
if(a,b,c) :a为条件，a为true，返回b，否则返回c，如if(1>2,1,0),返回0

开始注入

判断注入点

打开靶场

输入万能的SQL漏洞查询'来查看是否存在SQL漏洞

发现页面出现了明显的变化，可以判断这里存在SQL布尔注入

判断注入类型

输入1' and '1'='1来判断类型，如果是数字型的话，输入这一句会报错

可以看到，这里页面返回正常，说明并不是数字型，而是字符型

爆破数据库的一些重要信息

判断字段长度

这里以及后面操作之所以后面要加%23是因为，这里注入点将#过滤掉了，而同时又因为是字符型的注入，我们需要#来闭合掉后面的'，使之能够被正常运行，而%23是#的十六进制形式，所以可以绕过过滤使语句正常执行。
输入1' order by 1%23

可以看到，页面返回正常，说明字段长度肯定是大于或者等于1的，我们继续试
但是当我们输入1' order by 3%23时，页面发生了变化，说明字段长度比3小，所以我们得出字段长度为2