我的首个漏洞赏金报告

2022年的某个夜晚，我出于好奇浏览着电商网站页面。那时我甚至还没有HackerOne账户，只有浏览器、开发者工具和探究系统背后运行机制的强烈欲望。

在我称为target.com的网站产品页面上，我注意到一些标记为"匿名"的评论。这看起来很正常，人们在发表评论时喜欢隐藏姓名（说实话，我也是）。但当我检查网络请求时，发现了异常：这些评论的数据仍然包含userid，即使评论本应是匿名的。

这引起了我的好奇。我深入挖掘后发现了加载产品评论的请求接口。它返回包含评分、评论内容以及userid的评论数组。网站在前端隐藏了姓名，但后端仍在发送用户ID。我心想：“如果ID明明存在，为什么还要称之为匿名？”

起初这只是一个ID而已。于是我继续浏览其他页面，检查每个请求，偶然发现了一个用户端点。

我复制了其中一个ID，尝试访问/api/v2/user/profile/get/?userid=<id>。不需要登录，不需要令牌，完全不需要任何验证。就这样，响应直接显示了用户的完整姓名、用户名、加入日期和其他个人资料详情。我甚至尝试在登出状态下访问，仍然有效。

这时我才恍然大悟。所谓的匿名评论其实并不匿名。任何人都可以从评论中获取ID，然后调取用户资料来找出评论者的真实身份。这可能会暴露那些自以为安全用户的隐私，甚至导致骚扰或更严重的后果。

但有趣的是，正如我之前提到的，这是我第一次报告漏洞。我搜索目标公司，反复查找…最终找到了HackerOne。现在我已记不清是否等待了24小时才提交报告，毕竟现在是2025年了。

我撰写了报告，逐步说明了一切：两个端点、暴露的用户ID，以及无需登录即可获取个人资料的情况。然后开始等待反馈。

你知道那种感觉吗？不断登录、刷新页面、搜索赏金，那种迫切期待天上掉钱的美梦？这就是我当时（其实到现在也是）等待时的心情。

结果如何？你可能以为我首次尝试就幸运地获得了赏金，但是…并没有。

我的首个漏洞被标记为重复报告。在我之前已经有人报告过这个问题。没有赏金，只让我意识到自己确实发现了真实存在的漏洞，但不是第一个发现的。

尽管是重复报告，这仍然感觉像是一场胜利。我学到了小细节如何破坏隐私保护，API缺少检查会导致信息泄露，以及关注系统背后数据的重要性。更重要的是，这次经历教会我要持续探索——因为有时表面看似正常的功能下，可能隐藏着等待被发现的漏洞。