服务器端请求伪造

服务器端请求伪造(或 SSRF)是一种 Web 安全漏洞,允许攻击者诱使服务器端应用程序向攻击者选择的任意域发起 HTTP 请求。

在典型的 SSRF 示例中,攻击者可能诱使服务器连接回自身,或连接到组织基础设施内的其他基于 Web 的服务,或连接到外部的第三方系统。

绕过过滤器

应用程序通常会阻止包含非白名单主机名、敏感 URL 或 IP 地址(如环回地址、IPv4 链路本地地址、私有地址 等)的输入。在这种情况下,有时可以使用各种技术绕过过滤器。

重定向

您可以尝试使用重定向到所需的 URL 来绕过过滤器。为此,向来自易受攻击服务器的请求返回一个带有 3xx 代码和 Location 头部中所需 URL 的响应,例如:

HTTP/1.1 301 Moved Permanently
Server: nginx
Connection: close
Content-Length: 0
Location: http://127.0.0.1

您可以通过以下方式实现重定向:

  • bash,如 nc -lvp 80 < response.txt

  • URL 缩短服务

  • Mock 和 webhook 服务,参见此处

  • 更灵活的解决方案,如在 python 上的简单 HTTP 服务器

此外,如果应用程序包含开放重定向漏洞,您可以使用它来绕过 URL 过滤器,例如:

这些绕过方法有效,因为应用程序只验证提供的 URL,该 URL 触发重定向。它遵循重定向并向攻击者选择的内部 URL 发出请求。

URL 方案

您可以尝试使用不同的 URL 方案:

Node.js

Windows 版本的 Node.js 将 URL 方案中的任何单个字母视为 drive://filepath 并将协议设置为 file://

参考:

Java

Java 的 URL 将正确处理以下 URL:

参考:

  • @phithon_xg 推文 12

IP 地址格式

您可以尝试使用不同的 IP 地址格式来绕过过滤器。

罕见 IP 地址

RFC 3986 中定义的罕见 IP 地址格式:

  • 点分十六进制 IP:0x7f.0x0.0x0.0x1

  • 无点十六进制 IP:0x7f001

  • 带填充的无点十六进制 IP:0x0a0b0c0d7f000001(填充是 0a0b0c0d

  • 无点十进制 IP:2130706433

  • 带溢出的点分十进制 IP(256):383.256.256.257

  • 点分八进制 IP:0177.0.0.01

  • 无点八进制 IP:017700000001

  • 带填充的点分八进制 IP:00177.000.0000.000001

  • 组合:

您可以通过删除零来简写 IP 地址:

IPv6 地址

  • IPv6 本地地址:

  • IPv4 映射的 IPv6 地址:[::ffff:7f00:1]

  • IPv4 映射的 IPv6 地址:[::ffff:127.0.0.1]

  • IPv4 兼容的 IPv6 地址(已弃用,参见 RFC4291[::127.0.0.1]

  • 带有区域标识符的 IPv4 映射的 IPv6 地址:[::ffff:7f00:1%25]

  • 带有区域标识符的 IPv4 映射的 IPv6 地址:[::ffff:127.0.0.1%eth0]

滥用封闭字母数字

封闭字母数字是一个 Unicode 块,包含圆圈内、方括号内或其他不封闭的封闭内或以句点结尾的字母数字排版符号,参见列表

滥用 Ruby 原生解析器的错误

Resolv::getaddresses 依赖于操作系统,因此通过尝试不同的 IP 格式,可以返回空值。

概念验证:

参考:

损坏的解析器

URL 规范 包含许多在实现临时 URL 解析和验证时容易被忽略的功能:

  • 在主机名之前使用 @ 字符在 URL 中嵌入凭据:https://expected-host@evil-host

  • 使用 # 字符表示 URL 片段:https://evil-host#expected-host

  • DNS 命名层次结构:https://expected-host.evil-host

  • URL 编码字符。这有助于混淆 URL 解析代码。如果实现过滤器的代码处理 URL 编码字符的方式与执行后端 HTTP 请求的代码不同,这特别有用。

  • 这些技术的组合:

参考:

DNS 固定

如果您想要获取解析为 IP 的 A 记录,请使用以下子域:

例如,域名 make-127-0-0-1-rr.1u.ms 解析为 127.0.0.1

多个记录可以用 -and- 分隔:

例如,域名 make-127-0-0-1-and-127-127-127-127-rr.1u.ms 解析为 127.0.0.1127.127.127.127

另外,检查 sslip.io

DNS 重新绑定

如果易受攻击应用程序中的检查和建立连接的机制是独立的,并且没有 DNS 解析响应的缓存,您可以通过操纵 DNS 解析响应来绕过此限制。

例如,如果两个请求在 5 秒内一个接一个地发生,DNS 解析 make-1-1-1-1-rebind-127-0-0-1-rr.1u.ms 将通过第一个请求返回地址 1.1.1.1,第二个返回 127.0.0.1

另外,检查 lock.cmpxchg8b.com

Adobe ColdFusion

FFmpeg

SVG

任意 HTML 和 JS 的服务器端处理

在生成各种文档(例如 PDF)时,经常会发现用户提供的任意 HTML 和 JS 数据的服务器端处理。如果此功能易受 HTML 注入和/或 XSS 攻击,您可以使用它来访问内部资源:

使用 HTTPLeaks 来确定是否有任何允许的 HTML 标签可用于滥用处理。

参考:

电子表格导出

如果应用程序在 Windows 服务器上运行并导出到电子表格,请尝试使用 WEBSERVICE 函数来获得 SSRF:

参考:

请求分割

HTTP 头部

许多应用程序在其流程中使用直接从用户在不同 HTTP 头部(如 X-Forwarded-ForClient-IP 头部)接收的 IP 地址/域名。如果头部的值没有得到适当验证,这种应用程序功能可能导致盲 SSRF 漏洞。

这就是 param-miner 对于搜索 HTTP 头部很有用的地方。

Referer 头部

还要注意 Referer 头部,它被服务器端分析软件用于跟踪访问者。此类软件通常会记录来自请求的 Referer 头部,因为这允许跟踪传入链接。

分析软件实际上会访问出现在 Referer 头部中的任何第三方 URL。这通常是为了分析引用站点的内容,包括传入链接中使用的锚文本。结果,Referer 头部通常代表 SSRF 漏洞的富有成效的攻击面。

参考

最后更新于