五个赏金，一个漏洞：同一处 SSRF 的五种独立利用方式五个赏金一个漏洞同一处SSRF的五种独立利用方式引言在这篇文章中

官网：http://securitytech.cc/

五个赏金，一个漏洞：同一处 SSRF 的五种独立利用方式

引言

在这篇文章中，我将会讲述一次个人研究中发现的服务端请求伪造（SSRF）漏洞，并展示我是如何通过五种完全不同的技巧成功利用它的。对每一次绕过，我都会解释其逻辑、获得的奖励，以及对应的防御修复为何不足。

什么是 SSRF？为什么它如此危险？

服务端请求伪造（SSRF）是一种严重的安全漏洞，当服务器对用户提供的未验证输入发起请求时，就可能被攻击者利用去访问内部或外部未授权的系统。

本文描述的是盲 SSRF（Blind SSRF），意味着我无法看到服务器返回的内容。但通过分析响应时间、延迟模式，以及成功或失败的行为，我仍然可以推测系统的行为，并在没有直接数据泄漏的情况下有效利用漏洞。

下方是证明成功利用后的奖励截图：

（点击可查看大图）

技术 #1：最基础的 Localhost 端口扫描

在与 WooCommerce 电商平台集成时，应用要求用户提供 shop_Url，该参数被直接传入服务器，服务器会尝试发起 HTTP 请求以确认店铺 URL 是否可访问。

服务器内部会发送类似请求：

GET http://<shop_Url>/wp-json/wc/v1

漏洞背景

shop_Url 作为用户输入被直接使用，没有做任何 IP 校验或主机名过滤。因此攻击者可以传入类似 127.0.0.1 等回环地址，从而让服务器去访问内部服务。

如何进行端口扫描？

服务器请求内部服务：

如果端口开放 → 立即返回（响应快）
- 如果端口关闭 → 会尝试连接直到超时（响应慢）

根据响应时间差即可识别端口状态。

示例：

shop_Url = 127.0.0.1:80 → 快速响应（端口开）
- shop_Url = 127.0.0.1:79 → 超时（端口关）

HTTP 请求示例

POST /api/graphql HTTP/2 Host: redacted.com Cookie: session_id=<SESSION_ID
>; User-Agent: k4yra Content-Type: application/json { "operationName":
"ConnectWoocommerce", "variables": { "shop_Url": "127.0.0.1:80" }, "query":
"mutation ConnectWoocommerce($shop_Url: String!) {\n connectChannel(shop_Url:
$shop_Url)\n}" }</SESSION_ID
>

服务器内部行为：

GET http://127.0.0.1:79/wp-json/wc/v1 → 超时
- GET http://127.0.0.1:80/wp-json/wc/v1 → 快速响应

结果

根本原因： 未过滤内部 IP
- 影响： 可扫描内部服务端口
- 结果： 获得第一个漏洞赏金

修复方式（估计）与失败原因

if "127.0.0.1" in shop_Url or "localhost" in shop_Url:
raise ValidationError("Access to localhost is not allowed.")

此修复只屏蔽了固定字符串：

屏蔽 “127.0.0.1”
- 屏蔽 “localhost”

但未屏蔽整个 127.0.0.0/8，因此可以使用 127.0.1.3 轻松绕过。

技术 #2：利用 CIDR 漏洞绕过 Localhost 限制

开发者屏蔽了“127.0.0.1”，但忘了整个 127.0.0.0/8 都属于 loopback。

使用 127.0.1.3 即可继续 SSRF。

核心原因

他们只屏蔽了：

127.0.0.1（而不是 127.x.x.x）

这一 IP 在技术上仍属于本地回环，服务器仍然会访问内部资源。

HTTP 请求

"shop_Url": "127.0.1.3:80"

服务器内部：

GET http://127.0.1.3:80/wp-json/wc/v1

响应行为同样可以用于端口扫描。

结果

根本原因： 只针对字符串做过滤，而非整段 CIDR
- 影响： 继续访问内部网络
- 结果： 第二个赏金拿下

失败的修复方式（估计）

ip = ipaddress.ip_address(shop_Url.split(":")[0])
if ip in ipaddress.ip_network("127.0.0.0/8"):
raise ValidationError("Access to loopback range is not allowed.")

此修复比之前更好，但仍然没考虑：

八进制格式
- 十六进制格式
- 整数 IP 格式

因此可以继续绕过。

技术 #3：使用八进制格式绕过 IP 过滤

即使屏蔽了整个 127.0.0.0/8，如果应用只检查字符串格式而不进行 IP 规范化，也可以使用八进制格式绕过：

例如：

十进制：127.0.0.1
- 八进制：0177.0000.0000.0001

服务器解析后仍然变成：

127.0.0.1

但字符串检查无法识别此格式。

HTTP 请求

"shop_Url": "0177.0000.0000.0001:80"

服务器内部：

GET http://127.0.0.1:80/wp-json/wc/v1

继续可以用来扫描端口。

结果

根本原因： IP 未规范化
- 影响： 八进制格式成功绕过过滤
- 结果： 第三次成功获得赏金

技术 #4：利用开放重定向链式 SSRF

前几次修复都基于：

禁止 127.0.0.1
- 禁止回环网段
- 禁止八进制

因此这次使用完全不同的方法：开放重定向（Open Redirect）。

访问外部 URL，然后让服务器被 302 重定向到内部地址。

攻击用 URL

http://307.r3dir.me/--to/?url=http://localhost:80

这是一个开放重定向服务（公开可使用）。

服务器流程：

请求外部 URL
1. 服务端收到 Location: http://localhost:80
1. 服务器自动跟随重定向
1. SSRF 成功访问内部服务

端口扫描方式

通过改变端口号：

URL → localhost:80 → 响应快
- URL → localhost:79 → 超时

继续实现盲端口扫描。

结果

根本原因： HTTP 客户端默认跟随重定向
- 影响： 重定向到 localhost
- 结果： 第四个赏金成功

技术 #5：攻击元数据服务与内部网段

开发者修复后开始屏蔽：

localhost
- 回环网段
- 重定向到 localhost

但没有屏蔽所有内部网段，例如：

169.254.169.254（AWS Metadata）
- 10.0.0.0/8
- 172.31.0.0/16
- 192.168.0.0/16

因此可以通过开放重定向访问这些内部资源。

利用元数据服务

攻击 URL：

http://307.r3dir.me/--to/?url=http://169.254.169.254

服务器重定向后访问 AWS Metadata：

http://169.254.169.254/

尽管攻击者看不到返回内容，但通过时间差、响应状态行为仍然可以确认内部请求是否成功。

可访问的其它内部资源

可继续用于端口扫描与内部网络拓扑推测。

结果

根本原因： 防御未覆盖整个内部网段
- 影响： EC2 Metadata SSRF 成功
- 结果： 第五个赏金成功获得

五个赏金，一个漏洞：同一处 SSRF 的五种独立利用方式

官网：http://securitytech.cc/