扫描器报sql注入90%是假阳性，因其仅凭响应特征猜测而非执行真实sql；常见误报因参数未进数据库、被waf/缓存拦截或统一json响应干扰；sqlmap验证失败不等于无漏洞，需检查url可达性、参数是否真入sql、权限、回显位及user-agent等5个硬条件；人工验证应发payload观察数据变化或延时，修复必须用预编译语句或orm，禁用字符串拼接。
为什么扫描器一报SQL注入，90%是假阳性
因为扫描器不执行真实SQL，只靠响应特征猜。它看到 id=1' and 1=1-- 返回页面没变、状态码还是200，就标记“疑似字符型注入”——但这个请求可能根本没进数据库，只是被前端JS拦截、被Nginx日志模块记录、或被缓存层直接返回了旧页面。
常见误报场景包括：
- 参数只用于路由分发（如
/user/1'被框架解析为路径变量，未拼SQL） - 后端用该参数查Redis或ES，根本没连MySQL/PostgreSQL
- WAF已过滤单引号但未改响应体，扫描器误以为“过滤失败”
- 应用统一返回
{"code":200,"msg":"success"}，所有输入都回同样JSON，扫描器靠body长度差判别，极易受压缩、CDN、埋点JS干扰
SQLMap验证失败 ≠ 没漏洞，先检查这5个硬条件
SQLMap跑完输出 [INFO] all tested parameters do not appear to be injectable，不代表安全。它卡住往往是因为基础链路不通，不是技术不可利用。
-
curl -I确认目标URL能稳定返回200，中间不能有跳转到登录页或WAF拦截页（如403/503） - 检查参数是否真参与SQL查询：在测试环境加日志，打印最终执行的SQL语句，确认
id字段出现在WHERE子句里 - 数据库账号权限要够——只读账号无法触发
UNION SELECT，得切到开发账号再试 - 响应体必须有“回显位”：比如页面某处能显示
SELECT @@version结果；纯API接口若只返回固定字段，得手动构造AND SLEEP(3)测延时 - 别忘了加
--random-agent或-H "User-Agent: Mozilla/5.0"，有些站点会拦截默认的sqlmap/1.7.2
人工核实三步法：Payload → 观察 → 交叉验证
不依赖工具输出，自己发请求看上下文变化。重点不是“SQLMap说能注入”，而是“我能不能拿到额外数据”。
- 发
id=1' OR '1'='1，对比id=1的响应：新闻列表从1条变100条？说明查询逻辑被绕过，大概率真洞 - 发
id=1' AND SLEEP(5)--，用time curl -sS -o /dev/null http://x.com/p?id=1%27%20AND%20SLEEP%285%29--测响应延迟，超5秒即存在延时盲注 - 查后端日志：看error.log是否出现
You have an error in your SQL syntax；看access.log里带单引号的请求是否真进了业务代码（而非被Nginx/CDN拦截）
修复必须绕开字符串拼接，否则全是掩耳盗铃
加 addslashes()、删 or 1=1、替换单引号为全角，这些操作对现代攻击完全无效。真正有效的只有两条路径：
- 预编译语句：PHP用
PDO::prepare()，Java用PreparedStatement，Python用cursor.execute("SELECT * FROM t WHERE id = %s", [user_id])——变量永不进入SQL字符串 - ORM查询构造器：Django用
User.objects.filter(id=user_id)，Laravel用User::where('id', $id)->first()，前提是不用raw()或DB::select()手拼SQL
复杂点在于：很多老系统里，同一个DAO方法既处理用户输入又拼接动态表名或ORDER BY字段，这种地方预编译也救不了，必须拆逻辑、白名单校验、或引入SQL语法解析器做运行时检查。
