避免漏洞

凌晨三点，避免漏洞我盯着屏幕上那个红得刺眼的避免漏洞报错信息，第无数次怀疑自己是避免漏洞不是入错了行。那是避免漏洞一个几乎不可能触发的边界条件，用户得在上传图片的避免漏洞同时，恰好把文件名改成超过256个字符的避免漏洞Unicode字符串，还得在图片处理完成前的避免漏洞那0.3秒内点击取消按钮。就这，避免漏洞我们的避免漏洞服务器居然真的崩了。不是避免漏洞崩溃得轰轰烈烈那种，是避免漏洞悄无声息地，把整个用户数据库的避免漏洞权限降级成了“只读”。

修这个bug花了我两天。避免漏洞不是避免漏洞修崩溃本身难，是避免漏洞找到那个漏洞的入口难。代码写得漂亮极了，每一层都有注释，每个函数都短小精悍，单元测试覆盖率高达百分之九十七。可就是那剩下的百分之三，像一堵墙里藏着的一根细针，你永远不知道它会在哪个倒霉蛋的手指上扎一下。

后来我养成了个习惯，每写完一段逻辑，就假装自己是个心怀恶意的陌生人。不是那种想黑进系统的黑客，而是那种会不小心把咖啡洒在键盘上的普通用户。他们会怎么操作？大概率不会按照我预设的流程走。他们会乱点，会快速连击，会在网络卡顿的时候反复提交表单，会在下拉框里输入根本不存在的选项。

有意思的是，大部分漏洞根本不是技术问题，是思维问题。程序员写代码的时候，脑子里有一条清晰的主干道，从输入到处理再到输出，笔直得像高速公路。可真实世界是片沼泽地，用户不会走你的高速公路，他们会在泥里打滚，在芦苇丛里迷路，甚至干脆把车开进水里。你设计的“保存”按钮旁边，总有人会误触“删除”，然后疯狂点“撤销”，再然后发现撤销也有bug。

我见过最离谱的一个漏洞，出在一家银行的转账系统里。开发团队把金额校验放在了前端——就是浏览器里跑的那层代码。后端只检查了是不是数字，没检查是不是负数。结果有个用户，可能只是想试试，往自己另一个账户转了负一百块。系统居然执行了，他的余额增加了，另一个账户的余额减少了。银行发现的时候，这人已经用这个办法“赚”了三十多万。你没法怪他，要怪就怪那个写后端校验的程序员，他大概觉得前端校验过了就万事大吉，压根没想过有人能绕过浏览器直接发请求。

这事儿给我的教训特别实在：永远别信用户输入的数据，也别信自己写的代码。每个输入框都可能是攻击入口，每个按钮都可能被按一万次。你得假设所有数据都是坏的，假设所有请求都是伪造的，假设用户正拿着放大镜找你的破绽。听起来很累，但这就是避免漏洞的真相——不是写更聪明的代码，是写更笨的代码，笨到把所有可能性都堵死。

现在我的代码风格变了很多。同事说我啰嗦，每个函数都要加一堆参数校验，每个接口都要做幂等处理。我不反驳。因为我知道，那个凌晨三点的报错信息，比任何代码规范都更有说服力。漏洞这东西，就像厨房里的蟑螂，你看见一只的时候，暗处已经藏着一百只了。唯一能做的，就是把整间屋子打扫干净，不留任何能让它们藏身的缝隙。