提交漏洞的要求

```html

去年冬天，提交我帮一个做安全研究的漏洞朋友整理漏洞报告。他花了三周挖出一个逻辑漏洞，提交能绕过某电商平台的漏洞支付验证。结果提交后，提交厂商回复：“无法复现，漏洞请提供更详细的提交步骤。”他补了录屏、漏洞日志、提交甚至写了个自动化脚本，漏洞对方又拖了两周，提交最后说“已忽略”。漏洞他气得把报告公开在博客上，提交三天后厂商主动联系，漏洞说“我们确认了，提交正在修复”。这事说明一个道理：漏洞提交不是写作文，是打一场信息战。你手里的证据越硬，对方越没法装死。

先讲清楚一件事：漏洞提交的核心不是“描述问题”，是“证明问题存在且可被利用”。很多新手喜欢写“我发现一个XSS，在搜索框输入特殊字符会弹窗”。这不够。你得给出具体的payload、浏览器版本、是否持久化、能否窃取cookie、有没有绕过HttpOnly。厂商每天收几百份报告，模糊的描述直接扔进“需更多信息”的垃圾箱。我见过一个哥们提交SQL注入，只写“id参数存在注入”，连报错截图都没有。结果被标记为“信息不足”，他还在论坛骂厂商眼瞎。真不怪人家。

证据链要完整。从“触发条件”到“实际影响”中间不能断。比如你发现一个越权漏洞，能查看其他用户的订单。光说“修改userId即可”不够。你得展示：正常请求长什么样，修改后返回了什么，这个返回里包含哪些敏感字段（手机号、地址、商品明细），以及这个操作是否留下了日志。最好再补一句“我测试了三个不同账号，均复现”。厂商的修复工程师最怕看到“理论上可以”，他们想要“我试了，确实可以”。

别忽略环境信息。操作系统、浏览器版本、目标应用的版本号、甚至你的网络环境（公网还是内网）。有一次我提交一个SSRF漏洞，厂商说“我们内网无法访问外网”。我补了一句“我是在公网VPS上测试的，目标服务器能解析我的域名”。他们立刻改口。环境细节能堵住厂商“我们环境不同”的借口。另外，如果你用了代理或VPN，最好说明，否则对方可能怀疑你伪造流量。

复现步骤要像菜谱。不是“登录后点击个人中心”，而是“1. 用账号A登录，2. 访问 /user/profile?uid=123，3. 将uid改为124，4. 观察返回的JSON中包含账号B的邮箱”。每一步都要有预期结果和实际结果。如果中间有验证码或CSRF token，你得说明怎么获取的。别写“然后绕过验证”，要写“我抓包发现token在响应头里，直接复制到下一个请求即可”。越具体，对方越没法说“我们复现不了”。

影响描述要克制但有力。别写“此漏洞可导致整个系统崩溃，影响上亿用户”。除非你真能证明。我见过一个提交“反射型XSS”的报告，写“攻击者可窃取管理员cookie，进而控制整个后台”。但那个XSS只在用户自己的浏览器里弹窗，且没有敏感cookie。厂商直接降级为“低危”。正确的写法是：“该XSS可窃取当前用户的session，但需要诱导点击链接。若管理员访问，则可接管其账户。” 加一句“我未测试管理员账户，但普通用户已复现”。诚实反而增加可信度。

最后，别把漏洞报告写成小说。开头直接写“漏洞类型：越权访问；影响：可查看任意用户订单；复现步骤：...”。厂商的安全团队没时间读你的心路历程。我见过一份报告，前两页写“我是如何发现这个漏洞的，那天凌晨三点我喝了杯咖啡...”。第三页才出现payload。这种报告通常被搁置。直接给干货，附件放录屏和日志。如果厂商要求补充，别抱怨，补就是了。你越配合，修复越快。修复后记得问一句“能否申请CVE编号”，这对你的简历有用。

提交漏洞不是求人办事，是技术对话。你的证据越硬，对方越尊重你。那些被忽略的报告，九成是因为信息不完整。别做那九成。