美洽漏洞赏金计划

美洽的漏洞赏金计划鼓励安全研究者负责任地发现并上报产品安全问题，平台按严重度给予分级奖励并提供法律保护。参与者须在授权范围内测试，提交可复现报告并保持沟通；通常列明Web、移动与API等可测范围，排除社工与物理攻击并公开奖励区间与处理时限。平台会及时沟通修复进度并记录信誉积分与奖励发放流程及豁免说明。

先把事情讲清楚（费曼法：先回答“是什么”，再讲“为什么”和“怎么做”）

是什么：漏洞赏金计划（Bug Bounty）是厂商和安全研究者之间的协作机制，厂商通过明确规则、范围与奖励，鼓励外部研究者发现并负责任上报安全缺陷。

为什么重要：比起单靠内部审计，外部研究者能发现更多边缘用例和复杂场景的漏洞；对SaaS平台（如美洽）尤为关键，因为客服系统涉及用户数据、会话、第三方集成等丰富攻击面。

美洽赏金计划的常见组成（你参加前必须看懂的要点）

• 授权测试范围：哪些域名、移动APP包名、API路径可测试；是否允许灰盒（有账户）或仅黑盒测试。
• 不受理项：物理入侵、社工、拒绝服务（DoS）或第三方产品问题通常被排除。
• 提交要求：复现步骤、影响描述、PoC（概念验证）、截图/视频、日志或请求包。
• 评估与奖励：按严重度（低、中、高、严重/critical）分级，并给出奖励或积分；有时还会记录信用并在未来优先发放。
• 时间线：初步确认（triage）通常在7个工作日内，正式评估与修复计划会在后续沟通中明确。
• 法律与安全豁免：遵守规则的研究者通常会被提供有限的法律安全保障（但要严格按规则执行）。

如果你要参与——一步步操作（实操指南）

第一步：阅读并理解规则

先找清楚美洽公布的“赏金计划规则/政策”。规则里会写明允许测试的域名、APP、API，列出不受理的测试类型，说明如何提交和如何取证。别直接动手，读完再动。

第二步：准备环境与授权

• 使用自己的测试账号或官方提供的测试账户。
• 确认是否允许自动化扫描、模糊测试、暴力破解等行为（很多平台会禁止这类会影响可用性的行为）。
• 保留所有交互记录（HTTP抓包、终端日志、截图、录像）。

第三步：发现并验证漏洞

发现问题后先在本地或私有环境复现，尽量避免在生产环境做破坏性测试。再确认漏洞影响范围：是单个用户、所有用户、还是平台级别。

第四步：撰写清晰报告（决定奖励与效率的关键）

一份高质量的报告能显著提高你的可信度和获得奖励的概率。下面给出一个实用模板：

• 标题：一句话说明漏洞类型与影响（例如：Stored XSS导致客服界面可执行任意脚本）
• 概要（Summary）：用一段话描述漏洞是什么，影响哪些用户或模块。
• 测试环境：受影响的域名、APP版本、浏览器版本、账户类型。
• 复现步骤（Step-by-step）：清晰编号，每一步附请求/响应或截图。
• PoC：最小化的可运行示例或回放，必要时附上视频。
• 影响评估：机密性、完整性、可用性受损情况与潜在风险场景。
• 缓解建议：代码层和配置层可行的修复方案（例如对输入进行严格转义与输出编码）。
• 联系方式与沟通偏好：邮箱/平台消息/是否支持加密（PGP）。

常见漏洞类型（针对客服平台要特别注意的）

• XSS（跨站脚本）：客服消息、访客昵称、聊天记录等富文本输入处容易被利用。
• CSRF：免密操作或敏感配置的API，如果没有严格的防护，可能被利用。
• SSRF：平台整合第三方链接预览、抓取远程资源时要小心内网访问风险。
• IDOR（不当的对象访问）：聊天记录、工单、客户信息的权限检查不严，会导致越权查看或修改。
• 认证与会话管理漏洞：会话固定、弱会话失效、过长有效期会导致账户劫持。
• API滥用：速率限制不严或缺乏权限校验会让数据被批量抓取。
• 隐私数据泄露：日志、备份或第三方集成可能会暴露敏感PII。

如何判定严重度（CVSS与业务上下文结合）

不要只看CVSS分数，业务影响（例如客服工单包含银行卡号）往往决定赏金大小。下面是一个实用映射（供参考）：

奖励（示例与现实的差别要认清）

不同公司和计划给予的奖励差异很大。下面的表格仅为行业典型示例，不代表美洽官方数额：

沟通与礼仪（别把自己搞成对立面）

• 提交后耐心等待，不要公开披露细节，直到厂商修复并允许披露（或按厂商的披露策略）。
• 如果平台要求先私下沟通，尊重这一流程；不要滥用PoC在公开场景验证。
• 提供必要的协助（例如代码片段、补丁建议），但不要替代厂商的修复工作。

遇到平台不回应或纠纷时该怎么办

如果美洽或类似平台在合理时限内无回应，可以：

• 再次礼貌催促，并附上先前报告编号与要点。
• 查看是否有备案或第三方安全协调组织（部分公司会委托第三方处理赏金事务）。
• 在确保遵守法律与规则前提下，保留证据并寻求法律咨询（多数情况下不需要走到这一步）。

常见误区与避免方法

• 误区：随意暴力测试生产环境。
  避免：先确定是否允许自动化或暴力测试，尽量用测试账户与非高峰期。
• 误区：提交时只给出漏洞描述但无复现步骤。
  避免：写清楚每次请求与响应，最好附上curl命令或抓包文件。
• 误区：立刻公开漏洞以求曝光。
  避免：先与厂商沟通并跟进修复，公开前确认可披露时机。

示例：一个简短的XSS报告（样例）

下面是一段你可以照抄改写的示例文本，省得从零开始写：

• 标题：Stored XSS in chat message rendering (customer-facing)
• 环境：https://chat.meiqia.com，Chrome 90，用户角色：客服
• 步骤：
  1. 用游客账号在访客昵称字段输入：<script>alert(1)</script>
  2. 客服端打开对应会话，页面在消息列表直接执行脚本。
• 影响：任意脚本执行，可能导致会话劫持、消息篡改或Cookie泄露。
• PoC：截图+录像+抓包（附上请求与响应）
• 修复建议：对用户可见字段统一进行输出编码（HTML实体化），并启用Content Security Policy作为防护层。

给安全研究者的额外建议（提高效率也提高收益）

• 优先关注与用户隐私或大规模影响相关的功能模块（上传、导出、第三方集成、API接口）。
• 使用清晰、可复用的PoC工具链（如Burp保存项目、脚本化复现）。
• 建立个人记录：已提交的bug、厂商响应、奖励记录，长期下来你会形成自己的信誉档案。

对美洽类客服平台的特殊提示（经验类）

• 聊天记录存储与转发链路常常涉及第三方服务（存储、搜索、通知），确认漏洞是否源于第三方。
• 批量导出、数据备份接口要检查是否需要额外的访问控制或脱敏处理。
• 移动端SDK的授权与证书校验常被忽视，注意逆向或模拟调用带来的风险。

最后，关于披露与感谢

很多安全研究者参与赏金计划，既是为了奖励，也为了让产品更安全。美洽或任何服务方在收到高质量报告后大多会积极配合修复并表示感谢（有时通过公开表扬或列入贡献者名单）。你做的是社区服务，也是在为自己的名誉累积资本，所以上报时既要专业也要耐心——嗯，这就是我在做安全沟通时常常重复的事。