正如你们通常所知道的，我主要是在GoogleVRP上狩猎，所以这是我一个月前的报告，几周前就解决了，所以我今天写这篇文章。

在一个晴朗的日子里，当我在寻找我列举的 GoogleVRP 目标的子域时，我注意到一个奇怪的子域，让我们假设它 learn.jerry.com。这对我来说似乎很奇怪，因为子域的内容长度很大。

注意：由于我是手动猎人，主要在主域或子域上狩猎，并且不做太多侦察，所以只做子域枚举和回溯数据，所以请记住，每当我指向回溯时，这意味着子域和回溯数据。

我开始分析子域，作为普通用户创建登录帐户的帐户，探索它提供的功能和它销售的服务。

经过适当的分析，我想到了让我们使用我的私有模板运行 nuclei 以获得一些关于目标的见解，直到我手动分析它，扫描检测到基于技术的域开放重定向，但不幸的是 googlevrp 不接受开放重定向以及域使用的任何可用的 Oauth 登录，它是子，我可以通过它链接它以获得到 ATO 的开放重定向。

这就是为什么我只是忽略了它，专注于我所做的所有手动分析，过了一段时间，一个用于通过OTP验证用户所有权的功能引起了我的注意。

我玩了一会儿，注意到了一些奇怪的行为，所以我的蜘蛛侠感官提醒我，这里一定有一个错误，只是深入挖掘兄弟。

我快速创建了另外 2 个帐户，用于分析 OTP 的处理及其在验证过程中多次出现意外机会的行为。

BUG的实际利用和深刻理解

我使用用户 A 的电子邮件创建了一个帐户，并迅速向电子邮件发送了 OTP，以验证电子邮件的所有权

我捕获了 OTP 并对用户 B 电子邮件执行了相同的步骤，并在用户 B 的验证过程中使用了用户 A 的 OTP，但不幸的是它失败了并且对我不起作用

但是通过服务器进行的处理仍然让我认为这是一个易受攻击的服务器，也许我得尝试更有趣的场景。

再

我在两个浏览器中都打开了浏览器，我使用用户 A 电子邮件创建了帐户，在浏览器 1 中，我支持服务器要求输入电子邮件以发送 OTP FOR OWNSERSHIP 验证的路径。

然后，当服务器从浏览器 1 向用户 A 发送 OTP 电子邮件时，我输入了用户 B（受害者）的电子邮件，然后单击发送 OTP。

现在，我再次执行了相同的步骤，并将电子邮件再次更改为用户A（攻击者）电子邮件，并再次在浏览器3中获得了OTP（即：我存储了OTP，以便在下一步中使用它来对抗受害者电子邮件）

我再次将电子邮件更改为用户 B（受害者）

现在，当我输入我们得到的电子邮件更改的otp时，服务器感到困惑，并通过绕过所有权验证为我分配了用户B帐户的访问权限。

以下是 FLOW 图，用于更好地理解 bug

结论

这太令人困惑了，所以我认为也许 GoogleVRP triager 将无法复制并关闭它 n/a，但在 3 天内，这个问题被接受了，我通过 GoogleVRP 面板获得了 3 位数的赏金。

感谢您阅读这篇文章，希望你们喜欢。