1. 项目概述：为什么SSRF是渗透测试中的“瑞士军刀”？
在渗透测试和红队评估的实战中，我们常常会遇到各种漏洞，但有一种漏洞因其独特的“桥梁”作用，常被资深安全研究员称为“瑞士军刀”——这就是SSRF（Server-Side Request Forgery，服务器端请求伪造）。简单来说，SSRF就是攻击者能够诱使服务器（后端应用）向攻击者指定的任意地址发起HTTP请求。这听起来似乎平平无奇，不就是让服务器发个请求吗？但它的威力恰恰在于此：它让攻击者能够以服务器的身份和网络权限去“窥探”或“触碰”那些原本遥不可及的内部系统。
想象一下，你是一个外部攻击者，面对一个坚固的堡垒（企业内网），所有入口都有重兵把守。SSRF就像是你成功策反了堡垒内部的一个信使（存在漏洞的Web应用）。这个信使可以自由出入堡垒的各个房间（内部网络），你可以命令他去查看机密文件（访问内网服务）、打开后门（攻击内部系统）或者向外传递情报（数据外泄）。这个漏洞的可怕之处在于，它绕过了所有针对外部攻击者的网络边界防护，如防火墙、WAF（Web应用防火墙），直接从受信任的内部发起攻击。
我处理过不少案例，一个看似无害的“在线URL预览”、“文档转换”或者“从指定链接拉取头像”功能，背后就藏着SSRF的隐患。攻击者只需提交一个指向
http://127.0.0.1:8080/admin
的链接，就可能直接访问到本该只有管理员才能触及的后台。更危险的是，利用一些协议技巧，攻击者甚至能读取服务器本地文件、扫描内网端口、或与云服务元数据接口交互，从而窃取凭证、实现权限提升。因此，深入理解SSRF的原理、攻击手法和防御策略，对于开发、运维和安全人员都至关重要。
2. SSRF漏洞的核心原理与攻击面拆解
要防御SSRF，必须先透彻理解它的攻击原理。SSRF的本质是
应用程序未对用户提供的URL参数进行充分验证、过滤和限制
，导致服务器端代码（如PHP的
file_get_contents()
、
curl_exec()
，Python的
requests.get()
，Java的
HttpURLConnection
等）按照攻击者构造的恶意URL发起网络请求。
2.1 漏洞产生的典型代码模式
几乎所有SSRF漏洞都源于类似的代码模式。我们来看几个最常见的“反面教材”。
场景一：无任何过滤的直接请求
// PHP 示例
$url = $_GET['url']; // 用户直接控制输入
$data = file_get_contents($url);
echo $data;
这段代码毫无防备，攻击者可以将
url
参数设置为
file:///etc/passwd
来读取系统文件，或者设置为
http://169.254.169.254/latest/meta-data/
来访问AWS云服务器的元数据。
场景二：基于“域名白名单”的脆弱校验
# Python Flask 示例
from flask import request
import requests
url = request.args.get('image_url')
if 'example.com' in url: # 脆弱的字符串包含检查
resp = requests.get(url)
return resp.content
else:
return 'Domain not allowed'
这种检查极易绕过。攻击者可以构造
http://evil.com?example.com
或使用
http://example.com@evil.com/
（利用
@
语法）来欺骗检查逻辑。
场景三：解析与请求分离导致的绕过
有时应用会先解析URL获取主机名，进行白名单校验，然后再用原始URL字符串发起请求。如果解析库（如
urlparse
）和请求库（如
requests
）对URL的处理存在差异，就可能产生绕过。
import urllib.parse
import requests
def fetch_url(https://blog.csdn.net/user_input):
parsed = urllib.parse.urlparse(user_input)
if parsed.hostname in ['safe.com', 'cdn.safe.com']: # 校验解析后的hostname
# 但这里使用了原始的用户输入发起请求！
r = requests.get(user_input, timeout=5)
return r.text
return 'Forbidden'
攻击者可以提交
http://safe.com@evil.com/
。
urlparse
可能会将
safe.com
解析为用户名部分，而
requests
库却可能将其解释为访问
evil.com
，从而导致白名单被绕过。
2.2 关键攻击向量与协议利用
SSRF的攻击威力很大程度上取决于服务器支持哪些URL协议（Schema）。除了常见的
http://
和
https://
，许多编程语言的网络库还支持其他协议，这为攻击者打开了更多扇门。
-
file://协议 ：用于访问本地文件系统。file:///etc/passwd可以读取Linux系统密码文件（尽管是哈希），file:///C:/Windows/System32/drivers/etc/hosts可以读取Windows主机文件。这是信息泄露的直接通道。 -
dict://协议 ：允许攻击者向服务器上的任意端口发送命令，通常用于探测端口服务和获取横幅信息。例如，dict://127.0.0.1:6379/info可能用来探测Redis服务，如果Redis未授权，甚至能直接执行命令。 -
gopher://协议 ：一个非常古老但功能强大的协议，它可以构造任意格式的TCP数据包。在SSRF中，Gopher常被用作“协议转换器”，攻击者可以利用它向支持的其他协议（如Redis、MySQL、Memcached）发送精心构造的Payload，实现远程命令执行或数据篡改。这是SSRF攻击升级为RCE（远程代码执行）的关键跳板。 -
ldap:///ldaps:///tftp://等 ：这些协议可能用于攻击内部的基础服务。
注意 ：不同语言、不同库对协议的支持程度不同。例如，PHP的
cURL和file_get_contents()支持非常广泛的协议，而Python的requests库默认只支持HTTP/HTTPS，但底层如果使用urllib或某些旧版本，情况可能更复杂。在评估风险时，必须结合应用实际使用的网络库来分析。
2.3 目标：从信息泄露到远程命令执行
SSRF的攻击目标通常是多层次的，像一个漏斗，从信息收集逐步深入。
-
信息收集与内网探测
：这是最基本的一步。攻击者利用SSRF作为代理，扫描服务器本机（
127.0.0.1）或内网（如192.168.1.0/24网段）的开放端口。通过响应时间、错误信息或返回的横幅，可以识别出内部运行的服务，如Redis（6379）、MySQL（3306）、MongoDB（27017）、内网管理后台（8080）等。 -
访问敏感服务与数据
：一旦发现服务，攻击者可以直接与之交互。例如，访问本机的
http://127.0.0.1:8080/actuator/health可能暴露Spring Boot应用的监控信息；访问未授权访问的Redis服务，可以读取或写入数据。 -
与云元数据服务交互
：在云环境（AWS、Azure、GCP、阿里云等）中，实例内部可以通过一个特殊的内部地址（如AWS的
169.254.169.254）访问元数据服务，获取临时安全凭证、角色信息等。通过SSRF访问这些接口，攻击者可以窃取云服务器的访问密钥，进而控制整个云资源，危害性极大。 -
协议滥用与RCE
：这是SSRF攻击的“高阶形态”。通过
gopher://或dict://等协议，向内部服务发送精心构造的Payload。例如，向未授权Redis服务发送命令，将SSRF的HTTP请求转换为Redis协议格式，从而在Redis中写入Webshell或计划任务，最终在服务器上执行任意命令。
3. 实战演练：手动挖掘与自动化利用SSRF
理解了原理，我们进入实战环节。我将以一个模拟的“在线文档转换器”应用为例，带你走完从漏洞发现到深度利用的全过程。假设该应用提供一个功能：用户提交一个在线PDF的URL，服务器将其转换为图片。
3.1 漏洞发现与初步验证
首先，我们需要找到可能存在SSRF的功能点。关注所有接受URL作为输入的功能：
- 头像、图片、文件的外链加载。
- 数据导入/导出（从URL导入）。
- 网页抓取、预览、转码服务。
- 调用第三方API的代理功能。
- 任何提示“请输入网址”的地方。
步骤1：基础探测 我们向目标功能提交一个指向自己控制的Burp Collaborator服务器（或类似DNSLog、RequestBin等外带平台）的URL。
POST /convert HTTP/1.1
...
pdf_url=http://your-burp-collaborator-domain.com
如果不久后，在你的Collaborator控制台收到了来自目标服务器的HTTP请求，那么恭喜，一个基本的SSRF漏洞就存在了。这证明了服务器确实会向任意外部地址发起请求。
步骤2：协议探测与内网扫描 确认漏洞存在后，开始探测服务器支持的协议和内部网络环境。
-
本地文件读取
：尝试
file:///etc/passwd。观察响应是返回了文件内容，还是报错。如果返回内容，危害等级立刻提升。 -
环回地址访问
：尝试
http://127.0.0.1:80，http://localhost:8080等。通过变化端口号（如从22, 80, 443, 8080, 6379, 27017等常见端口），根据响应时间、长度或错误信息判断端口开放情况。例如，连接被立即拒绝（Connection refused）通常意味着端口关闭；连接超时可能意味着有防火墙；返回特定HTTP错误或服务横幅则意味着端口开放。 -
短域名或数字IP绕过
：有些防御会检查
localhost、127.0.0.1等关键字。可以尝试其变体：-
127.0.0.1的十进制表示：2130706433 -
127.0.0.1的八进制表示：0177.0.0.1 -
127.0.0.1的十六进制表示：0x7f000001 -
localhost的指向：127.0.0.1.nip.io(nip.io会将127.0.0.1.nip.io解析到127.0.0.1)
-
-
利用URL解析差异
：如前所述，尝试使用
@、#等符号。例如：http://expected-host@evil-host/。
3.2 利用工具提升效率：SSRFmap与Gopherus
手动探测虽然有效，但效率较低。在授权测试中，我们可以借助一些优秀的开源工具。
SSRFmap 这是一个功能强大的自动化SSRF利用框架。它不仅能自动探测内网，还能针对发现的特定服务（如Redis, Postgres, FTP等）自动生成攻击Payload。
python3 ssrfmap.py -r request.txt -p url -m portscan -l 80,443,8080,6379
-
-r request.txt: 包含原始HTTP请求的文件，其中漏洞点用§URL§标记。 -
-p url: 指定包含Payload的参数名。 -
-m portscan: 使用端口扫描模块。 -
-l: 指定要扫描的端口列表。
SSRFmap会自动化替换Payload，发送请求，并根据响应分析端口状态，大大提高了内网测绘的效率。
Gopherus 当发现内部存在未授权访问的Redis服务时，Gopherus是神器。它专门用于生成利用Gopher协议攻击Redis、MySQL、FastCGI等服务的Payload。
python gopherus.py --exploit redis
工具会交互式地引导你输入想执行的命令（如写入Webshell），并最终生成一个
gopher://...
格式的超长URL。将这个URL通过SSRF漏洞提交给服务器，服务器会将其作为Gopher请求发送给内部的Redis，从而执行命令。
实操心得 ：工具虽好，但不可盲目依赖。尤其是在生产环境测试时，自动化工具可能产生大量请求，触发告警。我的习惯是，先用工具快速摸清大致情况（如哪些网段存活），然后针对性地手动验证和利用关键服务。同时，要深刻理解工具生成的Payload原理，这样才能在遇到WAF或特殊过滤时，自己动手修改和绕过。
3.3 云环境下的致命攻击：元数据服务利用
云服务器上的SSRF危害性成倍增加。以AWS EC2为例，其元数据服务地址为
http://169.254.169.254/
。通过SSRF访问这个地址，可以获取到实例的敏感信息。
攻击路径：
-
直接访问根目录：
http://169.254.169.254/latest/meta-data/。这会返回一个目录列表。 -
逐步深入，获取IAM角色信息：
http://169.254.169.254/latest/meta-data/iam/security-credentials/。 -
如果实例附加了IAM角色，上一步会返回角色名。继续访问
http://169.254.169.254/latest/meta-data/iam/security-credentials/[角色名]，即可拿到包含AccessKeyId、SecretAccessKey和Token的临时凭证。 - 使用这些凭证，通过AWS CLI或SDK，攻击者就可以以该实例的角色权限操作云上资源，如读写S3存储桶、启动/终止实例等。
防御视角 ：云厂商也意识到了这个风险。例如，AWS IMDSv2（元数据服务第二版）引入了会话令牌和请求头校验，增加了利用难度。但许多旧实例或未升级配置的实例仍在使用IMDSv1，风险依旧存在。
4. 从开发到运维：构建纵深SSRF防御体系
防御SSRF需要开发、安全和运维团队协同，在软件开发生命周期（SDLC）的各个阶段建立防线。
4.1 开发层：输入处理与网络请求的“白名单”哲学
这是最根本的一层，核心思想是“默认拒绝，显式允许”。
1. 实施严格的URL校验与过滤
-
方案选择
：优先使用
白名单
，而非黑名单。只允许访问已知、可信的域名或IP范围。例如，一个图片处理服务，只允许从
cdn.company.com和static.trusted-partner.com拉取资源。 -
代码示例（Python改进版）
：
from urllib.parse import urlparse import requests ALLOWED_DOMAINS = {'cdn.yourcompany.com', 'images.trustedvendor.com'} ALLOWED_SCHEMES = {'http', 'https'} # 只允许HTTP/S def safe_fetch_url(https://blog.csdn.net/user_url): try: parsed = urlparse(user_url) # 校验协议 if parsed.scheme not in ALLOWED_SCHEMES: raise ValueError(f"Scheme '{parsed.scheme}' not allowed.") # 校验域名（处理子域名） if not any(parsed.netloc.endswith('.' + domain) or parsed.netloc == domain for domain in ALLOWED_DOMAINS): raise ValueError(f"Domain '{parsed.netloc}' not in allow list.") # 解析后重新构建URL，防止解析差异 safe_url = parsed.geturl() # 可以进一步解析hostname进行DNS解析，确保解析出的IP也在允许范围内 response = requests.get(safe_url, timeout=5) response.raise_for_status() return response.content except (ValueError, requests.RequestException) as e: log_security_event(f"SSRF attempt blocked: {user_url}, error: {e}") return None -
关键点
：使用权威的URL解析库（如Python的
urllib.parse， Java的java.net.URI），避免使用正则表达式等不严谨的方法。校验后， 使用解析后的组件重新构建URL ，而不是直接使用用户输入，这能有效防止@、#等绕过。
2. 禁用危险的URL协议
在应用层或使用的网络客户端库中，显式禁用不需要的协议。例如，如果你的应用只需要HTTP/HTTPS，就确保
file://
、
gopher://
、
dict://
、
ldap://
等协议无法被使用。
-
对于PHP
：检查并限制
allow_url_fopen和allow_url_include的配置。 -
对于libcurl
：在初始化cURL句柄时，使用
CURLOPT_PROTOCOLS和CURLOPT_REDIR_PROTOCOLS选项严格限制允许的协议。
3. 统一出口网关与请求代理 对于必须从服务器发起对外请求的场景，可以部署一个统一的、安全配置的HTTP代理网关。所有后端服务的出站请求都必须经过这个网关。在网关上实施统一的策略：域名白名单、协议限制、速率限制、DNS重绑定防护等。这样可以将安全策略集中管理，避免在每个应用里重复实现。
4.2 网络层：最小权限与隔离
开发层的防御可能被绕过（如0day漏洞），因此需要网络层提供纵深防御。
1. 网络分段与微隔离
- 原则 ：遵循最小权限原则，将服务器划分到不同的网络段（VPC、子网）。
-
实施
：Web应用服务器所在的子网，其出站规则应严格限制。除了必须访问的少数外部API（如支付网关、短信服务）和内部特定服务（如数据库）外，禁止访问其他任何内部网段（尤其是管理网段）和云元数据服务（
169.254.169.254等）。在安全组或防火墙规则中，明确拒绝到环回地址（127.0.0.0/8）和私有地址空间（10.0.0.0/8,172.16.0.0/12,192.168.0.0/16）的非必要流量。
2. 使用非路由元数据服务 对于云环境，积极采用云厂商提供的最新安全特性。例如，将AWS EC2的元数据服务升级到 IMDSv2 ，它要求先通过PUT请求获取一个有时间限制的令牌，才能在后续的GET请求中使用，这能有效防御简单的SSRF读取。此外，一些云平台允许为实例配置 专用主机名 来替代IP访问元数据，或通过安全代理访问。
4.3 响应处理：避免信息泄露
即使恶意请求被发出，我们也可以通过处理响应来减少损失。
- 屏蔽错误详情 ：确保应用程序不会将后端请求产生的详细错误信息（如连接失败的具体原因、端口状态、服务横幅）直接返回给用户。应返回统一的、模糊的错误信息，如“处理失败”。
- 过滤敏感响应内容 ：对于代理类功能，如果返回目标URL的内容，应检查响应中是否包含敏感信息（如云元数据、内部系统页面）。可以考虑只返回经过处理的内容（如只提取文本，不返回原始HTML），或者直接禁止返回非白名单域名的原始内容。
4.4 高级防御：应对DNS重绑定攻击
DNS重绑定是一种高级的SSRF绕过技术。攻击者控制一个域名，其TTL极短，第一次解析时返回一个合法的、通过白名单校验的外网IP；但在服务器发起请求时，DNS记录已变更为一个内网IP（如
192.168.1.1
）。由于某些HTTP客户端库会复用DNS解析结果，或者服务器与客户端DNS解析存在时间差，导致请求最终发往了内网地址。
防御措施：
- 应用程序层 ：在解析URL后，立即对获取到的IP地址进行校验，判断是否属于内网IP段。如果属于，则拒绝请求。 注意 ：这个校验必须在每次发起请求前进行，不能依赖首次解析的结果。
-
使用固定DNS解析
：在发起请求前，先解析域名获取IP，校验IP是否合法。然后，在发起实际HTTP请求时，使用获取到的IP地址直接连接，并通过
Host头指定原始域名。这需要HTTP客户端的支持。 - 网络层 ：配置主机或容器使用固定的、可信的DNS服务器，并禁止缓存TTL极短的DNS记录。
5. 防御策略落地与持续验证
设计好防御方案只是第一步，如何确保其持续有效更为关键。
5.1 安全编码规范与组件管理
- 将SSRF防御写入安全编码规范 ：明确要求所有涉及外部资源引用的功能点，必须经过安全评审，并使用统一的、经过安全加固的HTTP客户端工具类。
- 管理第三方库 ：定期盘点项目中使用的网络请求库（如OkHttp, Apache HttpClient, requests等），关注其安全更新。有些库的新版本提供了更便捷的安全配置选项。
5.2 自动化安全测试与监控
-
SAST（静态应用安全测试）
：在CI/CD流水线中集成SAST工具，其规则库应能检测出常见的SSRF代码模式，如未经验证的用户输入直接传递给
URLConnection、HttpClient等。 - DAST（动态应用安全测试） / 漏洞扫描 ：定期使用Burp Suite、Acunetix等工具或商业漏洞扫描器对应用进行扫描，配置扫描策略包含SSRF测试用例。
- 交互式安全测试（IAST） ：在测试环境中部署IAST探针，可以在测试人员操作过程中实时发现潜在的SSRF漏洞，并提供详细的代码定位。
-
RASP（运行时应用自我保护）
：在生产环境中部署RASP，可以在漏洞被利用时实时拦截恶意请求。例如，RASP可以监控到应用程序试图通过
file://协议读取/etc/passwd或访问169.254.169.254的行为，并立即阻断，同时告警。 - 网络流量监控 ：监控服务器出站流量，特别是向私有IP地址和已知云元数据地址发起的异常连接请求，这可能是SSRF攻击成功的迹象。
5.3 事件响应与复盘
尽管有层层防御，仍需做好被攻破的准备。制定针对SSRF的安全事件响应预案：
- 即时遏制 ：一旦发现SSRF攻击，立即通过WAF或防火墙策略临时封禁攻击源IP，并对疑似被利用的应用接口进行下线或熔断处理。
-
影响评估
：
- 检查服务器日志，确定攻击者尝试访问了哪些内部地址和端口。
- 检查被扫描或访问的内部服务（如Redis、数据库、管理后台）的日志，确认是否有未授权的成功访问或数据泄露。
- 如果涉及云环境，立即轮换实例的IAM角色凭证，并审查云审计日志（如AWS CloudTrail），查看攻击者是否利用窃取的凭证进行了其他操作。
- 漏洞修复 ：根据攻击路径，彻底修复漏洞。不仅仅是修补有问题的代码，还要审视整个防御体系是否存在短板，如网络策略是否过宽、元数据服务是否未升级等。
- 复盘与改进 ：召开复盘会议，分析漏洞为何能绕过现有防线，更新安全编码规范、测试用例和监控告警规则，防止同类问题再次发生。
SSRF的攻防是一场持续的博弈。攻击手法在进化（如利用新的协议、更巧妙的绕过技巧），防御体系也需要不断迭代。对于企业和安全从业者而言，建立以“身份验证、最小权限、输入校验、输出过滤”为核心的安全基础，结合覆盖开发、部署、运行全生命周期的安全实践，才能有效驾驭这把“双刃剑”，在享受Web应用便利的同时，筑牢内部网络的安全防线。
扫一扫
14万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
