设计漏洞

凌晨三点，设计漏洞我盯着屏幕上的设计漏洞报错日志，第无数次怀疑那个写支付模块的设计漏洞同事是不是在报复社会。明明用户点击“确认支付”时，设计漏洞前端已经弹出了“支付成功”的设计漏洞绿色对勾，后台数据库里却连一条交易记录都没落下。设计漏洞更诡异的设计漏洞是，这笔钱已经从用户的设计漏洞银行卡里扣走了。

这不是设计漏洞灵异事件。这是设计漏洞典型的接口幂等性设计漏洞——当用户在弱网环境下连续点击两次按钮，前端没有做防抖处理，设计漏洞后端又没校验重复请求，设计漏洞系统就会把同一笔订单处理两遍。设计漏洞第一遍扣款成功写入记录，设计漏洞第二遍扣款成功但写入时主键冲突，设计漏洞于是程序优雅地吞掉异常，返回给用户一个假成功。

设计漏洞从来不是技术问题，是人性问题。

上周我帮朋友排查他创业公司的数据泄露事故，发现罪魁祸首居然是个“贴心”功能。产品经理为了让用户忘记密码时少填点信息，设计了个“手机号验证后直接登录”的捷径。工程师照做了，但没给这个接口加频率限制。结果某天凌晨，黑客用脚本批量调这个接口，配合从暗网上买来的手机号段，一夜之间撞库撞出了四万多个有效账号。那个产品的用户总量才八千人。

你看，每个漏洞背后都站着个想走捷径的人。产品经理想省事，工程师想省事，连用户都想省事——可当所有人都图省事时，系统的边界就在某个看不见的角落里悄悄崩塌了。

我记得刚入行时带我的老师傅说过句话：“好的设计是让错误根本不可能发生，而不是发生了再补救。”当时不以为然，觉得他小题大做。直到有次我负责的优惠券系统上线，为了赶档期跳过了并发测试。结果双十一零点刚过，系统被几十万用户同时抢券，数据库连接池瞬间被打爆。更讽刺的是，优惠券的库存明明设置的是五千张，最后发出去九万多张——因为扣库存的SQL语句里没加“库存大于零”这个条件，高并发下多个请求同时读到库存还剩一张，然后同时执行了扣减操作。

那天晚上我蹲在机房里，看着监控屏幕上跳动的错误码，突然理解了什么叫“蝴蝶效应”。一个没加条件判断的SQL，一场精心策划的促销活动，一群熬夜守候的消费者，三者凑在一起，就能让公司的财务部门在接下来三个月里焦头烂额地追讨多发出的八万张优惠券。

设计漏洞最可怕的地方在于，它平时永远蛰伏着，只在最不该出现的时刻咬你一口。就像你家的门锁，平时正常开关毫无异样，可当小偷用一张塑料卡片就能捅开时，你才意识到当初买锁时只看了外观颜值，根本没研究锁芯结构。你怪小偷太狡猾？不，你得怪自己选锁时太肤浅。

去年有家银行找我做安全咨询，他们的转账系统里有个“历史遗留功能”——为了兼容十几年前的老系统，保留了一个不对外公开的调试接口。这个接口没有做身份验证，只要知道URL就能调用。安全扫描时发现了这个问题，但开发团队说“这个接口已经八年没人用了，改它干嘛”。结果三个月后，有人通过这个接口伪造转账指令，转走了六百多万。警方抓到人后才发现，对方根本不是什么黑客高手，只是在GitHub上搜到了这家银行早年开源项目里泄露的代码注释，顺着注释找到了那个被遗忘的接口。

你问我怎么看待设计漏洞？我觉得它像房间里的灰尘——你每天打扫，它每天都有。但真正让你生病的不是灰尘本身，而是你觉得“反正看不见，不扫也没关系”的那股懒劲儿。技术圈老爱说“安全是攻防战”，可大多数漏洞压根轮不到高级攻击，光是内部人的想当然、图省事、嫌麻烦，就足以把系统捅成筛子。修漏洞容易，难的是让每个写代码的人都时刻记得：你随手留的那个口子，可能是别人通往金库的康庄大道。