服务端请求伪造风险怎么排查：从外部链接抓取到出站访问控制

服务端请求伪造（SSRF）的排查难点，往往不在于“看不懂代码”，而在于“不知道从哪里看起”。很多团队做了网址格式校验、封了常见内网段，却仍然被绕过，原因在于把 SSRF 当成了一个单纯的“输入校验问题”，而忽略了它本质上是“应用层地址校验”与“网络层出站访问控制”的共同缺口。本文以业务功能发起的出站请求为主线，把排查路径拆解为识别入口、梳理网络、验证绕过、实施控制与复核审计五个步骤，帮助你建立一套可落地、可复核的排查方法。

第一步：先盘点哪些功能会由服务器发起请求

SSRF 的根源是“服务器替用户去访问一个地址”。因此排查的第一步，不是翻漏洞报告，而是梳理业务代码里所有由服务端发起的网络请求。常见的功能入口包括：

• 链接预览与分享卡片：用户提交 URL，服务端抓取页面标题、描述或缩略图。
• 远程图片或文件下载：用户提供图片地址，服务端下载后存储或处理。
• Webhook 与回调地址配置：用户在后台填写回调 URL，服务端在事件触发时向其发送请求。
• PDF 生成或截图服务：用户输入网页地址，服务端访问该地址并渲染成 PDF 或图片。
• 导入功能：用户提供 CSV、XML 或 JSON 文件的 URL，服务端拉取后解析。
• 代理或转发接口：某些网关类应用允许用户指定目标地址。

排查时，建议以“用户可控数据最终是否影响请求的 URL、Host、协议或端口”为判断标准。即使代码里做了拼接或二次编码，只要用户输入能影响到最终请求的目标，就属于需要重点核查的范围。

一个实用的做法是，在代码仓库里搜索发起 HTTP 请求的函数调用（如 curl、file_get_contents、requests.get、http.Client.Do 等），然后逐个追踪其 URL 参数的来源。如果 URL 直接或间接来自用户输入、数据库字段或第三方回调数据，就标记为高风险点。

第二步：梳理服务器可访问的网络范围

应用层的 URL 校验只是第一道关卡，网络层的可达性决定了 SSRF 的实际危害半径。同一台服务器，如果部署在公有云上且未做安全组限制，攻击者可以利用 SSRF 访问云元数据服务（如 169.254.169.254）获取临时凭证；如果服务器位于内网，则可能进一步横向探测内网资产。

因此，在排查 SSRF 时，需要同步梳理服务器自身的网络边界：

• 本机回环地址：127.0.0.1、localhost，以及 IPv6 的 ::1。
• 内网保留段：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。
• 云元数据地址：169.254.169.254（AWS、阿里云、腾讯云等均使用该地址）。
• 链路本地地址：169.254.0.0/16 除元数据外的其他地址。
• 特殊解析结果：某些 DNS 解析可能返回内网 IP，例如内部域名或泛解析记录。

这里有一个容易被忽略的点：地址格式的多样性。http://2130706433（十进制表示 127.0.0.1）、http://0x7f000001（十六进制）、http://[::ffff:127.0.0.1]（IPv4 映射的 IPv6 地址）都可能绕过简单的字符串匹配。因此，网络层的访问控制不能依赖应用层的黑名单，而应该在出站网关上做强制限制。

第三步：在授权隔离环境中验证绕过路径

排查 SSRF 不能只在代码层面“看”，还需要在受控环境中实际验证。验证的目的是确认现有的地址校验和网络限制是否真的有效，而不是为了构造攻击载荷。

建议搭建一个隔离的测试环境，具体要求如下：

• 使用独立的测试服务器或容器，与生产环境网络隔离。
• 在测试环境中部署一个简易的“目标服务”，用于记录收到的请求（包括 Host、URI、Headers 等）。
• 准备一组用于测试的地址样本，覆盖合法域名、内网 IP、回环地址、云元数据地址、特殊格式地址、重定向地址等。

验证的重点包括：

1. 地址解析是否被二次校验：应用层校验的是用户输入的字符串，但实际请求可能经过 DNS 解析后指向不同 IP。例如，一个域名首次解析为公网 IP，但攻击者控制 DNS 后二次解析为内网 IP。
2. 重定向是否被跟随：很多 HTTP 客户端默认跟随 30x 重定向。如果应用只校验了初始 URL，但重定向后的目标未校验，就可能被绕过。测试时，可以在自己的测试服务器上配置一个重定向到内网地址的响应。
3. 协议是否被限制：除了 HTTP/HTTPS，某些客户端还支持 file://、gopher://、dict:// 等协议。如果应用未限制协议，攻击者可能读取本地文件或向内网端口发送任意数据。
4. 端口是否被限制：即使目标 IP 被限制，如果允许任意端口，攻击者仍可能向内网服务的非标准端口发起请求。

验证完成后，需要记录每一项测试的结果，形成一份“哪些校验有效、哪些可以被绕过”的清单。这份清单是后续实施加固措施的直接依据。

第四步：实施分层加固，而不是单一校验

基于验证结果，加固措施应该分层实施，确保即使某一层被绕过，后续层仍然有效。

应用层：目标地址白名单

白名单是比黑名单更可靠的方案。对于链接预览、远程图片下载等功能，如果业务上允许访问的域名集合是有限的，应优先使用白名单。白名单的匹配应基于域名后缀而非前缀，例如允许 example.com 应同时匹配 www.example.com 和 api.example.com，但不应匹配 notexample.com。

如果业务确实需要允许用户提交任意公网 URL，则需要配合网络层控制。此时应用层的目标是“减少误报”而非“彻底防御”。

网络层：出站访问控制

网络层是 SSRF 防御的最后一道防线，也是最可靠的一层。具体措施包括：

• 默认拒绝出站流量：在防火墙或安全组中，默认拒绝服务器访问内网网段和云元数据地址，只放行必要的公网出口。
• 限制出站端口：如果业务只需要访问 80 和 443 端口，则在出站规则中仅放行这两个端口。
• 使用代理或专用出口：对于需要访问外部 URL 的功能，可以配置独立的出站代理，在代理层实施域名白名单和协议限制。
• 分离网络平面：将需要发起外部请求的应用与内网核心服务部署在不同的网络分段，减少 SSRF 可触达的范围。

DNS 解析校验

由于 DNS 重绑定攻击的存在，仅校验用户输入的域名是不够的。更稳妥的做法是：在发起请求前进行一次 DNS 解析，检查解析结果是否落在允许的 IP 范围内；如果解析结果包含内网地址，则拒绝请求。但要注意，这并不能完全防御 DNS 重绑定（攻击者可以在首次解析时返回公网 IP，在客户端实际连接时返回内网 IP），因此仍需依赖网络层控制。

重定向处理

对于重定向，有两种处理方式：一是禁止跟随重定向，二是对重定向的目标重新执行同样的校验。前者可能影响正常业务（很多合法页面会做跳转），后者实现复杂度较高。折中方案是：限制重定向次数（如最多 2 次），并且每次重定向都重新检查目标地址。

协议与端口限制

在 HTTP 客户端配置中，明确只允许 http 和 https 协议，并限制可访问的端口。对于 file://、gopher:// 等危险协议，应在客户端层面直接禁用。

第五步：建立审计与监控闭环

加固完成后，还需要建立持续的监控和审计机制，确保新的绕过方式出现时能够及时发现。

关键审计点

• 出站请求日志：记录所有由应用发起的出站请求，包括目标 IP、域名、端口、请求时间、发起用户或会话。日志应至少保留 90 天，并支持按 IP、域名、时间范围检索。
• 异常流量告警：当出站请求的目标 IP 属于内网段、云元数据地址或未在白名单内的域名时，触发告警。
• DNS 解析记录：记录应用发起的 DNS 查询，用于事后追溯是否存在 DNS 重绑定行为。
• 重定向链日志：记录请求经历的重定向链，便于发现“初始合法、最终非法”的绕过路径。

告警规则建议

误拦截的影响与灰度验证

加固措施可能影响正常业务，尤其是以下场景：

• 第三方 API 回调：某些第三方服务（如支付回调、短信通知）的 IP 会变化，如果出站白名单过严，可能导致回调失败。
• 用户上传的合法外链：链接预览功能如果限制了域名白名单，用户分享的合法链接可能无法生成预览。
• 内部服务调用：如果应用需要调用内网的其他服务（如配置中心、认证服务），出站限制可能导致这些调用失败。

因此，在实施网络层限制时，建议采用灰度策略：

1. 先审计后阻断：先开启日志模式，记录所有出站请求，运行 1-2 周，分析哪些流量会被新规则拦截。
2. 按业务维度灰度：先对非核心业务或测试环境应用新规则，观察运行情况。
3. 配置回滚方案：在防火墙或代理配置变更前，保存变更前的配置快照，并制定回滚步骤。一旦发现业务异常，能够在 5 分钟内恢复到变更前状态。
4. 建立白名单申请流程：对于业务确需访问的新域名或 IP，提供快速审批通道，避免因流程繁琐导致业务绕过安全规则。

复盘：从一次排查到一套机制

SSRF 排查不是一次性的“救火”任务，而应该成为安全建设的一部分。完成一次排查后，建议输出以下成果：

• 资产清单：所有由服务器发起请求的功能列表及对应的代码位置。
• 网络边界图：服务器可访问的网络范围、出站控制策略及部署位置。
• 验证报告：在隔离环境中进行的绕过测试结果及结论。
• 加固清单：已实施的加固措施及对应的验证方式。
• 监控规则：出站流量审计和告警的配置说明。

将这些文档纳入安全运营的常规资产，并在每次业务上线涉及出站请求功能时，要求开发团队同步更新资产清单和网络边界图。这样，下一次排查就不再是从零开始，而是基于已有机制的增量验证。

SSRF 的防御没有“一劳永逸”的方案，因为攻击者的绕过技巧和业务的功能演进都在持续变化。但只要你把排查思路从“检查用户输入”扩展到“控制服务器能访问什么”，并且把每一次排查沉淀为可复用的机制，风险就会处于可控范围。记住：应用层的校验决定“能不能访问”，网络层的控制决定“访问了会怎样”，而审计监控决定“被绕过了能否发现”。三者缺一不可。