凌晨三点，手机震了一下。出现漏洞运维群里有人贴了张截图：用户余额显示为 -2147483648。出现漏洞这个数字太眼熟了——32位有符号整型的出现漏洞最小值。不用猜，出现漏洞又是出现漏洞个溢出漏洞。

我盯着屏幕，出现漏洞想起五年前自己写过的出现漏洞第一行支付代码。那时候刚入行，出现漏洞觉得把金额存成 int 类型天经地义，出现漏洞谁会用负数买东西呢？出现漏洞后来才知道，黑客最喜欢这种“天经地义”的出现漏洞想法。

漏洞从来不是出现漏洞凭空冒出来的。它更像墙角的出现漏洞霉斑，平时看不见，出现漏洞等到湿度、温度、时间全凑齐了，就一片一片往外冒。上周那个案例特别典型：某电商平台搞促销，满减逻辑写成了 if (totalPrice - discount >= 0)。看着没问题对吧？可当用户把折扣券叠加到第17张时，totalPrice 变成了负数，条件居然成立。最后用户倒赚了平台两百块。

写这段代码的人后来在复盘会上说，他测试时最多叠三张券。三张。这个数字暴露了所有问题——他默认了“用户不会那么干”。

这个函数看起来无懈可击，用了 BigDecimal，避免了浮点精度问题。可如果 count 是负数呢？没人校验。攻击者传个 -1，价格直接翻转为负。系统不但不扣钱，还倒贴。

那段时间我养成了一个习惯：每次写完校验逻辑，就问自己一句——“如果用户是个混蛋，他会怎么绕过它？”这问题比任何安全规范都好使。

去年帮朋友看一个物联网项目，智能门锁的固件更新接口。他们用了签名验证，流程看着挺严密。但我注意到一个细节：签名比对用的是 == 而不是 equals()。Java 里字符串 == 比的是引用地址。这意味着只要攻击者能让两个不同内容的字符串指向同一块内存，验证就通过了。更离谱的是，他们居然在日志里打印了正确的签名值。我当场用手机连上调试口，十分钟就刷了个自定义固件进去。

朋友脸都绿了。他说这锁卖了八万台。

漏洞的可怕之处不在于技术多复杂，恰恰在于它往往简单得让人不好意思承认。缓冲区溢出、SQL注入、越权访问——这些词听起来像上古时代的遗迹，可每天还在发生。上个月某银行APP的转账接口，把用户ID放在URL参数里明文传输。改个数字就能看别人的交易记录。我试了，真的可以。

有人觉得这是开发人员粗心。我觉得不全是。更多时候是“赶进度”三个字压垮了一切。产品经理说这个功能明天上线，测试说时间不够只跑了主流程，安全评审？那是什么，能吃吗？

我见过最离谱的一个漏洞藏在密码重置功能里。用户点“忘记密码”，系统发一封邮件，里面带个 token。这个 token 的生成逻辑是 MD5(用户邮箱 + 时间戳)。时间戳精确到秒。攻击者只要知道目标邮箱，再猜一下注册时间，写个脚本跑几万次就能碰撞出来。更妙的是，token 有效期二十四小时。二十四小时够跑几亿次了。

发现这个漏洞的是个刚毕业的实习生。他在测试环境里随手改了下时间戳，居然登进了别人的账号。他兴奋地写了份报告，结果被主管骂了一顿——“谁让你乱试的？”

你看，漏洞不只是代码问题。它是一整套系统里所有侥幸心理的总和。

现在每次上线前，我都会做一件事：把新功能的接口文档打印出来，用红笔把每个参数圈一遍，旁边写上“如果这里是负数/空/超长字符串/特殊字符会怎样”。这个方法笨，但管用。上个月拦住了三个潜在问题，其中一个是优惠券金额可以传 0.0000001，结算时四舍五入变成了零元购。

漏洞不会消失。只要还有人写代码，只要还有 deadline，只要还有“应该没问题吧”这种念头，它就会换个面孔再冒出来。我们能做的，就是在它冒出来之前，先当一回混蛋。