首页/资讯中心/详情

Java SSRF漏洞深度解析：从原理到实战防御

Java SSRF漏洞深度解析：从原理到实战防御
📅 发布时间：2026/6/22 7:12:48

1. 项目概述：为什么Java开发者必须掌握SSRF审计？

在Java应用安全领域，SSRF（Server-Side Request Forgery，服务端请求伪造）是一个既古老又极具生命力的高危漏洞。说它古老，是因为其原理自Web服务诞生之初就存在；说它有生命力，是因为在微服务、云原生架构大行其道的今天，SSRF的攻击面不仅没有缩小，反而因为内部网络的可信性而变得更加危险。我见过太多因为一个不起眼的URL参数校验不严，导致整个内网被渗透的案例。对于Java开发者而言，无论是做业务开发、架构设计，还是专职安全，深入理解SSRF的原理、挖掘手法和修复方案，都是一项绕不开的核心技能。

这篇文章的目标，就是带你从零开始，彻底吃透Java环境下的SSRF。我不会只给你讲理论，而是会结合真实的代码片段、常见的开发框架（如HttpURLConnection、Apache HttpClient、OkHttp、Spring的RestTemplate）以及我这些年审计中遇到的“奇葩”案例，把漏洞成因、利用技巧、绕过手段和根治方法掰开揉碎了讲清楚。无论你是刚入门安全的新手，还是想深化Java代码审计能力的资深工程师，收藏这一篇，足以构建起关于SSRF的完整知识体系和实战能力。

2. SSRF漏洞核心原理与Java中的典型场景

2.1 SSRF到底是什么？一个生活化的比喻

你可以把SSRF想象成你让一个非常听话但缺乏判断力的秘书（服务器端应用）去帮你办事。你告诉秘书：“去档案室（内网）把XX文件拿来”，或者“去楼下邮局（外部服务）寄封信”。正常情况下，秘书会照办。但如果有坏人欺骗了你，给你一张纸条，上面写着“去金库把保险箱搬来”，而你又没检查纸条内容就直接交给了秘书，那么这位听话的秘书就会真的试图去金库——这就是SSRF。

在技术层面，SSRF指的是攻击者能够诱使服务器端应用向攻击者指定的任意地址发起HTTP请求。由于这个请求是从服务器内部发起的，它可能访问到以下敏感资源：

  1. 服务器本机内部服务：如127.0.0.1:8080的管理后台。
  2. 内网其他系统：如数据库（192.168.1.10:3306）、Redis（192.168.1.20:6379）、Consul/Nacos等配置中心。
  3. 云服务元数据接口：如AWS的169.254.169.254、阿里云的100.100.100.200，这些接口可能返回实例的敏感信息，甚至临时凭证。
  4. 攻击者控制的服务器：用于端口扫描、信息收集，或者结合其他漏洞进行利用。

2.2 Java中引发SSRF的“罪魁祸首”代码模式

Java中导致SSRF的代码模式非常集中，主要围绕几个用于发起HTTP请求的类库。理解它们是审计的第一步。

2.2.1 原生HttpURLConnection：最经典的陷阱

这是Java标准库自带的网络请求工具，因其简单而广泛存在于历史代码和老旧系统中。

// 漏洞代码示例 String url = request.getParameter("url"); // 用户完全可控的输入 URL u = new URL(url); HttpURLConnection conn = (HttpURLConnection) u.openConnection(); // ... 读取conn.getInputStream()并返回给用户

这段代码的问题一目了然：直接从用户参数url构造URL对象并发起连接，没有任何校验。攻击者可以传入file:///etc/passwd尝试读取服务器文件，或者传入http://169.254.169.254/latest/meta-data/来获取云服务器元数据。

注意：HttpURLConnection默认会跟随重定向（HttpURLConnection.setInstanceFollowRedirects(true)）。这意味着如果攻击者传入一个会返回302重定向到内网地址的URL，请求依然会被发往内网，这是常见的绕过姿势之一。

2.2.2 Apache HttpClient：功能强大，配置不当更危险

Apache HttpClient提供了更丰富的功能（连接池、重试机制、认证等），但不当配置会引入更多风险点。

// 漏洞代码示例 String url = request.getParameter("url"); try (CloseableHttpClient client = HttpClients.createDefault()) { HttpGet get = new HttpGet(url); // 危险！ try (CloseableHttpResponse response = client.execute(get)) { // 处理响应 } }

除了直接传入URL，HttpClient的风险还在于其RequestConfig的配置。例如，如果设置了setCircularRedirectsAllowed(true)且未对重定向目标进行校验，风险会加倍。

2.2.3 OkHttp：现代开发中的常见选择

OkHttp是Android和现代Java服务端的流行选择，其API设计同样可能埋下隐患。

// 漏洞代码示例 String url = request.getParameter("url"); OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder().url(url).build(); // 危险！ try (Response response = client.newCall(request).execute()) { // 处理响应 }

OkHttp默认不跟随重定向（需要显式配置），但这并不意味着安全。它同样支持file://、ftp://等协议，攻击面依然存在。

2.2.4 Spring RestTemplate：框架下的疏忽

Spring的RestTemplate极大简化了HTTP调用，但也容易让开发者放松警惕。

// 漏洞代码示例 @GetMapping("/fetch") public String fetchData(@RequestParam String url) { RestTemplate restTemplate = new RestTemplate(); return restTemplate.getForObject(url, String.class); // 危险！ }

RestTemplate底层通常使用SimpleClientHttpRequestFactory，它基于HttpURLConnection，因此继承了其所有安全问题。更隐蔽的是，如果项目中引入了Apache HttpClient或OkHttp的依赖，Spring可能会自动使用它们作为底层实现，使得审计时需要追溯更深。

2.2.5 其他常见触发点

  • XML解析：处理外部实体（XXE）时，如果解析器允许外部DTD或实体，可能触发SSRF（<!ENTITY xxe SYSTEM "http://internal-server/">）。
  • PDF/Office文档生成：某些库在渲染远程图片或资源时，会发起网络请求。
  • 数据库驱动：一些数据库连接字符串或特定查询可能触发对URL的访问（如某些JDBC驱动特性，但较少见）。
  • 邮件、短信服务：校验URL有效性时，如果直接请求用户提供的URL。

2.3 漏洞危害的深度分析：不止是端口扫描

很多人对SSRF的理解停留在“内网端口扫描”。这大大低估了它的危害。在实际渗透中，SSRF常作为进入内网的“桥头堡”，与其他漏洞结合产生致命效果：

  1. 攻击云元数据服务：直接获取云服务器的AccessKey、SecretToken，进而接管整个云资源。
  2. 攻击内网脆弱服务：访问内网未授权访问的Redis、MongoDB，执行命令或拖库。访问Jenkins、Docker Registry等管理界面，可能直接获取权限。
  3. 协议利用与回显：利用file://协议读取服务器本地文件（如/proc/self/environ获取环境变量）。利用gopher://、dict://等协议与更多内网服务进行交互，攻击面更广。
  4. 绕过认证与防火墙：因为请求来自受信任的服务器内部，可以绕过基于IP的白名单、防火墙策略或前端认证。
  5. 供应链攻击跳板：如果存在SSRF的服务被其他重要内部系统调用，攻击者可以以此为跳板，攻击更深层、更核心的系统。

3. 从零开始：Java代码审计中挖掘SSRF的实战方法论

审计不是漫无目的地看代码，而是有策略、有重点地追踪数据流。对于SSRF，我的核心审计路径是：寻找“用户输入”与“网络请求API”之间的可达路径。

3.1 第一步：定位敏感的网络请求方法

在IDE中，全局搜索以下关键词，这是发现潜在SSRF入口最快的方法：

  • new URL(
  • HttpURLConnection
  • HttpClient(以及CloseableHttpClient,HttpGet,HttpPost)
  • OkHttpClient
  • RestTemplate(以及getForObject,postForObject,exchange)
  • RequestFactory
  • openConnection
  • java.net.URI

找到这些调用点后，不要急于下结论。重点看构造请求的URL参数来源。

3.2 第二步：回溯数据流，建立“污染源”到“危险函数”的链路

这是审计的核心。你需要像侦探一样，追踪一个变量从何处来，到何处去。

3.2.1 识别污染源（Source）所有来自外部的、不可信的数据都是污染源：

  • HTTP请求参数：request.getParameter(),@RequestParam,@PathVariable
  • HTTP请求头：request.getHeader()
  • HTTP请求体：JSON/XML解析后的对象属性
  • 文件上传的文件名、内容
  • 数据库查询结果（如果数据最初来自用户）
  • 消息队列中的消息

3.2.2 跟踪数据流（Data Flow）手动或借助工具（如Find Security Bugs、SpotBugs）跟踪污染数据是否未经充分校验，就流向了构造URL的方法。关注：

  • 直接传递：String url = param; new URL(url);
  • 字符串拼接：String url = "http://api.example.com/data?key=" + userInput;如果userInput是@evil.com#，可能改变URL的解析结果。
  • 复杂逻辑处理：URL可能经过多个方法的处理、解码、重组。要仔细分析每一处处理是否可能被绕过。

3.2.3 分析校验逻辑（Validation）这是判断漏洞是否真实存在的关键。常见的、但不充分的校验包括：

  • 仅检查域名开头：if (url.startsWith("http://api.trusted.com/"))。攻击者可以使用http://api.trusted.com.example.evil.com/或http://api.trusted.com@evil.com/进行绕过。
  • 使用不安全的正则：过于宽松的正则，或者使用.*匹配，可能匹配到非预期的内容。
  • 黑名单过滤：禁止127.、localhost、192.168.等。绕过方法层出不穷（如127.0.0.1的十进制、八进制、十六进制表示，DNS重绑定攻击等）。

3.3 第三步：构造POC进行验证

当代码逻辑复杂，仅凭静态分析难以确定时，就需要构造Proof of Concept进行验证。

  1. 搭建本地测试环境：将可疑代码片段提取出来，或直接运行整个应用。
  2. 使用拦截代理：配置Burp Suite或ZAP，拦截应用发出的所有请求，观察是否发向了非预期的地址。
  3. 使用内网探测工具：在自己的测试服务器上启动一个简单的HTTP服务（如python3 -m http.server 8000），然后尝试让目标应用请求你的服务器，看是否能收到请求。更进一步，可以尝试让目标应用请求http://169.254.169.254（需要目标在云环境）或http://127.0.0.1:8080等。
  4. 测试协议处理：尝试file:///etc/passwd、gopher://、dict://等协议，观察应用行为（是报错、返回内容，还是连接被拒绝）。

实操心得：在测试SSRF时，我习惯准备一个“SSRF测试服务器”，它不仅能记录收到的请求头（特别是Host、URL），还能按需返回特定的状态码（如302重定向）或响应体，用于测试重定向绕过、差异响应攻击等高级技巧。

4. 深入利用：SSRF的绕过技巧与高级攻击手法

知道漏洞在哪只是第一步，理解攻击者如何利用和绕过防御，才能写出更安全的代码。

4.1 针对URL校验的常见绕过手法

4.1.1 利用URL解析歧义Java的java.net.URL解析器在某些场景下可能与前端或校验逻辑的解析不一致。

  • 利用@符号：http://expected-host@evil-host/。某些校验逻辑只检查@之前的内容，而Java的URL类在发起请求时，会连接到evil-host。
  • 利用#片段标识符：http://expected-host#@evil-host/。如果校验逻辑错误地截断了#之后的部分，而Java的URL类在特定情况下可能忽略#进行连接？（需结合具体代码逻辑，并非总是有效，但是一种思路）。
  • 利用DNS重绑定：这是高级绕过手法。攻击者控制一个域名，其DNS TTL极短，第一次解析返回一个允许的外网IP通过校验，第二次解析时返回一个内网IP（如127.0.0.1）。由于服务器端可能缓存了第一次解析的结果，或者校验与请求之间存在时间差，导致请求最终发往内网。防御这种攻击需要在校验时就解析域名并锁定IP，并在请求时使用该IP而非再次解析。

4.1.2 利用IP地址的多种表示形式黑名单过滤127.0.0.1？试试这些：

  • 十进制表示：2130706433(127.0.0.1的十进制)
  • 八进制表示：0177.0.0.1
  • 十六进制表示：0x7f.0.0.1或0x7f000001
  • 省略格式：127.1
  • IPv6地址：[::1](本地主机)
  • 域名指向：localhost、localtest.me（这个域名解析到127.0.0.1）等。

4.1.3 利用重定向这是最经典、最有效的绕过方式之一。

  1. 攻击者控制一个网站evil.com，当收到请求时，返回一个302 Found状态码，Location头指向http://169.254.169.254/latest/meta-data/。
  2. 存在漏洞的服务器在请求evil.com时，如果其HTTP客户端（如HttpURLConnection）默认跟随重定向，且未对重定向目标进行校验，那么请求就会自动跳转到云元数据接口。
  3. 防御关键：必须禁用自动重定向，或对重定向的目标URL进行与原始URL同样严格的校验。

4.2 利用非HTTP协议扩大攻击面

Java网络库通常支持多种URL协议，这为SSRF利用提供了更多可能性。

协议潜在利用方式备注
file://读取服务器本地文件。如file:///etc/passwd,file:///c:/windows/win.ini。最直接的利用，危害巨大。
ftp://可能用于与FTP服务器交互，或作为中间跳板。现代应用较少使用，但库可能支持。
gopher://一个古老的协议，但可以封装多种请求（如Redis、MySQL未授权访问的Payload），攻击内网服务。是SSRF攻击中的“瑞士军刀”，但Java标准库已默认不支持，需看具体依赖。
dict://可以用来探测端口，或与某些服务（如Redis）进行简单交互。
ldap:///ldaps://可能用于攻击内网LDAP服务。

注意事项：不是所有Java HTTP客户端都默认支持这些协议。HttpURLConnection通常支持file、ftp、http、https、jar。OkHttp和Apache HttpClient对协议的支持取决于其配置和底层实现。审计时，需要查看代码中是否使用了自定义的URLStreamHandler或SocketFactory，这可能会扩展协议支持。

4.3 盲SSRF的探测与利用

有时候，SSRF漏洞没有回显（即服务器不会将请求的响应内容返回给用户）。这种称为“盲SSRF”。挖掘和利用盲SSRF更需要技巧。

4.3.1 如何发现盲SSRF？

  1. 时间延迟：尝试让服务器请求一个你控制的、但设置延迟响应的端点（如sleep(10)）。观察原请求的响应时间是否显著变长。
  2. DNS外带：尝试让服务器请求一个类似http://your-unique-subdomain.evil.com/的地址。在你的DNS服务器日志中查看是否有收到对该子域名的解析请求。这是最可靠的方法之一。
  3. 错误差异：请求一个不存在的端口或非法协议，观察返回的错误信息是否与请求合法地址时不同。

4.3.2 盲SSRF的利用即使没有直接回显，盲SSRF依然危险：

  • 端口扫描：通过响应时间差异或DNS外带，判断内网端口开放情况。
  • 攻击无回显的接口：例如，攻击内网的Redis，执行flushall或config set dir命令，虽然看不到结果，但可能造成破坏。
  • 结合其他漏洞：如果SSRF能触发一个存储型XSS的存储点，或者一个反连Shell的触发点，那么盲SSRF就可以转化为有回显的漏洞。

5. 根治方案：在Java中有效防御SSRF的架构与代码实践

防御SSRF需要一套组合拳，从架构设计、代码编写到运维配置，层层设防。

5.1 第一道防线：输入校验与白名单机制

绝对不要使用黑名单！互联网上未知的IP、域名和绕过技巧太多，黑名单永远无法穷尽。白名单是唯一推荐的方式。

5.1.1 域名白名单如果业务明确只需要访问少数几个外部服务，直接硬编码或配置白名单域名。

private static final Set<String> ALLOWED_DOMAINS = Set.of("api.trusted1.com", "cdn.trusted2.com"); public boolean isUrlAllowed(String urlString) { try { URL url = new URL(urlString); String host = url.getHost(); // 检查是否为白名单域名 if (!ALLOWED_DOMAINS.contains(host)) { return false; } // 可选：进一步检查协议是否为HTTP/HTTPS if (!"https".equals(url.getProtocol()) && !"http".equals(url.getProtocol())) { return false; } return true; } catch (MalformedURLException e) { return false; // 非法URL，直接拒绝 } }

5.1.2 IP白名单与解析锁定如果需要根据IP限制，务必在校验阶段就完成域名解析，并将解析到的IP用于后续的请求，防止DNS重绑定攻击。

public boolean isUrlAllowedWithIp(String urlString) { try { URL url = new URL(urlString); String host = url.getHost(); // 1. 解析域名到IP InetAddress[] addresses = InetAddress.getAllByName(host); for (InetAddress addr : addresses) { String ip = addr.getHostAddress(); // 2. 检查IP是否在白名单内网段 if (!isIpInWhitelist(ip)) { return false; } } // 3. 校验通过，使用最初解析的IP发起请求，而不是再次解析域名 // 可以将`ip`替换回`host`，或者使用自定义的HostnameVerifier和HttpClient return true; } catch (Exception e) { return false; } } private boolean isIpInWhitelist(String ip) { // 实现IP段检查逻辑，例如允许 203.0.113.0/24 // 务必拒绝所有内网IP段：127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 // 以及云元数据IP、链路本地地址等。 // 可以使用Apache Commons Net的SubnetUtils或类似库。 // ... }

5.2 第二道防线：使用安全的HTTP客户端并进行严格配置

5.2.1 禁用自动重定向对于HttpURLConnection、Apache HttpClient、OkHttp，都必须显式配置禁止自动重定向，或者在跟随重定向前对新的URL进行同样严格的校验。

  • HttpURLConnection:conn.setInstanceFollowRedirects(false);
  • Apache HttpClient:
    RequestConfig config = RequestConfig.custom() .setRedirectsEnabled(false) // 禁用重定向 .build(); CloseableHttpClient client = HttpClients.custom() .setDefaultRequestConfig(config) .build();
  • OkHttp: 默认不跟随重定向。如果使用了.followRedirects(true)，请改为false。

5.2.2 限制协议如果可能，只允许HTTP/HTTPS协议。

  • 在URL校验逻辑中拒绝非http/https的协议。
  • 对于OkHttp，可以自定义ConnectionSpec来限制。
  • 注意：简单地检查url.startsWith("http")是不够的，因为httpexample.com也会通过。应该使用URL.getProtocol()方法。

5.2.3 设置超时和连接范围限制防止SSRF被用于对内部服务进行慢速攻击或端口扫描。

  • 连接超时：设置一个较短的连接超时（如3秒）。
  • 读取超时：设置读取超时。
  • 限制响应大小：防止服务器下载大文件耗尽内存。

5.3 第三道防线：网络层与架构层隔离

代码层面的防御是基础，但架构层面的隔离能提供纵深防御。

  1. 网络分段与微隔离：将存在SSRF风险的应用部署在独立的安全域（DMZ），严格限制其出站连接。使用安全组或防火墙策略，只允许该应用访问其业务必须的、特定的外部IP和端口，阻断对所有内网段（10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.0/8）以及云元数据地址的访问。
  2. 使用出站代理：配置应用的所有出站HTTP流量必须经过一个安全的代理服务器。在代理服务器上实施全局的白名单策略。这样即使应用代码存在漏洞，请求也会被代理拦截。
  3. 为内部服务添加认证：不要依赖“内网即安全”的假设。所有内部服务（数据库、缓存、管理后台）都应强制身份认证和授权。
  4. 使用服务标识而非IP：在微服务架构中，使用服务发现（如Consul、Nacos）和服务名进行通信，而不是直接使用IP地址。这可以在一定程度上增加攻击者构造目标地址的难度。

5.4 第四道防线：安全编码与审计工具

  1. 代码审查：将SSRF检查点纳入代码审查清单。重点关注所有将用户输入转换为网络请求的地方。
  2. 静态应用安全测试（SAST）：集成Find Security Bugs、SpotBugs with FindSecBugs插件、SonarQube等工具到CI/CD流程中。这些工具可以自动识别常见的SSRF模式（如new URL(userInput)）。
  3. 动态应用安全测试（DAST）与IAST：定期进行黑盒扫描，并使用交互式应用安全测试（IAST）工具在测试运行时检测漏洞。
  4. 依赖库管理：及时升级HTTP客户端库，修复已知的安全问题。

6. 实战案例深度剖析：从一段问题代码到完整漏洞链

让我们通过一个模拟的真实案例，将前面所有知识串联起来。假设我们审计一个旧的Java Web应用，发现如下功能：提供一个“网页快照”服务，用户输入URL，服务器返回该URL页面的截图。

6.1 漏洞代码发现

@PostMapping("/screenshot") public ResponseEntity<byte[]> takeScreenshot(@RequestParam String url) { // 调用外部服务生成截图，这里模拟一个简单的HTTP请求获取内容 String screenshotServiceUrl = "http://internal-screenshot-service/render"; String targetUrl = URLDecoder.decode(url, "UTF-8"); // 危险！先解码 RestTemplate restTemplate = new RestTemplate(); // 将用户输入的url作为参数传递给内部截图服务 String requestBody = "url=" + targetUrl; HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED); HttpEntity<String> request = new HttpEntity<>(requestBody, headers); // 内部服务可能会去请求用户提供的targetUrl byte[] image = restTemplate.postForObject(screenshotServiceUrl, request, byte[].class); return ResponseEntity.ok().contentType(MediaType.IMAGE_PNG).body(image); }

6.2 漏洞链分析

  1. 入口点：用户可控的url参数。
  2. 数据处理：代码对url进行了URLDecoder.decode。这本身没问题，但位置不对。如果攻击者传入一个经过URL编码的内网地址（如http%3A%2F%2F169.254.169.254%2Flatest%2Fmeta-data%2F），解码后就会变成http://169.254.169.254/latest/meta-data/。
  3. 危险调用：解码后的URL被拼接进请求体，发送给一个内部服务internal-screenshot-service。
  4. 假设内部服务：该内部服务很可能直接请求了这个targetUrl。如果该内部服务没有做SSRF防护，且具有内网访问权限，那么攻击者就实现了一次SSRF攻击，攻击链为：用户 -> 外部应用 -> 内部截图服务 -> 云元数据/内网服务。

6.3 漏洞利用模拟攻击者可以构造如下请求：

POST /screenshot HTTP/1.1 Content-Type: application/x-www-form-urlencoded url=http%3A%2F%2F169.254.169.254%2Flatest%2Fmeta-data%2F

外部应用解码后，将url=http://169.254.169.254/latest/meta-data/发送给内部服务。内部服务请求该元数据接口，并将返回的敏感信息（可能以错误信息、图片二进制乱码等形式）返回给攻击者。

6.4 修复方案

  1. 对外部应用（当前代码）的修复：

    • 移除不必要的解码：如果业务上不需要解码，则去掉URLDecoder.decode。
    • 增加白名单校验：在将url参数转发给内部服务前，必须校验其是否在允许的域名白名单内。这个业务的“网页快照”很可能只允许对公网网站截图，那么白名单就应该排除所有内网IP和域名。
    if (!isUrlAllowed(targetUrl)) { throw new IllegalArgumentException("Invalid URL"); }
    • 使用安全的RestTemplate：为RestTemplate配置自定义的ClientHttpRequestFactory，禁用重定向、设置超时。

  2. 对内部截图服务的修复：

    • 同样实施严格的URL白名单校验。或者，更好的架构是：外部应用只传递一个经过校验的、安全的“任务ID”给内部服务，内部服务根据ID从可信的存储中获取目标URL。

这个案例清晰地展示了，SSRF漏洞往往存在于业务链的深处，需要审计者具备追踪数据流跨服务、跨系统的能力。防御也需要在每一层都做好校验，遵循“零信任”原则。

7. 工具链与自动化审计思路

手动审计效率有限，对于大型项目，必须借助工具。

7.1 静态分析工具（SAST）

  • Find Security Bugs / SpotBugs: 这是Java生态中最知名的开源SAST工具之一。它包含的SSRF规则能检测new URL(userInput)等模式。将其集成到Maven/Gradle构建中，每次编译都能自动检查。
  • SonarQube: 企业级选择，提供更全面的质量与安全门禁。
  • Semgrep: 基于模式的快速扫描工具，可以编写自定义规则来匹配项目特有的SSRF模式，非常灵活。

7.2 动态测试与模糊测试（Fuzzing）

  • 手工测试：使用Burp Suite的Collaborator功能进行盲SSRF探测，利用Intruder对URL参数进行模糊测试，尝试各种绕过Payload。
  • 自动化Fuzz：可以编写脚本，针对识别出的可疑接口，自动化注入一系列测试用例（包括各种格式的IP、重定向Payload、不同协议等），并监控DNS日志、HTTP请求日志来判断是否存在漏洞。

7.3 依赖组件检查使用OWASP Dependency-Check或Snyk检查项目依赖的HTTP客户端库（如HttpClient、OkHttp）是否存在已知的与SSRF相关的安全漏洞。及时升级到安全版本。

7.4 建立代码审计清单为团队建立一份《Java HTTP请求安全编码规范》，将SSRF防御作为强制要求列入，并在代码审查时重点检查：

  1. 是否存在用户输入直接进入URL/URI构造器？
  2. 是否使用了白名单校验？（禁止黑名单）
  3. HTTP客户端是否禁用了重定向？
  4. 是否设置了合理的超时和响应大小限制？
  5. 内部服务调用是否使用了服务发现而非硬编码IP？

掌握Java代码审计中的SSRF，是一个从理解原理、熟悉API、掌握挖掘方法、知晓绕过技巧到落实防御措施的完整闭环。它要求开发者兼具攻击者和防御者的思维。真正的安全不是堆砌规则，而是深刻理解每一行代码可能引发的连锁反应。希望这篇长文能成为你手边常备的参考，在每一次代码编写和审查时，都能对SSRF多一分警惕，少一分风险。