白地规定型漏洞

去年秋天，白地我在一个开源项目的规定issue区里泡了整整三天。起因很简单：某个功能模块的型漏权限校验逻辑，代码里写着“如果用户角色不是白地admin，则放行”。规定注意，型漏是白地“不是admin则放行”。这行代码在测试环境跑得好好的规定，上线后却差点让整个后台管理接口裸奔。型漏开发者不是白地没写校验，他写了，规定只是型漏写反了。更麻烦的白地是，这种反写在语法上完全合法，规定编译器不会报错，型漏静态扫描工具也未必能揪出来。它就像一扇门，锁装反了，门看着是关的，推一下就开。

这就是典型的白地规定型漏洞。名字听着绕口，拆开看就明白了。“白地”是法律术语里的空白地带，“规定型”是说规则本身存在，但规则覆盖不到某些具体情形。合起来，指的是系统或规范在逻辑上留了一块没被明确约束的区域，而这块区域的默认行为恰好是危险的。它不是没规定，而是规定的方式制造了一个逻辑盲区。

我后来翻了不少类似案例。有个电商平台的优惠券核销逻辑，规则写的是“订单金额大于等于100元时可用券”。开发实现时，把“大于等于”写成了“大于”。结果呢？刚好100元的订单用不了券。用户投诉，客服查半天查不出原因，因为规则文档和代码看起来都对——文档写的是“满100可用”，代码写的是“>100”。差一个等号，白地就出来了。这个白地不是没人管，是管的人以为管住了。

这种漏洞的狡猾之处在于，它往往藏在“正确”的附近。你检查代码，变量名对，函数调用对，逻辑结构也对。唯独边界条件或者否定判断上，偏了一点点。而这一点点，在常规测试用例里极难触发。测试人员写用例时，习惯性覆盖“正常路径”和“常见异常”，但“刚好等于阈值”或者“双重否定”这种场景，很容易被跳过。白地规定型漏洞就蹲在那儿，等着某个真实用户以某种不走运的方式踩进去。

更让人头疼的是，这类漏洞很难靠工具自动发现。静态分析能查空指针、查资源泄漏，但它查不了“业务逻辑的默认真值”。什么叫默认真值？就是当规则没明确说“不行”的时候，系统默认它“行”。比如权限系统里，如果某个角色的权限列表是空的，系统是拒绝所有操作，还是允许所有操作？很多框架的默认行为是允许。因为开发者假设“没配置就是没限制”。这个假设在内部系统里可能没事，一旦暴露到公网，就是灾难。

我自己的判断是，白地规定型漏洞的根源不在技术，在思维习惯。写规则的人习惯用“正向描述”——“满足A则执行B”。但系统运行起来，大量逻辑是反向的：“不满足A则执行C”。正向描述容易写全，反向描述容易漏。因为“不满足A”的情况可能有很多种：A没定义、A为空、A类型不对、A在某个边界上。每一种都是一个白地。而代码的默认分支，往往就是那个没被想到的分支。

怎么防？我的做法很笨但有效：把每一条“否定判断”都当成嫌疑人。看到“!=”、“not”、“else”这些词，停下来问一句——这个分支的默认行为是什么？如果默认行为是“放行”或“允许”，那就得手动把它改成“拒绝”。安全设计里有个原则叫“默认拒绝”，说的就是这个。但很多业务代码为了省事，默认放行，然后靠白名单去拦。白名单没覆盖到的地方，就是白地。

那个开源项目的issue最后怎么解决的？维护者加了一行“else { return false; }”。就一行。但这一行背后，是三天里翻遍权限模块、对比了六个类似项目、写了二十多个测试用例才定位到的。白地规定型漏洞就是这样，修起来可能只要一分钟，找出来可能要一周。而它造成的损失，往往在找出来之前就已经发生了。

很赞哦!（44）