文章总结： 本文详细分析了HackerOne平台上一个结合IPv6编码与重定向技巧的SSRF漏洞案例。攻击者通过将IPv4地址编码为IPv6格式（如[::ffff:7f00:1]）绕过过滤器限制，利用webhook功能的重定向机制成功访问内部服务。关键发现包括端口扫描识别开放端口（5000、5012等）以及手动探测方法的有效性，建议开发者在重定向环节增加IP格式全面校验。 综合评分： 78 文章分类： 漏洞分析,WEB安全,渗透测试,实战经验,红队

0149.HackerOne 报道的真实 SSRF 案例（涉及 IPv6 和重定向）

原创

Red Darkin Red Darkin

Rsec

2026年4月17日 10:14 贵州

在小说阅读器读本章

去阅读

本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。

声明：本文搬运自互联网，如你是原作者，请联系我们！

类型：重定向+SSRF

在网络安全领域，即使是像 Webhook 这样看似无害的功能也可能隐藏着严重的漏洞。本文将深入探讨一个在 Webhook 实现中发现的服务器端请求伪造 (SSRF) 漏洞。这个案例的特别之处在于，只有将 IPv6 行为与重定向技巧结合起来才能利用该漏洞。以下是我和我的好友 madara_ 如何发现并利用此漏洞的技术解析。

在现代应用中，像 Webhook 这样的功能随处可见。它们能够实现自动化、集成和实时工作流程。

但它们也带来了一些危险的东西：

您允许您的服务器代表用户发出请求。

而这正是问题开始出现的地方。

这是一个看似“安全”的 webhook 实现如何导致服务器端请求伪造 (SSRF) 的故事，该攻击结合了 IPv6 编码和重定向滥用。

首先，什么是 SSRF（快速解释）…… 服务器端请求伪造是指攻击者诱骗服务器向非预期目标发送请求，例如：

• 内部服务（ 127.0.0.1 ）
• 私有 API
• 云元数据端点
• 管理界面

你不用直接攻击，而是让服务器为你完成攻击。

#

入口点：Webhook 功能

在 HackerOne 上测试目标时，我们发现了一个 webhook 功能。这没什么不寻常的。直到我们注意到：

• 它接受用户控制的 URL
• 它触发了服务器端请求
• 它设有一些过滤装置。

乍一看，它似乎很坚硬。

#

初始行为

该应用程序具有保护措施：

• 屏蔽十进制格式的内部 IP 地址（例如 127.0.0.1 ）
• 过滤常见的 SSRF 有效载荷
• 允许重定向，但仍以十进制格式阻止内部 IP 地址

所以……没有直接的 SSRF 攻击。

但接下来我们重点测试一些简单的东西：重定向。

我们发现后端会自动跟随重定向，但没有重新验证目标地址，这是一个典型的错误，因此我们没有直接访问内部资源，而是尝试了以下方法： http://attacker.com → 重定向 → 内部资源（十进制） → 仍然被阻止。

于是我们深入探究。

突破：IP 表示技巧

过滤器通常会阻止这种行为：127.0.0.1

但别忘了，同一个 IP 地址可以有不同的写法。[::ffff:7f00:1]

这本质上是将 IPv4 编码为 IPv6……而过滤器呢？没能拦截下来。

这是我们用来检查漏洞是否存在的重定向文件。

<?phpheader("Access-Control-Allow-Origin: *");header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE");header("Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept");header("Content-Type: application/json");header("Location: http://[::ffff:a9fe:a9fe]");?>

当我们意识到我们已经掌握了内部基础设施的入口后，下一步显然就是：端口扫描，但系统另有打算。

webhook 的响应极其不稳定……到处都是延迟，没有可靠的时间安排，也没有清晰的信号。端口开放、端口关闭……一切看起来都一样。自动化完全不起作用。

所以我们做出了调整。

我们没有依赖工具，而是采取了手动方式；缓慢、谨慎、专注。我们开始逐个探测常用端口，寻找任何异常行为。

虽然速度不快，但奏效了。

发现开放端口：

• 5000
• 5012
• 8090
• 8126
• 24220

接下来就更有意思了。内部服务通常会暴露以下问题：

• 调试端点
• 管理面板
• 内部 API
• 指标体系

在此过程中，我们还发现，即使在重定向之后，仍然可以使用八进制和 IPv6 等替代 IP 表示形式来绕过过滤机制。

为了简化攻击过程，我们最终使用了如下的有效载荷：

https://ourserver/h1/redirector.php?url=http://[::ffff:7f00:1]:§5000§

这个漏洞并非旨在破坏系统，而是旨在让系统比它自身更了解自身。过滤器失效并非因为其自身存在缺陷，而是因为其本身并不完整。

时间线

• 2024年1月2日——报告已提交
• 1月3日——“需要更多信息”
• 1月8日——分诊
• 1月9日——“请不要再升级事态了……”😅
• 1月10日——严重程度降低
• 1月16日——悬赏2500美元
• 1 月 30 日——披露[点击此处查看报告]

点击此处查看更多关于 SSRF 绕过技术的详细幻灯片。

#

鸣谢

特别感谢 madara_ 的 合作。

记住，关键从来不仅仅在于漏洞本身，而在于你能把它推向多远。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Rsec Red Darkin Red Darkin《0149.HackerOne 报道的真实 SSRF 案例（涉及 IPv6 和重定向）》