repeater手动确认注入点需先发送带单引号的请求（如id=1'），对比响应长度、状态码及内容变化；再尝试闭合变体（如id=1'-- -）观察是否恢复正常，结合报错关键词、布尔差异（and 1=1/1=2）或延时（sleep(3)）综合判断注入类型与可利用性。
怎么用Repeater手动确认注入点存在
别急着开Scanner，先拿Repeater把可疑参数“按住细看”。核心是观察响应是否随输入变化而产生可区分的差异——不是只看报错，更要看长度、状态码、内容结构的变化。
- 把目标请求（比如
GET /user?id=1）右键 →Send to Repeater - 在
id参数后加单引号：id=1'，发送，记下响应长度和HTTP状态码 - 再试闭合变体：
id=1'-- -、id=1" -- -、id=1') -- -，对比响应是否恢复“正常” - 如果
id=1' -- -返回200且内容完整，而id=1'返回500或空白页，说明后端SQL语句被截断且未做异常处理——这是典型可利用信号
注意：有些应用会统一返回500，但响应体里藏了数据库错误关键词（如MySQL、ORA-、syntax error），记得打开Repeater的Response标签页逐行扫。
怎么判断是Union-Based还是盲注
Union-Based能直接回显数据，盲注靠逻辑推断。关键看能不能让后端把你想查的东西“吐出来”。
- 先试
id=1 UNION SELECT 1,2,3-- -：如果页面某处显示2或3，说明列数匹配成功，且该位置可回显——走Union路径 - 如果页面没变化，但
id=1 AND 1=1和id=1 AND 1=2返回内容明显不同（比如一个有用户头像，一个只有空白div），就是布尔盲注起点 - 再试
id=1 AND SLEEP(3)：用Repeater发两次，看响应时间是否稳定延迟3秒以上。延迟成立，说明支持时间盲注
别跳过列数探测：用UNION SELECT NULL,NULL,NULL逐步增加NULL个数，直到不报错。很多新手卡在列数不对，结果一直收不到回显。
Intruder怎么配Payload跑布尔盲注
布尔盲注本质是“问问题”，Intruder就是帮你批量问的机器。重点不在Payload多炫酷，而在怎么让响应差异足够明显、可自动化识别。
- 在Repeater中选中要爆破的参数值（比如
1），点击Add §标记位置 - Payload type选
Simple list，填入两个基础Payload：AND SUBSTRING((SELECT password FROM users WHERE id=1),1,1)='a'和AND SUBSTRING((SELECT password FROM users WHERE id=1),1,1)='b' - 进
Options → Grep-Match，填关键词如Thank you（假设正确条件触发欢迎语）或invalid（错误条件触发提示） - 勾选
Make browser match highlight，发完后直接看哪一行标黄——标黄的那条就是条件为真的Payload
容易漏掉的是响应长度阈值：如果页面本身动态渲染导致长度浮动，就别依赖Length列排序，改用Grep-Match或Compare模块人工比对两组响应的DOM结构差异。
Scanner主动扫描为什么常漏报
Scanner不是万能的，它怕三类东西：WAF拦截、应用层异常处理、上下文不匹配。漏报不等于没洞，只是它没“看懂”你传进去的东西在哪起作用。
- 默认Scanner只测
'、"、;等基础字符，但遇到过滤空格的应用，UNION SELECT会被干掉——得手动在Scanner Options → Payloads里加UNION/**/SELECT这类变体 - 如果目标用JSON传参（如
{"id":1}），Scanner默认不解析JSON body，需在Insertion Points里勾选JSON parameter values - 某些API返回
200 OK但body里是{"success":false,"msg":"db error"}，Scanner可能忽略——要开Grep for messages并填db error
真正可靠的验证永远落在Repeater和Intruder的手动操作上。Scanner只是帮你筛出“值得深挖”的候选，不是判决书。
