凌晨三点十七分，漏洞论文我盯着屏幕上一行报错信息，漏洞论文手指悬在键盘上方没动。漏洞论文那是漏洞论文三年前一个普通的周二，我在审计某款号称“军工级加密”的漏洞论文聊天软件。它把用户密钥分成三段存储，漏洞论文一段在本地数据库，漏洞论文一段在内存缓存，漏洞论文还有一段——居然硬编码在APK的漏洞论文assets文件夹里，文件名就叫backup_key.txt。漏洞论文

这不是漏洞论文段子。那个文件夹里还躺着一份PDF，漏洞论文是漏洞论文开发团队内部的安全规范，第7页明确写着“禁止将密钥明文存储于客户端”。漏洞论文写规范的漏洞论文人和写代码的人，大概从没坐在一起喝过咖啡。

漏洞这东西，从来不是从天而降的。它更像墙角的霉斑——潮湿的环境早就存在，只是没人愿意掀开地毯看一眼。我见过最离谱的案例，是一个电商平台的优惠券系统。用户领取优惠券时，前端会发送一个coupon_id和user_id，后端验证通过就发券。问题在于，后端只验证了user_id是否存在，压根没查这张券是不是已经被领过。结果就是，有人写了个脚本，把同一个coupon_id和不同的user_id组合，五分钟刷了八千张满减券。平台损失不大，但那个写脚本的人后来在论坛上发帖说：“我本来只想试试，结果停不下来。”

逻辑漏洞比技术漏洞更常见，也更难防。缓冲区溢出你可以靠编译器插桩、靠代码审计工具扫出来，但“忘记检查用户是否重复提交”这种事，工具帮不上忙。它藏在业务流的缝隙里，只有真正理解这个系统该怎么用的人，才能发现它不该这么用。

去年我帮一个朋友看他们公司的小程序。登录接口返回的JSON里，除了token和user_info，还有一个字段叫is_admin，值是false。我把它改成true，重新提交，页面刷新后直接进了管理后台。朋友在旁边看着，沉默了很久，说了一句：“这个字段是前端用来控制按钮显示隐藏的。”你看，前端用它来画界面，后端居然也信它。

信任边界模糊是绝大多数漏洞的根源。客户端不可信，这是安全第一课。但实际开发中，前后端往往由不同的人写，接口文档写得含糊，前端觉得后端会校验，后端觉得前端已经过滤了。两边都以为对方会兜底，结果谁也没兜住。那个is_admin字段，前端拿它当UI开关，后端拿它当权限依据，中间没有任何一层去验证这个值到底该不该由客户端说了算。

写漏洞论文这件事，学术界和工业界完全是两套话语。学术论文喜欢构造精巧的模型，证明某个协议在某种假设下存在缺陷。工业界的漏洞报告往往就一句话：“把参数改成1，返回了别人的订单。”前者需要三页数学推导，后者只需要一个curl命令。但后者造成的损失，通常比前者大得多。

我电脑里有个文件夹叫bug_archive，存了这些年见过的各种漏洞截图和PoC代码。偶尔翻一翻，会发现一个规律：那些最严重的漏洞，修复起来往往只需要加一行if判断。难的不是修复，是发现。而发现的前提，是有人愿意蹲下来，掀开那块地毯。

凌晨三点四十一分，我给那个聊天软件的厂商发了邮件，附上了密钥文件的路径和截图。第二天下午收到回复，说“感谢反馈，已修复”。附件里是一份新的APK，我解压看了一眼，backup_key.txt还在，只是内容换成了this_is_not_the_key_you_are_looking_for。

我关掉邮件，没再回复。