上周三凌晨两点，网站我盯着某电商后台的漏洞订单导出接口，把 order_id=1001 改成 order_id=1002，提交页面直接吐出了别人的网站收货地址和手机号。没有验证码，漏洞没有权限校验，提交连个频率限制都没有。网站我截了图，漏洞关掉浏览器，提交心里清楚这玩意儿要是网站被黑产扫到，一晚上能拖走几十万条数据。漏洞

漏洞提交这事，提交很多人以为就是网站填个表、等审核、漏洞拿奖励。提交实际操作起来，比写代码还磨人。我前后提交过十几次漏洞，从某云服务商的存储桶权限配置错误，到某政务平台的后台弱口令，踩过的坑能写一本小册子。最离谱的一次，我提交了一个 SQL 注入，厂商回复“该接口已下线”，结果三天后我路过那个 URL，它还在线，数据照样能拖。

先搞清楚你手里的东西值不值得提交。不是所有异常都叫漏洞。页面报错弹出一堆堆栈信息，可能只是调试模式没关；某个接口返回了多余字段，也许人家设计就这样。真正能算漏洞的，得满足三个条件：能复现、有危害、厂商能修。我见过有人把“网站没有 HTTPS”当成高危漏洞提交，结果被 SRC 直接标为“忽略”。不是说不该提，是优先级排不上号。

选对平台很关键。企业自己的 SRC（安全应急响应中心）通常响应快、奖金高，但审核也严。第三方平台像补天、漏洞盒子，流程标准化，适合新手练手，不过有些厂商会压等级。我一般先去目标官网找“安全应急响应”入口，找不到再考虑第三方。有一次我通过第三方提交了某运营商的漏洞，等了半个月，厂商回复“请通过官方渠道提交”，白忙活。

写报告别炫技。审核员一天看几百份，没空猜你的思路。标题直接写“XX系统XX接口存在SQL注入可获取全量用户数据”，别整“关于XX系统安全问题的探讨”。复现步骤要能让人照着做一遍就能看到结果。我习惯用 curl 命令贴出来，比截图直观。危害描述别夸大，说“可获取数据库权限”就够了，别写“可控制整个机房”。

提交之后才是真正的拉锯战。厂商说“已修复”，你得去验证。我遇到过修了但没完全修的情况——参数加了过滤，换种编码方式照样绕过。这时候别客气，补充材料再提。也有厂商态度好但技术菜，修了三次都没修对，最后我直接把修复建议写进报告里，他们照着改才通过。别觉得这是越界，能推动问题解决就行。

有个细节很多人忽略：提交前先确认资产归属。我朋友扫到一个漏洞，兴冲冲提交给 A 公司，结果 A 公司说“这个 IP 已经卖给 B 公司了”，他又去找 B 公司，B 公司说“系统是外包做的，你找 C 公司”。一圈下来，漏洞还在，人累了。所以看到 IP 或域名，先 whois 一下，或者看备案信息，别急着下手。

奖金这事随缘。大厂给得爽快，小厂可能只发个证书。我拿过最高的单笔是八千，最低的是某创业公司送的一件文化衫。但说实话，提交漏洞最大的快感不是钱，是那种“我看到了别人没看到的东西”的瞬间。就像半夜改 order_id 那次，屏幕亮着，整个系统在我面前像没穿衣服一样。

最后说个真事。去年我提交了一个逻辑漏洞，厂商修完后给我发了封邮件，说“感谢您帮助我们发现了这个问题，我们内部已经增加了代码审计流程”。那一刻我觉得，比拿奖金值。