dast工具中，sqlmap（--batch模式）、xray（v1.9+ sqllib插件）和acunetix（新版时间盲注逻辑）能实际跑出sql注入poc；owasp zap默认策略因缺乏深度编码变形能力而不推荐。
哪些DAST工具能实际跑出SQL注入PoC
DAST工具检测SQL注入，核心是靠主动发带payload的HTTP请求并观察响应差异。不是所有标称“支持SQLi检测”的工具都能稳定触发或识别——sqlmap虽常被归为渗透工具，但它的--batch + --level=5 --risk=3模式在DAST流程中更接近自动化扫描器；xray（v1.9+）内置sqllib插件，对布尔盲注和报错注入识别率高；Acunetix新版对sleep()类时间盲注有专用检测逻辑，但误报集中在WAF拦截后返回的503/403页面上。
不建议用OWASP ZAP默认策略扫SQLi：它的active scan默认不启用深度编码变形，对绕过WAF的%27%20OR%201%3D1或/*!50000UNION*/类载荷响应迟钝。
必须手工补全的三个关键输入点
DAST工具只扫描它“看到”的请求，而很多SQL注入入口根本不在常规GET/POST参数里：
-
Cookie字段：如sessionid=abc123被拼进查询时，需在xray或sqlmap中用-cookie显式传入 -
X-Forwarded-For或User-Agent头：某些老系统会把IP或UA存进日志表再查，DAST默认不 fuzz 这些头，得手动加--headers参数 - JSON body中的深层字段：比如
{"filter":{"name":"admin"}}里的name，工具若没解析JSON结构，就会漏掉——sqlmap -r request.txt比自动爬取更可靠
为什么DAST扫不出二阶SQL注入
二阶SQL注入的本质是：第一步输入被安全存储（如进数据库），第二步在另一处读取并拼接执行。DAST无法关联这两个非连续请求——它看到的是两个独立HTTP事务，中间没有显式数据流标记。
典型场景：POST /profile提交bio=' OR 1=1 -- 成功保存；GET /report?user_id=123触发后台查询SELECT * FROM profiles WHERE id = ? AND bio LIKE '%'+@bio+'%'才执行恶意逻辑。DAST对第二个请求的user_id参数做fuzz时，根本不知道@bio已被污染。
解决方案只有两条路：
- 用IAST工具（如Contrast或Seeker）在运行时Hook SQL执行点，捕获变量来源
- 人工审计代码，定位所有“入库后再次拼接查询”的路径，再针对性用
sqlmap -u "http://x/report?user_id=123" --data="user_id=123" --technique=S（S代表stacked queries）验证
扫到疑似漏洞后怎么快速验证真假
DAST报告的“SQLi detected”可能只是WAF拦截、应用层异常或数据库连接池超时导致的500响应，不是真漏洞。验证必须分三步交叉比对：
- 复现原始payload：比如DAST发了
?id=1' AND SLEEP(5)--，自己curl一把，用time curl -s "url?id=1%27%20AND%20SLEEP%285%29--"看是否真延迟5秒以上 - 换一个数据库函数：MySQL用
SLEEP()，PostgreSQL得换pg_sleep()，否则DAST的PoC在PG环境必然失败 - 检查回显位置：报错注入依赖
updatexml()等函数报错，但如果应用统一捕获SQLException并返回固定提示页，DAST看到的永远是200+正常HTML，此时需开代理抓包看原始响应体是否含XPATH syntax error
真正难啃的其实是WAF后面那些“响应码不变、内容微变”的盲注——DAST的阈值判断容易失效，这时候只能切回sqlmap --batch --level=5 --risk=3 --threads=5硬刚，但得提前配好--tamper=space2comment这类绕过脚本。
