sqlmap卡在“testing injection point”主因是响应差异不显著，如状态码恒为200、页面结构一致，导致布尔逻辑判断失效；需用--level 3 --risk 3、--string、--fresh-queries等增强识别。
能直接用工具跑出结果的，就别靠肉眼猜——但工具报“存在”，不等于真能利用；工具报“不存在”，也不代表绝对安全。
sqlmap -u 参数检测时为什么总卡在“testing injection point”？
这是最常被误判的环节。sqlmap 默认会对每个参数先发 and 1=1 和 and 1=2 两个请求，比对响应状态码、长度、内容相似度来判断布尔逻辑是否生效。但很多现代应用会返回 200 状态码且页面结构一致（比如前端统一兜底页），导致 sqlmap 无法确认差异，于是反复重试或跳过。
- 加
--level 3 --risk 3提高探测深度，强制测试 Cookie、User-Agent、Referer 等头部字段 - 用
--string或--not-string指定页面中必然出现/不出现的文本（如“用户不存在”“查询成功”），帮它锚定有效响应 - 遇到 JS 渲染页或前后端分离架构，
--fresh-queries避免缓存干扰，必要时配合--proxy http://127.0.0.1:8080用 Burp 抓包人工校验
Wireshark 捕获到 id=1' AND '1'='2 这类请求，说明什么？
这类流量本身不证明漏洞存在，只说明有人在探测——但它是真实攻击链的起点。重点不是“有没有发”，而是“服务器怎么回”。需结合响应体分析：
- 若返回 MySQL 错误信息（如
You have an error in your SQL syntax），基本可确认未过滤单引号，且 SQL 拼接方式暴露 - 若返回空数据但无错误，可能是布尔盲注场景；此时要观察响应时间差异，比如
id=1' AND SLEEP(3)--是否真延迟 3 秒 - 若返回 500 但错误被 WAF 拦截（如显示“Request blocked”），说明有防护，但规则可能被绕过，不能因此放松审计
为什么 NBSI 或 阿D 工具在 PHP+MySQL 环境下经常漏报？
NBSI 是为 ASP+SQL Server 场景深度优化的，其核心检测逻辑依赖 MSSQL 特有的错误模式（如 Microsoft OLE DB Provider for SQL Server）和系统函数（如 sys.fn_sqlvarbasetostr）。在 PHP+MySQL 环境中：
- 它发的
convert(int, ...)类 payload 直接报错或被忽略，根本得不到有效反馈 - 对 MySQL 的报错注入（
extractvalue()）、时间盲注（BENCHMARK()）支持弱，甚至不识别 - 图形界面隐藏了原始请求/响应细节，一旦失败很难定位是网络问题、WAF拦截，还是目标根本不吃这套
换言之：工具选错环境，等于拿锤子拧螺丝——力气再大也没用。
手动验证时，and 1=1 和 and 1=2 为什么必须成对测试？
这不是仪式感，是排除干扰的最小必要操作。单独测 and 1=1 成功，只能说明“语句没崩”，不代表逻辑可控；单独测 and 1=2 失败，也可能是业务逻辑本身返回空（比如商品下架），而非 SQL 执行了条件判断。
- 必须对比两者响应差异：状态码不同？长度差 >20 字节？关键文本消失？
- 如果差异微弱（比如仅时间差 50ms），要用
time-basedpayload 验证，例如id=1' AND IF(1=1,SLEEP(2),0)-- - 整数型参数（如
id=123）可省略单引号，直接试id=123-1是否等价于id=122；字符型（如name=abc）必须闭合引号，否则 SQL 语法错误，测不到逻辑层
真正容易被忽略的，是那些“看起来没报错、也没回显、但响应时间稳定偏高”的接口——它们往往已落入时间盲注的射程内，而多数自动化工具默认不开启耗时检测。
