SSRF 服务端请求伪造与线上安全治理

SSRF 服务端请求伪造与线上安全治理一、业务场景某 Spring Boot 文件管理系统提供 URL 文件预览功能。用户提交图片或文档的 URL后端服务器主动下载文件并生成预览。线上出现以下问题部分用户提交的 URL 无法正常预览。安全团队发现服务器曾经向内网地址发起 HTTP 请求。服务器部署在云环境中可以访问部分内部服务。接口仅校验 URL 是否以http://或https://开头。功能已经上线不能直接关闭。核心任务在保障正常预览业务的前提下修复安全漏洞并建立可持续的安全治理机制。二、什么是 SSRFSSRFServer-Side Request Forgery即服务端请求伪造。它的本质是攻击者利用服务器代为发起请求使服务器访问原本不应该访问的目标。例如正常请求是用户提交 https://example.com/image.png 服务器 下载图片 → 生成预览 → 返回结果但攻击者可能提交http://127.0.0.1:8080/admin http://192.168.1.10/internal http://169.254.169.254/这些地址可能指向服务器本机、内部网络服务或云环境中的元数据服务。实际可访问范围取决于服务器的网络配置、云环境和访问控制策略。为什么仅检查 HTTP/HTTPS 不够下面的代码只能检查协议不能证明访问目标安全。if(url.startsWith(http://)||url.startsWith(https://)){download(url);}攻击者仍然可以使用 HTTP/HTTPS 协议访问危险地址。核心结论协议合法不代表目标地址合法目标地址合法也不代表下载的文件安全。三、SSRF 的主要风险1. 访问内网服务攻击者诱导服务器访问内部管理接口。未暴露在公网的业务服务。内部数据库管理页面。仅允许内网访问的运维系统。服务器可能具有攻击者本身不具备的网络访问权限。2. 访问云元数据服务某些云环境提供实例元数据服务其中可能包含敏感的实例信息或凭证。如果服务器可以访问这些服务SSRF 可能进一步造成敏感信息泄露或权限扩大。3. 利用重定向绕过校验假设系统检查了最初提交的 URL发现目标是公网地址。但是服务器访问该地址后目标返回 HTTP 302将请求重定向到内网地址。如果 HTTP 客户端自动跟随重定向就可能访问原本禁止的目标。因此不能只检查最初的 URL。4. DNS 重绑定与校验时序问题攻击者控制的域名可能在不同时间解析出不同的 IP 地址。例如第一次解析 evil.example → 公网 IP 第二次解析 evil.example → 内网 IP如果应用在第一次解析时检查安全性随后又让 HTTP 客户端独立解析域名并建立连接实际连接目标可能发生变化。这类问题涉及 DNS 重绑定以及校验与使用之间的时序差异。不能通过简单地多解析几次就彻底解决这个问题。5. 下载恶意文件即使目标是公网 IP服务器下载的文件仍然可能存在安全风险。例如恶意文件或伪造格式的文件。超大文件导致磁盘、内存或网络资源耗尽。利用图片、PDF 等解析器漏洞的文件。文件解析过程中触发资源消耗攻击。因此SSRF 防护和文件处理安全是两条不同的防线。四、SSRF 防护方案1. URL 规范化与协议校验对用户提交的 URL 进行严格解析而不是简单地使用字符串前缀判断。需要考虑只允许业务所需的 HTTP/HTTPS 协议。拒绝不符合预期格式的 URL。正确处理主机名、端口和路径。拒绝包含用户信息等不必要或有歧义的 URL 结构。规范化后再执行安全校验。对解析异常和无法明确判断的目标采取拒绝策略。注意字符串过滤、正则表达式和 URL 前缀判断都不能单独作为 SSRF 防护方案。2. DNS 解析与 IP 地址校验解析目标域名对应的 IPv4 和 IPv6 地址并依据明确的网络访问策略进行判断。通常需要拒绝未经授权的环回地址。私有网络地址。链路本地地址。未指定地址。多播地址。其他特殊用途或组织内部禁止访问的地址段。不能只检查一个解析结果而忽略其他结果。也不能简单地认为所有公网 IP 都安全。企业内部可能还有额外的禁止访问网段和敏感服务。3. 将校验结果与实际连接绑定这是防止 DNS 重绑定的重要措施。不安全的做法checkPublicIp(host);httpClient.get(url);因为 HTTP 客户端可能重新解析域名。更可靠的设计是解析域名。校验所有相关解析结果。选择经过验证的目标 IP。确保实际 TCP 连接使用该 IP。同时正确保留 HTTP Host 和 HTTPS TLS SNI、证书校验等行为。防止连接过程中通过重定向或其他机制访问未经校验的目标。具体实现取决于使用的 HTTP 客户端或代理架构必须确认连接目标确实受到约束而不是只在业务代码中检查了一次 IP。4. 控制 HTTP 重定向优先考虑禁止自动重定向。如果业务必须支持重定向则每次跳转都应重新执行完整的 URL、DNS 和目标 IP 校验并限制最大跳转次数。不能因为初始 URL 安全就信任后续所有跳转。5. 使用网络层隔离不能把安全责任全部放在 Java 代码中。还应考虑出站防火墙。容器网络策略。云安全组与路由策略。安全出站代理。对云元数据地址和内部服务网段的访问限制。即使应用层校验出现遗漏网络层也应尽可能阻止服务器访问敏感资源。需要注意如果采用代理代理自身也必须执行目标地址校验避免把 SSRF 风险转移到代理上。6. 文件下载与解析安全对下载内容实施独立的安全控制限制最大下载大小。设置连接超时和读取超时。限制并发数和总资源消耗。检查实际文件格式不仅依赖 URL 后缀或Content-Type。使用安全、及时更新的文件解析库。对高风险解析任务使用隔离环境。不执行下载的文件。限制临时文件存储权限和清理策略。五、业务权限控制与网络访问控制两类控制的目标不同不能互相替代。控制类型解决的问题示例业务权限控制用户是否有权使用功能或访问指定文件登录校验、资源归属校验网络访问控制服务器是否允许访问目标地址禁止访问内网、云元数据地址文件安全控制下载的文件是否能被安全处理文件格式校验、大小限制、隔离解析资源保护请求是否会耗尽服务器资源超时、并发限制、限流一个用户即使有权使用文件预览功能也不意味着他有权让服务器访问任意内部服务。六、已上线系统的应急治理线上安全问题不能只考虑最终方案还要考虑从发现漏洞到彻底修复之间的风险。第一阶段快速降低风险优先采用能够快速部署的防护措施在网络出口阻止访问敏感内部网段和云元数据服务。禁止自动重定向或者严格限制重定向目标。加入目标 IP 校验覆盖 IPv4、IPv6 和相关特殊地址。根据风险情况临时限制高风险目标或启用可信域名白名单。限制下载大小、超时时间和并发量。增加 SSRF 拦截日志与异常告警。如果业务要求访问任意外部网站就不能长期依赖固定域名白名单作为唯一方案应逐步完善通用目标校验和连接层控制。第二阶段建立可热更新的安全策略把适合配置化的规则与业务代码解耦。可以考虑以下配置项配置项示例允许的协议HTTP/HTTPS禁止访问的网段内部网段、特殊用途地址域名规则允许列表、临时封禁列表重定向策略禁止或逐跳校验下载限制文件大小、超时时间并发限制单实例或全局并发上限功能开关暂停高风险预览能力配置可放在配置中心或数据库中并提供受控的管理接口。需要配套配置格式和语义校验。发布权限控制。操作审计。配置版本管理。快速回滚。配置更新失败时的安全默认行为。可热更新不等于可以随意关闭安全校验。热更新主要解决策略调整速度不能替代可靠的连接目标约束和网络隔离。七、灰度发布与配置变更治理一次规则更新可能误拦截正常业务因此不能直接对全量请求生效。推荐流程1. 预检在发布前检查配置是否合法。规则之间是否存在冲突。IPv4、IPv6 等边界条件是否覆盖。是否误伤已知正常业务。是否正确拦截已知危险目标。可以使用历史请求样本、自动化测试和安全测试验证规则。注意历史请求只能用于验证不代表未来请求一定安全。2. 小范围灰度让小部分实例或请求使用新策略观察预览成功率。不同错误类型的失败率。安全规则拦截率。请求耗时与超时率。内网访问拦截告警。灰度期间不能让未经验证的请求绕过已有安全防护。3. 逐步扩大满足预先设定的安全与业务指标后再逐步扩大覆盖范围。如果指标异常应暂停扩量而不是继续全量发布。4. 回滚或修复保留经过验证的配置版本支持快速回滚。但是回滚时不能因为业务成功率下降就恢复到已知存在 SSRF 风险的旧策略。必要时应暂时限制部分预览能力而不是开放内部网络访问。八、限流、熔断、降级分别解决什么问题机制主要目的在本场景中的用途限流控制请求进入的速度防止下载请求过多保护网络和服务器资源并发限制控制同时执行的任务数量避免大量下载任务同时占用连接、线程和内存熔断依赖持续异常时暂时停止请求避免外部站点故障引起资源持续消耗降级在异常时减少非核心功能暂停高风险来源或部分预览能力灰度发布控制新规则的影响范围避免错误配置影响全部用户回滚恢复到经过验证的配置版本快速撤销错误变更要牢记限流、熔断、降级主要保护系统可用性不能替代 SSRF 安全校验。如果一个 URL 指向内网哪怕请求量只有每秒一次也依然可能造成安全问题。九、如何判断是否应该继续灰度假设新规则发布后正常图片预览成功率从 99% 降到 95%。SSRF 风险请求的拦截率明显提升。暂时没有发现内网访问告警。不能只凭这些指标就决定继续发布或回滚。正确的处理流程暂停灰度扩量避免影响进一步扩大。按错误类型分析失败请求。区分正常请求误拦截、外部服务故障、DNS 异常、超时、文件格式校验失败等原因。检查新旧规则版本和具体命中情况。根据分析结果修复规则、调整适用范围或回滚错误配置。验证安全保护仍然有效后再决定是否恢复灰度。需要观察的指标指标分析目标预览成功率判断业务影响安全规则拦截率判断策略影响范围各类失败原因定位误拦截或外部故障请求耗时和超时率发现性能或网络问题内网访问拦截告警判断防护是否生效文件下载大小和并发量监控资源消耗日志应记录规则版本、失败阶段、目标地址分类和错误类型并避免记录 URL 中的敏感参数、凭证等信息。一个重要原则业务成功率下降不一定代表安全规则有问题。安全拦截率上升也不一定代表规则完全正确。必须结合具体请求、错误类型、安全测试和网络层日志共同判断。十、常见错误方案错误一只检查 URL 前缀HTTP/HTTPS 只代表协议不代表访问目标安全。错误二只校验用户权限用户有权使用预览功能不意味着服务器可以访问任意地址。错误三多解析几次 DNS 就安全了如果校验与实际连接使用不同的解析结果风险仍然存在。关键是让实际连接受到验证结果的约束。错误四只检查公网 IP公网目标仍可能通过重定向、DNS 变化等方式绕过初始校验也可能提供恶意文件。错误五只依赖域名白名单域名白名单可以缩小风险范围但仍要处理 DNS 解析、重定向、连接目标和白名单配置错误等问题。错误六为了恢复业务直接关闭安全规则业务恢复不能以重新暴露已知安全风险为代价。错误七认为限流和熔断可以防止 SSRF限流和熔断控制的是请求量与故障传播不负责判断目标地址是否合法。十一、最终架构设计推荐将整个功能拆分为以下职责用户请求 | v 业务认证与资源权限校验 | v URL 规范化与协议校验 | v DNS 解析与目标 IP 校验 | v 受控 HTTP 客户端 / 安全出站代理 | -- 连接目标约束 -- 重定向逐跳校验 -- 超时与并发限制 | v 文件大小与格式校验 | v 隔离的文件解析与预览生成 | v 返回预览结果贯穿整个链路的基础设施配置中心与策略版本管理。网络出口访问控制。限流、熔断和降级。监控、日志和安全告警。灰度发布与配置回滚。最终目标不是增加尽可能多的校验代码而是建立多层防御某一层出现遗漏时其他层仍然能够限制风险。十二、本篇核心总结SSRF 的核心是攻击者诱导服务器访问未经授权的目标。用户权限、网络访问控制和文件安全是不同的防线。URL 前缀校验、公网 IP 判断都不足以独立解决 SSRF。DNS 校验必须与实际连接目标绑定并正确处理重定向。网络出口隔离是应用层防护的重要补充。文件下载后仍需进行大小、格式和安全解析控制。安全规则应支持配置管理、版本审计、灰度和回滚。限流、熔断、降级解决可用性问题不能替代安全校验。发现业务成功率下降时应暂停扩量、定位原因再决定修复或回滚。回滚不能恢复到已知存在安全漏洞的状态。架构师思维不仅要考虑如何阻止攻击还要考虑规则如何更新、故障如何定位、变更如何控制以及发生问题时如何安全恢复。