交叉漏洞

凌晨三点，交叉漏洞我盯着屏幕上的交叉漏洞两段代码，咖啡杯沿留下一圈褐色的交叉漏洞渍。左边是交叉漏洞某电商平台的支付接口，右边是交叉漏洞它新上线的优惠券系统。单独看，交叉漏洞它们都固若金汤，交叉漏洞像两座独立城堡。交叉漏洞可当我把它们拼在一起，交叉漏洞中间那道缝隙里透出了光——一个能让用户以负金额下单的交叉漏洞漏洞。

这活儿我干了七年，交叉漏洞见过太多这种“交叉漏洞”。交叉漏洞不是交叉漏洞某个函数写错了，而是交叉漏洞两个安全系统在交界处互相踩脚。就像你家门锁结实，交叉漏洞窗户也装了防盗网，但小偷发现空调外机正好能踩着翻进阳台——开发商盖楼时可没想过这两样东西能配合成这样。

上个月某银行出的事故更典型。他们的手机银行App有个“一键锁卡”功能，风控系统检测到异地消费就自动触发。另一套系统管着信用卡积分兑换，每笔消费都会实时累积积分。问题出在时间差上：锁卡指令生效前0.3秒，消费请求已经进了积分系统。有人用这个缝隙，在锁卡的瞬间刷了笔大额，积分照常到账，再兑换成航空里程转卖。银行查了三天，愣是没找到哪个环节“出错”——因为每个环节都在按规则运行。

我常跟新来的同事说，别只盯着代码看。真正的漏洞长在流程的褶皱里，藏在两套系统的信任边界上。A系统默认B系统会校验数据，B系统以为A系统已经过滤过了——结果谁都没管。像两个人同时以为对方带了钥匙，门就那样虚掩着。

这种漏洞特别难修。你没法简单打个补丁，因为问题不在任何单一模块里。得有人站在更高的地方，把两套逻辑同时摊开，看它们怎么咬合。去年我们给一家物流公司做审计，发现它们的订单系统和车辆调度系统各有一道“防重复”校验。单独测，都能拦住重复请求。可当订单量暴增时，调度系统会主动把请求重发三次以防丢失——这三次重发绕过了订单系统的防重判断，结果同一批货被三辆车同时派送。修了两个月，最后只是加了条规则：调度系统重发前必须检查订单状态。就这么简单，可之前没人想到去看两个系统之间的对话协议。

做安全这行越久，越觉得漏洞像藤蔓——单株长不成气候，非要攀着两棵树的枝桠才能蔓延。那些出大事故的，往往不是某个密码太弱，而是“忘记密码”和“修改手机号”两个功能能串起来用。攻击者不需要攻破任何一道防线，只需要找到防线之间的缝隙，侧身滑过去。

现在每次接到新项目，我都先画一张系统交互图，专门找那些箭头交错的地方。数据在系统间传递时，每跳一次就多一分风险——就像传话游戏，第一个人说“明天下午三点开会”，传到第五个人嘴里变成“明天带伞去爬山”。代码不会传错话，但两个系统对同一字段的不同理解，比传话游戏更危险。

那晚的电商漏洞最终修好了，在优惠券系统里加了个金额下限判断。但我清楚，过阵子还会有新的交叉漏洞冒出来——只要系统还在增加，交互还在发生。安全不是把每扇门都锁死，而是看清楚门和门之间，谁在负责那条走廊。

本文地址：http://www.79wt.cn/news/350c199648.html