多个 HTTP 重定向以绕过 SSRF 保护

我需要同时利用许多已知的 SSRF 技术来成功利用同一公司的许多端点。在发现之后，我将其应用于使用攻击者控制的 URL 的所有功能，并发现 2 个盲读和 1 个全读 SSRF。这是一个错误赏金计划，因此盲 SSRF 以 dups 的形式关闭，另一个被接受。

关于目标

该公司为其他企业提供营销服务。他们的应用程序可让您创建和管理营销活动。有很多功能要测试，但应用程序本身很慢，我不喜欢测试臃肿的应用程序。所以，在学会了在应用程序中做一些基本的事情之后，我决定不花太多时间，在找到一些漏洞后通过程序。 该应用程序与 URL 有很大关系。因此，它引起了我的注意，我决定主要寻找 SSRF。

报告本身没有披露。因此，我将其称为“ company.com ”，并且不会共享来自应用程序本身的任何图像并更改 URL 结构。

开发过程

1. API 需要用户通过应用程序的身份验证，并使用 cookie 来执行此操作。

2.我们有一个API调用，例如

https://www.company.com/api/campaign/v3/check-snippet?url=http://example.com/

3.url参数是我们的注入点。我尝试的第一件事是向我的interactsh处理程序发出请求，以获取请求的 HTTP 标头和 IP 地址。提出了以下要求。

4. 请求来自 AWS EC2 IP 地址，并且没有任何开放端口。也没有有用的 HTTP 标头泄漏。

5. 应用程序发出任何传出请求。所以，我的目标是命中内部主机。这是一个盲目的请求，因为它没有泄露我得到的响应。但是，如果成功向攻击者控制的 URL 发出请求，此功能会以 JSON 格式返回完整的 URL。

6. 允许域和直接 IP。我已经在我的 Linux V** 上运行了 netcat HTTP 服务器，并尝试向它发出请求并且它成功了。但是，当我尝试向“ 127.0.0.1 ”发出请求时，它不起作用。然后，我尝试了“ localhost ”，但也没有用。

7. 我试图通过将“ http://127.0.0.1/$FUZZ”、“$FUZZhttp://127.0.0.1 ”和“ http://local$FUZZhost ”中的 00 模糊为 FF 来滥用 URL 解析器但没有任何结果。然后，我尝试了这个生成许多​​有效载荷的漂亮脚本。同样，没有任何效果。我倾向于在任何地方对所有 UTF-8 进行 FUZZ。通过这种方式，我在 Web 应用程序中发现了许多奇怪的行为。

8. 我有像“127.0000000.000000.000001”和“127.1”这样的有效载荷。没用

9. 我尝试在 DNS A 记录查询中使用返回“127.0.0.1”的子域。没用。

10. 在尝试绕过 SSRF 保护时，我总是使用两个 github 存储库。

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery 
https://github.com/cujanovic/SSRF-Testing

11. 我想看看 API 是否遵循 HTTP 重定向。所以，我做了我以前一直做的事情，并使用了一个自动将 302 重定向到 URL 中设置的 IP 地址的站点。它看起来像这样：

https://make302redirect.io/127.0.0.1

12. 我已使用此有效负载来获取请求，但它不起作用。结果表明，该应用程序基本上搜索了“localhost”和“127.0.0.1”等关键字，如果用户提供的 URL 中存在这些关键字，则会被阻止。

13. 所以，我尝试在我的 V** 上运行一个简单的 Netcat HTTP 服务器，它可以将 302 重定向到发送给它的任何请求。该命令如下所示：

echo -e "找到HTTP/1.1 302\n内容类型：应用程序/json\n位置：http://127.0.0.1\n " | 须藤 nc -l -s 64.227.116.98 -p 8080 -q 1

（我现在不使用那个IP地址，请不要滥用当前用户）

14. 我在下面提出了 API 请求。

https://www.company.com/api/campaign/v3/check-snippet?url=http://myIP/

15. 它没有用。

16.此时，我绝望了。该应用程序基本上使用诸如“localhost，127.0.0.1”之类的关键字并遵循 HTTP 重定向。因此，在尝试了其他一些有效载荷之后，我已经在不同的端口上运行了两个 netcat 服务器，并将第一个重定向到另一个到本地主机。它看起来像这样：

易受攻击的服务器 ---> 我的服务器在端口 8080 ---> 我的服务器在端口 8081 ---> localhost

17. 这次成功了。

结论

如果我使用类似的服务127.0.0.1.nip.io ，我永远不会发现这个漏洞，因为应用程序不接受任何包含 “ 127.0.0.1 ”的内容。 应用程序检查了Location第一个 HTTP 302 重定向中标头的值。但是，它没有检查第二个。这导致了SSRF。

我在不同的 API 端点中使用了这些方法，总共发现了 3 个这样的错误。其中一个是完整的 SSRF，它让我发现内部资产。