反馈漏洞

凌晨两点十七分，反馈漏洞我提交了一个漏洞报告。反馈漏洞不是反馈漏洞那种能拿几万美金赏金的重磅炸弹，只是反馈漏洞一个普通的、几乎没人会注意到的反馈漏洞逻辑缺陷——在某个社交平台的密码重置流程里，验证码的反馈漏洞有效期比文档里写的长了整整八分钟。

对方回复得很快，反馈漏洞快得反常。反馈漏洞三分钟后，反馈漏洞一封自动邮件弹出来：“感谢您的反馈漏洞反馈，此问题已记录，反馈漏洞将在下一个版本修复。反馈漏洞”语气标准得像机器人在念悼词。反馈漏洞我盯着那封邮件看了很久，反馈漏洞忽然意识到，反馈漏洞这已经是这个月我提交的第四个“已记录”漏洞了。前三个呢？我去翻邮件记录——一个说“正在评估”，一个说“已转交相关团队”，还有一个干脆石沉大海，连个自动回复都没给我。

这事让我想起去年在某家银行做渗透测试的经历。客户方有个安全主管，四十多岁，头发梳得一丝不苟。我们在他眼皮底下发现了一个严重的越权漏洞，能直接查看任意用户的交易明细。他听完汇报，面无表情地说了句：“好的，我们内部会处理。”然后就没有然后了。三个月后我回访，发现那个漏洞还躺在那里，像一块没被捡起来的玻璃碎片，随时可能扎伤路人。我问他为什么没修，他苦笑了一下，压低声音说：“修漏洞要改代码，改代码要走变更流程，变更流程要排期，排期要等领导审批——领导最近在忙数字化转型的事，顾不上这个。”

你看，漏洞反馈这件事，真正的难点从来不在“发现”，而在“落地”。技术上的漏洞用补丁就能堵上，流程上的漏洞却像沼泽，你扔多少石头进去，水面很快就恢复平静。我见过最荒诞的一次，是某公司安全团队收到漏洞报告后，第一反应不是验证漏洞真假，而是先查提交者的背景——查完发现是个刚毕业的实习生，于是报告被标记为“低优先级”，理由是“新人可能误报”。结果那个实习生后来自己写了个验证脚本，把漏洞利用过程录成视频发到网上，事情才闹大。

更讽刺的是，有些漏洞反馈渠道本身就是个漏洞。某开源项目维护者告诉我，他每天收到上百条issue，其中三分之一是重复的，三分之一是无效的，剩下三分之一里真正有价值的可能只有十几条。但他就一个人，没时间逐条筛选。于是那些真正严重的、能导致数据泄露的漏洞，常常淹没在“求加个暗黑模式”之类的请求里。他试过用关键词过滤，结果把一条标题写得很委婉的SQL注入报告给滤掉了——那报告标题叫《关于用户输入的一些小建议》。

我有个做安全研究员的朋友，他的处理方式比较极端——发现漏洞后不直接提交，而是先写一篇技术博客发出去，等厂商来找他。他说这样虽然不厚道，但效率最高。“你正经提交报告，人家可能拖半年；你发博客，他们两天内就会主动联系你，态度还特别好。”他顿了顿，补了一句，“漏洞反馈的本质不是技术问题，是权力问题——谁有动力去改，谁才有动力去听。”

写到这里，我又收到一封新邮件。是之前那家社交平台发来的，说我报告的验证码延长期限问题已经修复了，附了个补丁说明链接。我点进去看了一眼，修复方式很简单，就是把验证码的有效期从十分钟改成了八分钟。改动就一行代码的事，却花了两周才落地——中间隔了一个周末、一次产品评审会、两次领导出差。

但至少，它被修了。这年头，一个漏洞能被认真对待，已经算是一种幸运了。至于那些还在“正在评估”里的报告，我打算再等两周。如果还没动静，我就把它们整理成一份清单，发到微博上。题目我都想好了，就叫《那些年我们提交过的漏洞》。反正，总比让它们烂在某个无人问津的工单系统里强。你说是不是。

本文地址：http://www.79wt.cn/news/1362a0699857.html