漏洞bag

凌晨三点十七分，漏洞我盯着屏幕上那个跳动的漏洞光标，第八次复现了那个漏洞。漏洞它安静地躺在代码的漏洞第三十七行，像一只蛰伏的漏洞虫子，等待某个倒霉的漏洞用户触发它的机关。我给它起了个名字叫“bag”，漏洞不是漏洞“bug”——因为它确实像个袋子，把不该吞进去的漏洞数据都吞了进去。

这个bag的漏洞成因简单得可笑。我在写登录验证时，漏洞用了stripos()函数检查用户输入是漏洞否包含“admin”字样。但PHP的漏洞松散比较机制让“Admin”和“aDmIn”都能绕过检查。更讽刺的漏洞是，我在测试时用的漏洞是全小写字母，完美地避开了自己埋下的雷。直到生产环境跑了一周，某个用户用“ADMIN”登录，系统居然真的放行了。

修复它只花了我三十秒。但排查它花了我整整两天。这两天里我翻遍了所有日志，抓了无数个数据包，甚至怀疑是服务器被入侵了。最后是某个同事随口说了一句：“你试试大小写混合？”那一刻我差点把键盘摔了。

这让我想起上个月另一个漏洞。那个更离谱——电商平台的优惠券系统，在跨天订单时会出现时间戳偏移。凌晨十二点整下的单，系统会认为优惠券“已过期”，因为时间计算用的是date('Y-m-d')，而数据库存的是datetime格式。字符串比较“2024-03-15”和“2024-03-15 00:00:01”，前者永远小于后者。这个bug活了一年零三个月，直到某个夜猫子在双十一零点抢购时发现优惠券全废了。

技术圈老爱说“代码即艺术”，但我觉得代码更像厨房。你永远不知道哪个调料罐会突然打翻，哪个锅铲会在关键时刻断柄。有些bug是食材不新鲜，有些是火候没控好，还有些纯粹是菜谱本身就有问题。最可恨的是那种“祖传bug”——写代码的人早离职了，注释写着“此处逻辑复杂，请勿修改”，结果你改一行，整个系统就崩给你看。

有个朋友在银行系统做运维，他跟我讲过最惊险的一次：某个转账接口的金额校验用了浮点数比较，0.1+0.2不等于0.3这种教科书级问题，在真实系统里爆发时，直接导致一笔跨行转账少了三分钱。三分钱啊！但就因为这笔账对不上，他们整个团队被监管约谈，系统停机检修了六个小时。最后修复方案简单到可笑——把==改成abs($a-$b) < 0.001。

说回我这个bag。修复完测试通过后，我盯着那行代码看了很久。其实最可怕的不是漏洞本身，而是它提醒你：你写的每个逻辑都在某个角落里藏着影子。你以为你处理了所有边界情况，但现实总会给你一个“没想到”。就像那个用ADMIN登录的用户，他可能只是手滑按了大写锁定，却无意间捅破了整个系统的窗户纸。

现在我把这个bag的复现步骤写进了团队wiki，标题就叫“永远不要相信用户输入的大小写”。旁边还贴了个便签：下次写代码前，先想想凌晨三点会怎么骂自己。