上周三凌晨两点，网站我收到一条短信：“你们商城的漏洞优惠券接口能无限刷。”发信人是书面个陌生号码，附了一张截图，反馈显示他用同一个账号连续领取了47张满减券。网站我打开电脑，漏洞用curl构造了一个请求，书面把手机号参数改成数组格式，反馈服务端果然返回了47张券的网站JSON。这个漏洞的漏洞根源在于后端没有校验手机号是否已领取过，只在前端做了按钮置灰。书面前端校验永远不可信，反馈这是网站常识，但总有人栽在这上面。漏洞
写漏洞反馈最怕什么？书面怕对方看不懂，或者看懂了不认。我见过有人丢过来一句“你们网站有SQL注入”，然后附一个带sqlmap参数的URL。这种反馈基本会被开发当成扫描器报警忽略掉。有效的反馈得让开发一眼看到“哪里、怎么触发、会造成什么”。我习惯用三段式：请求原文、响应差异、影响范围。别写“可能存在风险”，要写“我删掉了别人的订单”。
举个例子。去年帮一个客户看后台，发现用户ID是自增整数，且修改个人资料时没做水平越权校验。我注册了两个账号，A账号用Burp抓包，把userId=1024改成userId=1025，提交后返回了B账号的手机号和邮箱。反馈时我直接贴了两段HTTP请求，一段是正常修改自己资料的，一段是修改别人资料的，响应码都是200。开发看完五分钟就改了。如果你只写“存在越权漏洞”，他可能得先复现半小时。
截图比文字管用。但截图要截对地方。别只截一个报错页面，要截出请求参数和响应里的敏感数据。我习惯用Burp的Repeater界面截图，高亮修改的参数和返回的身份证号。如果漏洞是逻辑漏洞，比如0元购买，那就录屏。录屏比截图更有说服力，因为能展示操作序列。录屏时鼠标别乱晃，每一步停两秒，让开发看清你点了哪个按钮、填了什么值。
有些漏洞没法直接复现，比如条件竞争。我遇到过一个提现接口，并发请求能导致余额扣成负数。这种漏洞用文字描述很吃力。我的做法是写一个Python脚本，用threading模块发20个并发请求，然后把脚本和运行结果一起发过去。脚本里加注释，说明每个请求的作用。开发拿到脚本跑一遍就明白了。别指望开发会自己写PoC，你写了，他改得就快。
反馈渠道也有讲究。别在公开的Issue里贴漏洞细节，也别在群里@所有人。找安全应急响应中心（SRC）或者直接发邮件给技术负责人。邮件标题写清楚“<网站名> 优惠券接口无限领取漏洞”，正文第一句写“复现步骤：1. 登录后访问...”。如果对方有工单系统，就提工单，把优先级标成“高”。别用“紧急”这个词，用多了就不灵了。
最后说一个反面案例。有人发现某网站登录接口返回的用户信息里包含密码哈希，反馈时写“你们把密码明文返回了”。开发一看，是bcrypt哈希，觉得不是明文，就没理。其实问题在于返回了不该返回的字段。正确的写法是：“登录响应体中的password字段返回了bcrypt哈希值，攻击者可离线爆破。建议删除该字段。”你看，同样的漏洞，换种说法，处理速度差三倍。
漏洞反馈不是写论文，不需要背景介绍和风险评估模型。把请求、响应、复现步骤、影响写清楚，附上截图或脚本，发对人。剩下的交给开发。他们改得快，你拿奖金也快。