简单漏洞

去年我帮一个朋友看他的小电商后台。登录框底下有个“记住我”的简单漏洞勾选框，勾上之后，简单漏洞浏览器存了个 user=admin 的简单漏洞 Cookie。就这么简单。简单漏洞我把它改成 user=admin2，简单漏洞刷新页面，简单漏洞直接进了另一个店铺的简单漏洞管理界面。没有验证，简单漏洞没有签名，简单漏洞连个时间戳都没有。简单漏洞朋友在旁边看着，简单漏洞愣了半天说：“这玩意儿也能叫漏洞？简单漏洞”

能。而且比那些绕来绕去的简单漏洞远程代码执行可怕得多。复杂漏洞需要天时地利，简单漏洞简单漏洞只需要你懒得改一行代码。

我见过太多人把安全想成一道高墙。防火墙、WAF、加密算法、零信任架构，堆得越高越安心。但攻击者从来不翻墙。他们找门。门没锁，或者锁了但钥匙插在锁孔上。你花三个月部署的入侵检测系统，挡不住一个在 URL 后面加 ?id=1 然后改成 ?id=2 的人。

2019年某社交平台的数据泄露，起因是一个内部接口的 user_id 参数没做权限校验。任何人登录后，把 user_id 从自己的改成别人的，就能拉到对方的私信。接口写得清清楚楚，GET /api/messages?user_id=123。改个数字的事。这个漏洞存在了将近两年，期间平台拿了三轮融资，安全团队从三个人扩到二十个人。没人去点那个接口。

“我们以为安全是加东西，其实安全是别漏东西。”

为什么会漏？因为写代码的人默认“用户不会乱改”。可用户里总有几个会按 F12 的。更糟的是，很多开发觉得“这参数在前端已经校验过了”。前端校验？那玩意儿跟用粉笔在门上写“禁止入内”一样。你打开开发者工具，删掉那个 disabled 属性，或者直接构造请求，粉笔字就没了。

我自己的习惯是，每写完一个带 id 的接口，先不写业务逻辑，先写一行判断：这个 id 属不属于当前登录的人。不属于就返回 403。就这一行，能挡掉八成水平不高的攻击者。但很多人不写。为什么？因为产品经理催得急，因为测试用例里没这条，因为“先上线再说”。

简单漏洞还有个特点：它不挑目标。大厂小厂，新项目老系统，都可能中招。去年某银行 App 的转账接口，把收款账号和金额放在前端算好签名，后端只验签名不验金额。结果有人把金额从 100 改成 10000，签名跟着改——因为签名密钥硬编码在 App 里。这个漏洞的修复成本是重新发版，而攻击成本是下载一个反编译工具。

你可能会说，那用 HTTPS 啊，用 Token 啊。对，但 HTTPS 只保护传输过程，Token 只证明你是谁——它不证明你有权访问这个资源。张三的 Token 能证明他是张三，但后端得自己判断张三能不能看李四的订单。这个判断，就是那一行 if。没有它，Token 就是一张写着名字的纸。

我见过最离谱的一个：某政务系统的文件下载接口，URL 长这样 /download?file=report.pdf。把 report.pdf 改成 ../../etc/passwd，服务器直接把系统文件吐出来了。目录穿越，1990年代就有的漏洞类型。2023年还在出现。修起来也简单，把 .. 过滤掉，或者用白名单。但就是没人做。

所以我现在看一个系统安不安全，不看它用了多少安全产品，就看两件事：每个接口有没有做权限校验，每个输入有没有做边界检查。这两件事做到位，能防住绝大多数真实攻击。剩下的复杂攻击，那是另一个层面的问题。但如果你连门都没关，装再贵的防盗报警器也没用。

简单漏洞不简单。它简单在修复，不简单在发现。因为发现它需要你放下“用户是善意的”这个假设，需要你把自己当成那个会改 id=1 的人。这跟技术无关，跟心态有关。而心态这东西，比任何框架都难改。