服务器端请求伪造（SSRF）攻击的进阶利用与防御绕过技术详解
字数 3435 2025-12-11 01:58:47

服务器端请求伪造（SSRF）攻击的进阶利用与防御绕过技术详解

一、 知识点描述

服务器端请求伪造（Server-Side Request Forgery， SSRF）是一种由攻击者构造恶意请求，诱使服务器端应用向攻击者指定的内部或外部资源发起非预期请求的安全漏洞。进阶利用与防御绕过技术指的是在目标应用已部署基本防护措施（如黑名单、白名单过滤、DNS解析校验等）的情况下，攻击者通过更隐蔽、更复杂的技术手段，成功利用SSRF漏洞，实现更深层次的攻击目标，例如访问敏感内网服务、进行端口扫描、甚至远程代码执行。

核心危险在于，服务器通常拥有更高的网络权限（可访问防火墙后的内网、云服务元数据接口等），并且其发起的请求可能被内部系统视为“可信流量”，从而绕过某些认证机制。

二、 解题/讲解过程

我们从一个假设的、存在基础SSRF漏洞的场景开始，逐步升级防护措施，并对应讲解攻击者如何绕过。

步骤1：基础SSRF场景与利用

  1. 漏洞点：一个Web应用提供一个“网页快照”或“URL内容获取”功能。用户提交一个URL（如 https://example.com），服务器会去获取该URL的内容并返回给用户。
  2. 利用：
    • 访问内网服务：攻击者提交 http://192.168.1.1/admin，服务器会请求这个内网IP的管理界面。
    • 端口扫描：通过观测服务器响应时间或错误信息，判断目标IP的特定端口是否开放（如提交 http://192.168.1.1:22）。
    • 访问云元数据：在云环境中，服务器可以访问一个特定的内部端点（如AWS的 http://169.254.169.254/latest/meta-data/）来获取自身实例的敏感信息（密钥、配置等）。

步骤2：基础防御 - URL协议与地址黑名单

  1. 防御措施：开发者意识到风险，开始过滤。
    • 禁止使用 http://、https:// 之外的协议（如 file://、gopher://、dict:// 可能被直接禁用）。
    • 将常见内网IP段（10.0.0.0/8， 172.16.0.0/12， 192.168.0.0/16）和回环地址（127.0.0.1， localhost）加入黑名单。
  2. 绕过技术：
    • 利用进制、八进制、十六进制或混合表示法：IP地址可以多种格式表示，黑名单可能只检查点分十进制格式。
      • 127.0.0.1 -> 2130706433（十进制）、0177.0.0.1（八进制）、0x7f.0.0.1（十六进制）、127.1（省略后缀零）。
    • 利用域名解析：
      • 注册一个指向内网IP的域名（如 attacker-internal.com A记录指向 192.168.1.1）。
      • 使用 localtest.me 等公共域名，其解析结果指向 127.0.0.1。
      • 利用 DNS重绑定攻击：攻击者控制一个域名，其TTL极短，第一次解析返回一个允许的外网IP（通过黑名单检查），当服务器真正发起请求时，DNS解析结果已变为目标内网IP。
    • 利用URL解析差异：应用程序代码、底层库（如 curl、libcurl）和WAF对URL的解析可能存在差异。
      • 添加默认端口：http://localhost:80@attacker.com， 某些解析器会认为主机是 localhost:80，而实际 curl 可能将 @ 前的内容视为认证信息，最终请求 attacker.com。
      • 利用畸形URL：如 http://127.0.0.1:80%20@attacker.com/， http://127.0.0.1%0d%0aHost:attacker.com。

步骤3：进阶防御 - 白名单与DNS重新解析校验

  1. 防御措施：更严格的防护。
    • 白名单域名：只允许请求特定的、可信的域名（如 cdn.example.com）。
    • DNS重新解析校验：在应用程序收到用户输入的URL后，立即解析其主机名得到IP_A，并进行黑名单校验。在服务器发起真实请求前，再次解析同一个主机名得到IP_B，比对IP_A和IP_B。如果不同，则拒绝请求。这旨在防御DNS重绑定。
  2. 绕过技术：
    • 利用白名单域名的子域或路径：如果白名单是 *.example.com，攻击者可尝试 ssrf.evil.com?redirect=https://cdn.example.com， 但更可能是利用白名单域名下的开放重定向漏洞。
    • 利用开放重定向：在白名单域名 trusted.com 上找到一个开放重定向漏洞（如 trusted.com/redirect?url=http://169.254.169.254）。攻击者提交 https://trusted.com/redirect?url=http://169.254.169.254， 通过白名单检查，服务器请求该URL后被重定向到目标元数据地址。
    • 对抗DNS重校验：
      • 如果校验逻辑不严谨（如只校验第一次解析的IP不在黑名单，而不校验第二次解析的IP是否在），则DNS重绑定依然可能成功（首次解析为合法IP，二次解析为内网IP）。
      • 使用 IPv6 地址。黑名单和白名单通常只处理IPv4，内网IPv6地址（如 ::1， fd00::/8）可能被忽略。攻击者可以提交 http://[::1]:80/ 或一个指向 ::1 的域名。

步骤4：终极利用 - 协议滥用与代码执行

  1. 目标：超越信息泄露，实现远程代码执行（RCE）或更深度内网渗透。
  2. 利用技术：
    • 攻击内部脆弱服务：利用SSRF访问内网中存在的已知漏洞服务（如未授权访问的Redis、Memcached、Jenkins等），通过发送特定Payload实现RCE。
    • 利用非HTTP协议（如果未被完全禁用）：
      • file://：读取服务器本地文件（file:///etc/passwd）。
      • gopher://：这是一个非常强大的协议，可以构造任意TCP数据包。攻击者可以用它与内网的Redis、MySQL、SMTP等TCP服务交互，发送命令。例如，构造一个Gopher请求来向Redis写入SSH公钥，从而获取服务器权限。
      • dict://：可以用于端口扫描和有限的信息获取。
    • 攻击FastCGI、HTTP/HTTPS服务内部接口：通过SSRF访问本地的 127.0.0.1:9000 (PHP-FPM) 或 127.0.0.1:8080 (某些管理API)，发送精心构造的Payload来执行命令。
    • 利用CRLF注入：在请求的URL路径或参数中注入 %0d%0a， 从而在服务器发出的请求中插入新的HTTP头，可能用于污染缓存、进行请求走私的初始链，或覆盖Host头攻击内部基于虚拟主机的服务。

步骤5：防御总结与最佳实践

  1. 输入校验：
    • 严格白名单：基于应用业务需求，制定严格的域名或IP白名单，并拒绝一切非白名单请求。
    • 统一解析器：使用同一个URL解析库进行校验和实际请求，避免解析差异。
  2. 网络层控制：
    • 出站防火墙：限制服务器发起的出站连接，只允许访问必要的、已知的外部服务和端口。禁止访问内部RFC 1918地址段、回环地址、云元数据端点等。
    • 使用网络命名空间或容器：将存在SSRF风险的应用组件运行在独立的、网络受限的环境中。
  3. 协议与认证：
    • 禁用不必要的URL协议（file， gopher， dict， ftp 等），只允许 http/https。
    • 对内网服务实施强认证，不要仅依赖网络位置作为信任依据。
  4. 响应处理：
    • 禁止跟随重定向：或者至少对重定向目标也进行同样的白名单校验。
    • 过滤敏感信息：服务器获取远程内容后，在返回给用户前，应检查是否包含敏感信息（如云元数据、错误信息等）。
  5. 沙箱与隔离：将执行网络请求的功能放在一个独立、权限极低的微服务或函数中。

通过以上循序渐进的分析，我们可以看到，SSRF的攻防是一场不断升级的对抗。有效的防御需要从输入验证、网络架构、服务配置多个层面进行纵深部署，而不能仅仅依赖于应用层简单的黑名单过滤。

服务器端请求伪造（SSRF）攻击的进阶利用与防御绕过技术详解 一、 知识点描述 服务器端请求伪造（Server-Side Request Forgery， SSRF）是一种由攻击者构造恶意请求，诱使服务器端应用向攻击者指定的内部或外部资源发起非预期请求的安全漏洞。 进阶利用与防御绕过技术 指的是在目标应用已部署基本防护措施（如黑名单、白名单过滤、DNS解析校验等）的情况下，攻击者通过更隐蔽、更复杂的技术手段，成功利用SSRF漏洞，实现更深层次的攻击目标，例如访问敏感内网服务、进行端口扫描、甚至远程代码执行。 核心危险在于，服务器通常拥有更高的网络权限（可访问防火墙后的内网、云服务元数据接口等），并且其发起的请求可能被内部系统视为“可信流量”，从而绕过某些认证机制。 二、 解题/讲解过程 我们从一个假设的、存在基础SSRF漏洞的场景开始，逐步升级防护措施，并对应讲解攻击者如何绕过。 步骤1：基础SSRF场景与利用 漏洞点 ：一个Web应用提供一个“网页快照”或“URL内容获取”功能。用户提交一个URL（如 https://example.com ），服务器会去获取该URL的内容并返回给用户。 利用 ： 访问内网服务 ：攻击者提交 http://192.168.1.1/admin ，服务器会请求这个内网IP的管理界面。 端口扫描 ：通过观测服务器响应时间或错误信息，判断目标IP的特定端口是否开放（如提交 http://192.168.1.1:22 ）。 访问云元数据 ：在云环境中，服务器可以访问一个特定的内部端点（如AWS的 http://169.254.169.254/latest/meta-data/ ）来获取自身实例的敏感信息（密钥、配置等）。 步骤2：基础防御 - URL协议与地址黑名单 防御措施 ：开发者意识到风险，开始过滤。 禁止使用 http:// 、 https:// 之外的协议（如 file:// 、 gopher:// 、 dict:// 可能被直接禁用）。 将常见内网IP段（ 10.0.0.0/8 ， 172.16.0.0/12 ， 192.168.0.0/16 ）和回环地址（ 127.0.0.1 ， localhost ）加入黑名单。 绕过技术 ： 利用进制、八进制、十六进制或混合表示法 ：IP地址可以多种格式表示，黑名单可能只检查点分十进制格式。 127.0.0.1 -> 2130706433 （十进制）、 0177.0.0.1 （八进制）、 0x7f.0.0.1 （十六进制）、 127.1 （省略后缀零）。 利用域名解析 ： 注册一个指向内网IP的域名（如 attacker-internal.com A记录指向 192.168.1.1 ）。 使用 localtest.me 等公共域名，其解析结果指向 127.0.0.1 。 利用 DNS重绑定攻击 ：攻击者控制一个域名，其TTL极短，第一次解析返回一个允许的外网IP（通过黑名单检查），当服务器真正发起请求时，DNS解析结果已变为目标内网IP。 利用URL解析差异 ：应用程序代码、底层库（如 curl 、 libcurl ）和WAF对URL的解析可能存在差异。 添加默认端口 ： http://localhost:80@attacker.com ， 某些解析器会认为主机是 localhost:80 ，而实际 curl 可能将 @ 前的内容视为认证信息，最终请求 attacker.com 。 利用畸形URL ：如 http://127.0.0.1:80%20@attacker.com/ ， http://127.0.0.1%0d%0aHost:attacker.com 。 步骤3：进阶防御 - 白名单与DNS重新解析校验 防御措施 ：更严格的防护。 白名单域名 ：只允许请求特定的、可信的域名（如 cdn.example.com ）。 DNS重新解析校验 ：在应用程序收到用户输入的URL后，立即解析其主机名得到IP_ A，并进行黑名单校验。在服务器发起真实请求前， 再次 解析同一个主机名得到IP_ B，比对IP_ A和IP_ B。如果不同，则拒绝请求。这旨在防御DNS重绑定。 绕过技术 ： 利用白名单域名的子域或路径 ：如果白名单是 *.example.com ，攻击者可尝试 ssrf.evil.com?redirect=https://cdn.example.com ， 但更可能是利用白名单域名下的开放重定向漏洞。 利用开放重定向 ：在白名单域名 trusted.com 上找到一个开放重定向漏洞（如 trusted.com/redirect?url=http://169.254.169.254 ）。攻击者提交 https://trusted.com/redirect?url=http://169.254.169.254 ， 通过白名单检查，服务器请求该URL后被重定向到目标元数据地址。 对抗DNS重校验 ： 如果校验逻辑不严谨（如只校验第一次解析的IP不在黑名单，而不校验第二次解析的IP是否在），则DNS重绑定依然可能成功（首次解析为合法IP，二次解析为内网IP）。 使用 IPv6 地址。黑名单和白名单通常只处理IPv4，内网IPv6地址（如 ::1 ， fd00::/8 ）可能被忽略。攻击者可以提交 http://[::1]:80/ 或一个指向 ::1 的域名。 步骤4：终极利用 - 协议滥用与代码执行 目标 ：超越信息泄露，实现远程代码执行（RCE）或更深度内网渗透。 利用技术 ： 攻击内部脆弱服务 ：利用SSRF访问内网中存在的已知漏洞服务（如未授权访问的Redis、Memcached、Jenkins等），通过发送特定Payload实现RCE。 利用非HTTP协议 （如果未被完全禁用）： file:// ：读取服务器本地文件（ file:///etc/passwd ）。 gopher:// ：这是一个非常强大的协议，可以构造任意TCP数据包。攻击者可以用它与内网的Redis、MySQL、SMTP等TCP服务交互，发送命令。例如，构造一个Gopher请求来向Redis写入SSH公钥，从而获取服务器权限。 dict:// ：可以用于端口扫描和有限的信息获取。 攻击FastCGI、HTTP/HTTPS服务内部接口 ：通过SSRF访问本地的 127.0.0.1:9000 (PHP-FPM) 或 127.0.0.1:8080 (某些管理API)，发送精心构造的Payload来执行命令。 利用CRLF注入 ：在请求的URL路径或参数中注入 %0d%0a ， 从而在服务器发出的请求中插入新的HTTP头，可能用于污染缓存、进行请求走私的初始链，或覆盖 Host 头攻击内部基于虚拟主机的服务。 步骤5：防御总结与最佳实践 输入校验 ： 严格白名单 ：基于应用业务需求，制定严格的 域名或IP白名单 ，并拒绝一切非白名单请求。 统一解析器 ：使用同一个URL解析库进行校验和实际请求，避免解析差异。 网络层控制 ： 出站防火墙 ：限制服务器发起的出站连接，只允许访问必要的、已知的外部服务和端口。禁止访问内部RFC 1918地址段、回环地址、云元数据端点等。 使用网络命名空间或容器 ：将存在SSRF风险的应用组件运行在独立的、网络受限的环境中。 协议与认证 ： 禁用不必要的URL协议 （ file ， gopher ， dict ， ftp 等），只允许 http / https 。 对内网服务实施强认证 ，不要仅依赖网络位置作为信任依据。 响应处理 ： 禁止跟随重定向 ：或者至少对重定向目标也进行同样的白名单校验。 过滤敏感信息 ：服务器获取远程内容后，在返回给用户前，应检查是否包含敏感信息（如云元数据、错误信息等）。 沙箱与隔离 ：将执行网络请求的功能放在一个独立、权限极低的微服务或函数中。 通过以上循序渐进的分析，我们可以看到，SSRF的攻防是一场不断升级的对抗。有效的防御需要从 输入验证 、 网络架构 、 服务配置 多个层面进行纵深部署，而不能仅仅依赖于应用层简单的黑名单过滤。