一个让我怀疑现实的漏洞

故事开始。我像往常一样在HackerOne上闲逛（其实就是找漏洞），突然发现了一个让我惊呼： “等等，这不应该发生吧？”

剧透：它确实发生了。

漏洞重现

1. 访问HackerOne密码重置页面：https://hackerone.com/users/password/new
2. 输入我的邮箱，点击提交
3. 拦截请求时突发奇想：“如果我把请求中的邮箱改成别人的会怎样？”
4. 修改后转发请求
5. 结果：目标邮箱收到了重置邮件，而我这个发起者却没收到

问题严重性

这不是简单的UI显示问题，而是核心功能缺陷：

• 你以为在重置自己的密码
• 实际重置邮件发给了任意指定的人
• 对方能在不知情的情况下重置密码
• 而你还在困惑为什么没收到邮件

想象普通用户遇到这种情况：恐慌、困惑、反复提交客服工单…如果大规模发生呢？

技术原理

攻击步骤：

1. 访问"忘记密码"表单
2. 输入真实邮箱
3. 拦截请求
4. 替换为他人邮箱
5. 转发请求
6. 目标收到重置链接

无需复杂攻击手段，仅需修改一个参数就导致严重的逻辑漏洞。

修复方案

正确的实现应该：

• 服务端严格绑定初始用户输入
• 无论请求如何修改，只发送邮件到最初输入的地址
• 遵循"不信任客户端"的安全原则

但HackerOne的实现却是：“好的，你说发哪就发哪”

时间线

• 2025年6月3日：提交漏洞报告
• 2025年6月4日：确认为2013年报告的重复漏洞

经验总结

这个漏洞的特别之处在于：

• 不需要高技术手段
• 没有复杂攻击载荷
• 纯粹的逻辑缺陷
• 靠的是好奇心而非技术碾压

这正是漏洞猎手的乐趣所在——发现那些从指缝中溜走的简单错误。