漏洞验证方法

凌晨两点，漏洞我盯着屏幕上那个返回了200 OK的验证请求，后背发凉。漏洞参数里塞了'; DROP TABLE users;--，验证数据库居然没报错——这往往意味着两种可能：要么是漏洞过滤得干净，要么是验证根本没过滤。区别在于，漏洞前者会返回语法错误，验证后者会静默吞掉一切。漏洞而这次，验证响应时间多了300毫秒。漏洞我按下F12，验证控制台里跳出一行字符：SQLSTATE[42S02]: Base table or 漏洞view not found。行了，验证实锤了。漏洞

验证漏洞的第一步，从来不是拿工具乱扫。你得先问自己：这个漏洞存在的前提条件是什么？比如SQL注入，前提是后端把用户输入直接拼进了查询语句。那验证动作就简单了——构造一个能让查询语法改变的输入，观察响应差异。但很多人栽在第二步：他们看见报错就兴奋，直接掏sqlmap开始跑。结果呢？目标站点有WAF，封了IP不说，还把日志清了。真正稳妥的做法是手工构造几个分级payload，从无害的'到稍微带点逻辑的' AND '1'='1，逐个看响应变化。记住，验证的目的是确认漏洞存在，不是证明你能拿到数据。

有些漏洞藏得深，光靠输入输出判断不出来。比如越权漏洞，你得同时用两个账号交叉测试。A账号访问B账号的资源ID，如果返回了B的数据，那问题就大了。可有时候接口做了模糊匹配，比如/api/user/1和/api/user/01都能返回同一条记录，但你没试过斜杠变体。我见过一个案例，某支付接口用orderId做校验，但没校验orderId是否属于当前用户。测试者用自己订单号改了最后一位，居然查出了别人的收货地址和手机号。这种漏洞验证，核心在于逻辑边界——你得想清楚业务上“谁该访问什么”这条线画在哪。

再说说逻辑漏洞里的时间盲注。有些开发者以为把报错信息隐藏了就能防注入，但响应时间骗不了人。验证方法很简单：构造IF(1=1, SLEEP(5), 0)和IF(1=2, SLEEP(5), 0)两个请求，对比响应时间。如果前者明显慢5秒，那基本跑不掉。可这里有个坑——网络波动和服务器负载会干扰时间测量。所以每次请求至少重复三次，取中位数，还得加个基线请求做对照。我习惯用Python写个十行脚本，循环发50次请求，自动计算平均延迟差。别嫌麻烦，误差控制不好，你会把正常业务误判成漏洞，或者反过来。

文件上传漏洞的验证更直白，但容易踩雷。你上传一个.php文件，如果服务器返回了路径，甚至直接执行了，那漏洞就确认了。但很多站点会检查MIME类型或扩展名白名单。这时候别急着放弃——试试双重扩展名shell.php.jpg，或者大小写绕过Shell.PhP，再不行就塞个.htaccess文件改解析规则。不过我得提醒一句：验证上传漏洞时，千万别传真实恶意代码。传一个只输出phpinfo()的文件就够了，能执行就说明问题存在。你非要传个webshell上去，那就等着被请去喝茶吧。

最后说说那些“看似正常实则漏洞”的情况。比如验证码可以重复使用，或者修改响应包里的success:false为true就能绕过校验。这种漏洞用自动化工具很难发现，得靠手动改包。我的习惯是，每次测试正常业务时，顺手用Burp拦截响应，把关键布尔值或状态码翻转一下，看前端会不会信任。有一次我就是这么发现某银行App的转账接口，只要把响应里的code字段从1改成0，前端就显示成功，虽然钱没真转出去，但逻辑上已经算越权了。

验证漏洞这事，说穿了就是构造条件、观察差异、排除干扰。别迷信工具，也别轻视手工。工具能帮你扩大覆盖面，但真正决定漏洞能不能被确认的，往往是你对业务逻辑的理解深度。多问几个“如果这样呢”，多试几种边界条件，比盲目跑十个扫描器管用得多。