清水漏洞的危险性比浑水漏洞

清水漏洞比浑水漏洞危险得多。清水这不是漏洞比喻，是危洞我干了八年渗透测试后最直接的体会。浑水漏洞像明火，险性谁都知道烫；清水漏洞像温水，比浑你泡在里面觉得挺舒服，水漏直到发现皮肉已经熟了。清水

去年我帮一家电商做安全评估。漏洞他们的危洞开发团队很自信，说代码审计报告全是险性绿的，WAF日志干干净净，比浑连SQL注入的水漏告警都没几条。我翻了两天，清水确实没找到什么“像样”的漏洞漏洞。但有个细节让我停住了：用户修改收货地址的危洞接口，返回的JSON里多了一个user_id字段。

这个字段前端根本没用到。我试着把它改成另一个用户的ID，服务器没报错，也没拒绝，只是默默把地址改到了别人账号下。整个过程没有任何异常日志，WAF没触发，因为请求参数完全合法。这就是典型的清水漏洞——权限校验缺失，但接口本身“看起来”没问题。

浑水漏洞有噪音。你扫个目录，满屏的404里夹着200，谁都知道有问题。你发个' OR 1=1--，数据库直接报错，日志红成一片。这些漏洞像浑水里的鳄鱼，你至少知道水里有东西。清水漏洞不一样，它藏在正常的业务逻辑里，用合法的参数做非法的事。你甚至没法用自动化工具扫出来，因为工具不知道“这个用户不该看那个订单”。

更麻烦的是，清水漏洞往往出现在“已经修过”的地方。我见过一个支付系统，开发团队把金额参数做了签名校验，防止篡改。很规范。但他们忘了校验订单归属——用户A可以支付订单B，只要金额签名对得上。结果就是，攻击者用自己账号的合法签名，去支付别人的订单，钱扣了，货发到攻击者手里。这个漏洞存在了七个月，直到有人薅了十几万的货才被发现。期间所有安全扫描都是通过的。

为什么清水漏洞更难防？因为它不违反任何“规则”。WAF规则库不会拦截一个参数完全合法的请求，代码扫描工具不会标记一个没有拼接SQL的查询，连日志系统都看不出异常——请求是200，响应也是200，只是数据错了。这种漏洞的检测依赖对业务逻辑的深度理解，而大多数安全团队没有这个精力。

我自己踩过最大的坑是一个文件下载接口。参数是file_id，做了严格的整数校验，注入不可能。但我发现只要把file_id改成负数，就能下载到系统里的任意文件。因为代码里写的是WHERE id = -1 OR 1=1——负数触发了逻辑漏洞。这个接口跑了三年，没人发现。浑水漏洞至少会留下点痕迹，清水漏洞连痕迹都没有。

所以我现在做测试，先不看漏洞扫描报告。我打开Burp，把每个请求的参数值改一改，改大、改小、改成别人的ID、改成不存在的值。看响应有什么不同。大多数时候没什么不同，但偶尔，你会发现服务器在悄悄做它不该做的事。那种感觉就像在清水里摸到一把刀——你都不知道它什么时候割的你。