sqlmap判断

sqlmap跑完一圈，判断屏幕上跳出“parameter 'id' is 判断vulnerable”的时候，很多人第一反应是判断“稳了”。别急。判断这个判断本身可能就有问题。判断我见过太多人拿着sqlmap的判断输出当圣旨，结果手工验证时发现是判断个误报，或者反过来——sqlmap说没问题，判断实际却存在注入点。判断判断这件事，判断从来不是判断看它打印了什么，而是判断看它怎么得出的结论。

sqlmap判断注入的判断核心逻辑其实不复杂。它往参数里塞各种payload，判断观察响应差异。判断布尔盲注看页面内容变化，时间盲注看响应延迟，报错注入看数据库报错信息。问题在于，这些信号都可能被干扰。比如目标站点用了WAF，payload被拦截后返回一个自定义错误页，sqlmap可能把这个当成“页面内容变化”，误判为布尔注入。或者网络本身就不稳定，延迟忽高忽低，时间盲注的阈值一松，假阳性就出来了。

我印象很深的一次，帮朋友看一个站。sqlmap报了个时间盲注，payload是AND SLEEP(5)。朋友高兴坏了。我让他先别声张，手动测一下。结果发现那个参数无论传什么值，响应时间都在4到6秒之间波动——服务器本身负载就高。sqlmap的默认延迟阈值是5秒，刚好卡在波动区间里，它随机几次命中超过5秒，就判定存在注入。这种误报，手工一测就露馅。

反过来，漏报也常见。有些站点对特定payload做了过滤，但换个编码方式就通了。sqlmap的tamper脚本能绕过一部分，可如果目标环境比较特殊——比如用了非标准的数据处理逻辑——sqlmap的测试用例可能覆盖不到。我遇到过参数在进入SQL查询前被做了两次URL解码的情况，sqlmap默认只解一次，payload自然打不进去。后来手动构造了双重编码的payload，注入点才暴露出来。

那怎么判断sqlmap的结果靠不靠谱？我的习惯是三步走。第一步，看它给出的payload。如果sqlmap只报了“时间盲注”且延迟阈值接近目标正常响应时间的上限，先打个问号。第二步，手工验证。布尔盲注就自己构造true/false条件对比页面差异；时间盲注就多测几次，取正常响应时间的平均值和标准差，看注入payload的延迟是否显著偏离。第三步，换个工具交叉验证。比如用sqlmap --technique=B只跑布尔盲注，或者用Burp的Intruder手动fuzz几个关键字符，看看响应有没有规律性变化。

还有个细节容易被忽略：sqlmap的--level和--risk参数。默认level=1、risk=1，测试的payload很保守。有些注入点需要更高的level才会被触发，比如Cookie里的参数或者User-Agent头。但调高level和risk也会增加误报概率，尤其是risk=3时会尝试OR 1=1这类可能修改数据的payload。我一般先默认跑一遍，没结果再逐步调高，同时盯着日志看它到底在测什么。

判断这件事，工具给的是线索，不是结论。sqlmap的“vulnerable”和“not vulnerable”都只是它基于当前配置和网络环境做出的推测。真正靠谱的判断，来自你对目标行为的观察、对payload原理的理解，以及手工验证的耐心。别偷懒。工具跑完只是开始，手工确认才是结束。