应用程序漏洞

去年秋天，我帮朋友修一台旧手机。程序问题很怪：每次打开某款外卖App，漏洞只要点进“我的应用订单”，屏幕就会闪一下，程序然后直接退回桌面。漏洞没有崩溃提示，应用没有日志弹窗。程序重启、漏洞重装、应用清缓存，程序全试了，漏洞没用。应用最后我用调试工具抓了一下运行时的程序堆栈，发现是漏洞App在读取订单列表时，把一个空指针塞进了一个本该存时间戳的字段里。程序走到那儿就懵了，干脆把自己杀了。

这就是典型的应用程序漏洞。它不一定是那种上新闻的“零日漏洞”，也不是黑客电影里敲几行代码就能控制卫星的桥段。很多时候，它就是一个粗心的判断、一个没考虑到的边界条件，或者——更常见的——一个开发人员觉得“这不可能发生”的假设。

我见过一个更离谱的。某银行App的转账页面，金额输入框做了限制：不能超过卡内余额。逻辑看起来没问题。但有人发现，如果你先输入一个很大的数字，比如9999999，然后在键盘弹出的瞬间快速切换到另一个输入框再切回来，那个校验逻辑就失效了。App会把请求发出去，然后被服务器拒绝。这不算严重，但它暴露了一个事实：客户端校验永远只是用户体验，不是安全边界。写代码的人把这两件事搞混了。

结果呢？某个版本的Android系统在输入法切换时，回调顺序和预期不一样，真的传了个空字符串进来。App直接崩溃。用户看到的是“应用无响应”，开发者看到的是后台一堆莫名其妙的崩溃报告。修起来也简单，把那个“不可能”的判断改成正常的空值处理就行。但找到它花了三天。

漏洞这东西，跟虫子一样，你越觉得某个角落干净，它越喜欢往那儿钻。我自己的项目里出过一次事：一个图片上传功能，前端限制了只能传JPG和PNG。后端呢？只检查了文件扩展名。有人把一段PHP代码存成.jpg传上来，服务器一执行，整个目录都暴露了。后来我加了文件头校验，又加了白名单，才算堵住。但每次想起来都后怕——那个上传接口是我写的，我当时觉得“前端都限制了，后端随便查一下就行”。

说回外卖App那个闪退。我最后找到的修复方式很土：在读取订单列表之前，加了一个空值判断。就一行代码。但那一行代码背后，是开发团队对“订单列表一定有时间戳”这个假设的盲目信任。数据从服务器过来，经过序列化、反序列化、网络抖动、版本兼容，任何一个环节都可能让那个字段变成null。你信任数据，数据就坑你。

还有一个容易被忽略的地方：第三方库。你写了个App，用了某个开源图片加载库。那个库的作者可能两年前就不维护了，里面有个内存泄漏，平时没事，一旦用户快速滑动列表，内存就爆了。你查自己的代码查了半天，最后发现是别人的锅。但用户不会管是谁的锅，他们只知道你的App卡死了。所以我现在养成了一个习惯：每引入一个依赖，都去翻翻它的issue列表，看看最近有没有人报严重问题。这很花时间，但比上线后被用户骂强。

漏洞不全是技术问题。有时候是流程问题。比如测试环境的数据和线上不一样，测试的时候那个字段永远有值，线上偶尔没有。或者开发、测试、运维各管一摊，没人对“异常输入”负责。我见过一个团队，后端接口返回的JSON里，某个字段有时是字符串，有时是数字。前端处理的时候没做类型判断，直接当字符串用，结果在iOS上没事，在Android上就崩。原因是两个平台的JSON解析库对类型不一致的处理策略不同。这种坑，文档里不会写，只有踩过的人才知道。

修漏洞这件事，有点像修老房子。你看到墙上有个裂缝，补上了。过两天旁边又裂了一条。你不可能把整面墙拆了重砌，只能一点点找，一点点补。但关键是，你得承认裂缝存在。很多团队的问题是，他们觉得自己的代码“应该没问题”，所以不去做边界测试，不去做模糊测试，不去看崩溃日志里那些“不重要”的堆栈。等到用户流失了，才回头翻日志。

我现在的做法很简单：每次写完一个功能，先问自己三个问题。如果这个字段是空的会怎样？如果这个数字是负数会怎样？如果用户点得特别快会怎样？大部分漏洞，都藏在这三个问题的答案里。剩下的，就交给时间和运气了。