存在安全漏洞

2023年8月，存安某知名电商平台的全漏安全团队在例行代码审计中发现，一个负责用户订单查询的存安接口存在SQL注入漏洞。攻击者只需在搜索框输入一个精心构造的全漏字符串，就能直接读取数据库中所有用户的存安姓名、手机号和收货地址。全漏这个接口上线已经超过两年，存安期间被调用了上亿次，全漏没人发现问题。存安直到一个刚入职的全漏实习生用自动化工具扫了一遍，漏洞才浮出水面。存安

这不是全漏孤例。我曾在一次内部技术分享会上听到一位安全工程师吐槽：他们公司有超过200个微服务，存安每个服务平均暴露3到5个API端点，全漏真正做过完整安全测试的存安不到三成。剩下的要么是“先上线再说”，要么是“等下次迭代补”。下次是哪次？没人知道。

安全漏洞的本质不是技术问题，是优先级问题。写业务代码能拿绩效，修漏洞不能。产品经理催着上线新功能，安全测试被压缩到半天。开发人员心里想的是“先跑通再说”，安全团队想的是“先别出事”。两个目标天然打架，结果往往是前者赢——因为出事是概率事件，而延期是确定事件。

去年有个真实案例。一家做在线教育的公司，数据库配置了默认密码，而且对外开放了3306端口。这个配置从测试环境复制到生产环境，没人改。半年后，数据库被拖库，几十万条用户信息挂在暗网上卖。事后复盘，发现运维团队在部署时确实收到过安全扫描告警，但告警被淹没在每天上千条监控通知里，没人点开看。

告警疲劳是个大问题。安全工具越装越多，误报率居高不下。一个中型企业每天可能收到几万条安全告警，其中真正需要处理的不到1%。安全团队人力有限，只能靠规则过滤。规则写得太严，漏报；写得太松，误报。最后大家干脆只看最高危的那几条，剩下的默认忽略。攻击者恰恰利用的就是这个盲区。

还有一种漏洞更隐蔽——逻辑漏洞。代码层面看不出任何问题，参数校验完整，权限控制严格。但业务流程本身有缺陷。比如某社交平台曾经有个功能：用户A可以查看用户B的主页，但需要B的授权。漏洞在于，授权状态是前端控制的。攻击者抓包修改请求，把“已授权”字段改成true，就能绕过限制。后端没有二次校验。这种漏洞扫描器扫不出来，只能靠人工渗透测试。而人工测试的成本，很多团队不愿意承担。

我见过最离谱的一个案例，是一家金融公司的内部系统。登录接口做了图形验证码，但验证码的答案直接写在返回的JSON里。攻击者根本不需要识别图片，读一下响应体就知道答案。开发人员的解释是：“前端需要知道答案才能校验。”这个逻辑本身没错，但校验应该在后端做。前端校验只是用户体验优化，不是安全措施。把安全寄托在前端，等于把家门钥匙插在锁孔上。

修复漏洞的速度同样堪忧。根据我接触过的十几个团队数据，从发现漏洞到完成修复，平均周期是47天。高危漏洞稍微快一点，也要两周左右。这两周里，系统一直暴露着。攻击者不需要多高明的手段，写个脚本批量扫就行。互联网上每天都有无数个爬虫在扫描常见端口和路径，你的系统只要有一个已知漏洞，大概率已经被标记了。

更麻烦的是，很多团队根本没有资产清单。不知道自己在公网上有多少个IP、多少个域名、多少个API端点。新服务上线不通知安全团队，旧服务下线不清理DNS记录。一个已经被遗忘的测试环境，可能还跑着三年前的代码，带着当时没修的漏洞。攻击者找到它，就像找到一扇没锁的后门。

安全漏洞不会消失。只要代码是人写的，就会有错误。只要业务在迭代，就会有新漏洞。问题在于，我们愿不愿意承认这个现实，并且为修复它付出真实成本——时间、人力、以及最重要的，把安全排在功能前面的决心。