Spring Cloud Function SpEL注入漏洞深度剖析：从原理到防御实践
1. 项目概述：一次对Spring Cloud Function SpEL注入的深度剖析
最近在整理内部安全审计的案例库，又翻到了CVE-2022-22963这个老熟人。这是一个发生在Spring Cloud Function组件中的SpEL表达式注入漏洞，攻击者可以通过构造特定的HTTP请求头，在未授权的情况下远程执行任意命令。虽然官方补丁发布已久，但复盘其原理和复现过程，对于理解现代Java框架的安全风险、掌握代码审计的思路依然极具价值。今天，我就从一个安全研究者和开发者的双重角度，带大家从头到尾拆解这个漏洞。我们不仅会复现攻击过程，更会深入Spring Cloud Function的源码，看看漏洞究竟是如何产生的，以及修复方案是如何堵上这个安全缺口的。无论你是想入门安全研究，还是作为开发者想避免写出有类似问题的代码，这篇文章都能给你带来直接的收获。
2. 漏洞背景与核心原理拆解
2.1 Spring Cloud Function与“函数即服务”的上下文
要理解这个漏洞，首先得知道Spring Cloud Function是干什么的。它本质上是Spring生态中对于“函数即服务”（FaaS）理念的一个实现抽象。它允许开发者将业务逻辑编写成普通的java.util.Function、Consumer或Supplier接口的实现，然后由框架负责将这些函数与各种消息传递或HTTP端点绑定起来。比如，你可以写一个处理字符串的函数，然后通过简单的配置，让它既能监听HTTP POST请求，也能处理来自RabbitMQ或Kafka的消息。这种设计带来了极大的灵活性和解耦。
在漏洞涉及的版本（Spring Cloud Function 3.1.6, 3.2.2 以及更早的旧版本）中，框架提供了一个关键特性：动态路由。简单说，就是客户端可以通过一个HTTP头（默认是spring.cloud.function.routing-expression）来指定本次请求应该由哪个具体的函数来处理。这个特性的本意是好的，提供了运行时动态选择处理逻辑的能力。但问题就出在，框架为了支持更灵活的路由逻辑，允许这个头的值是一个SpEL表达式。
2.2 祸根：SpEL表达式注入
SpEL，全称Spring Expression Language，是Spring框架内建的一种强大的表达式语言。它允许在运行时查询和操作对象图，功能非常强大，可以调用方法、访问属性、进行逻辑运算等。在Spring生态中，SpEL被广泛用于注解（如@Value）、XML配置和Spring Security的权限控制中。
漏洞的核心就在于，Spring Cloud Function在处理spring.cloud.function.routing-expression这个头时，直接将其值作为SpEL表达式进行解析和执行，而且没有做任何的安全过滤或沙箱限制。这意味着，攻击者可以将任意恶意SpEL表达式通过这个HTTP头传递给服务器。由于SpEL表达式在解析时默认就具有执行任意Java代码的能力（尤其是在某些上下文环境下），这就等同于开放了一个远程代码执行（RCE）的后门。
这里需要理解一个关键点：为什么执行SpEL就能导致RCE？这依赖于SpEL的一个特性——它可以访问Spring应用上下文中的Bean，并调用其方法。Java中有一个Runtime类，它的exec方法可以执行系统命令。虽然SpEL默认可能无法直接访问Runtime，但通过一连串的反射调用，可以最终达到执行命令的目的。攻击者常用的一个Payload原型是：T(java.lang.Runtime).getRuntime().exec(\"calc.exe\")。这里的T()操作符就是SpEL中用于访问类静态方法的语法。
2.3 影响范围与严重性
这个漏洞的CVSS评分高达9.8（临界级别），其严重性主要体现在以下几点：
- 利用门槛极低：攻击者只需要能发送HTTP请求即可，无需任何身份认证。
- 危害极大：直接导致服务器被远程控制，可以执行任意系统命令，窃取数据、植入后门、破坏服务器等。
- 影响面广：所有使用了受影响版本Spring Cloud Function并开启了HTTP适配器的应用都暴露在风险之下。由于Spring Cloud的普及度，潜在受影响的应用数量非常可观。
注意：很多开发者在引入Spring Cloud Function时，可能并不直接显式使用它，而是通过引入Spring Cloud Stream等依赖间接引入。因此，即使你没有主动配置Function，只要依赖在类路径上，且应用是一个Web应用，就可能存在风险。
3. 环境搭建与漏洞复现实操
理论讲完了，我们动手搭建一个漏洞环境，真实地感受一下攻击过程。这里我选择使用Vulhub这个漏洞靶场集成环境，它已经为我们准备好了所有配置，可以快速聚焦于漏洞本身。
3.1 靶场环境准备
首先，确保你的机器上安装了Docker和Docker Compose。然后，从Vulhub官网下载或克隆项目，找到Spring CVE-2022-22963的目录。
# 进入漏洞环境目录 cd vulhub/spring/CVE-2022-22963 # 使用docker-compose一键启动漏洞环境 docker-compose up -d执行成功后，使用docker ps命令查看容器是否正常启动，通常会有一个Tomcat容器运行在8080端口。此时，一个存在漏洞的Spring Boot应用就已经在本地运行起来了。
3.2 构造并发送攻击请求
漏洞的利用点在于spring.cloud.function.routing-expression这个HTTP头。我们需要构造一个恶意的SpEL表达式作为这个头的值。这里以在Linux靶机中执行touch /tmp/success命令为例，创建一个文件作为攻击成功的标志。
我们可以使用curl命令来发送攻击请求：
curl -X POST http://your-target-ip:8080/functionRouter \ -H \"spring.cloud.function.routing-expression:T(java.lang.Runtime).getRuntime().exec('touch /tmp/success')\" \ --data-raw \"任意数据\"请求拆解说明：
-X POST: 指定使用POST方法。实际上，对于这个漏洞，GET请求通常也有效，但POST更为通用。http://your-target-ip:8080/functionRouter: 这是漏洞应用默认的Function路由端点。functionRouter是Spring Cloud Function用于处理动态路由的默认路径。-H \"...\": 这是设置HTTP头。我们将恶意的SpEL表达式放在了spring.cloud.function.routing-expression这个头里。--data-raw \"任意数据\": POST请求需要请求体，内容可以为空或任意，不影响漏洞利用。
3.3 验证攻击结果
发送请求后，如果返回的HTTP状态码是500（内部服务器错误），这很可能意味着命令执行成功了。为什么是错误？因为我们的SpEL表达式执行了exec()方法，但整个表达式并没有返回一个合法的函数名给框架进行路由，所以框架处理流程会抛出异常，但这并不妨碍命令已经执行。
我们进入Docker容器内部验证：
# 进入正在运行的容器（容器名可以通过docker ps查看） docker exec -it [容器ID] /bin/bash # 检查文件是否被创建 ls -la /tmp/success如果看到/tmp/success这个文件，恭喜你，漏洞复现成功！这证明我们通过一个HTTP头，就在远程服务器上执行了任意命令。
实操心得：在实际渗透测试中，命令执行后可能需要回显结果。由于直接执行命令的返回输出无法通过HTTP响应直接看到，攻击者通常会采用一些技巧，比如将命令结果写入Web目录下的一个文件，然后通过HTTP访问该文件；或者使用
curl、wget将结果发送到自己的服务器；更高级的会直接反弹一个Shell。例如，一个常见的反弹Shell的Payload会利用bash -i或nc，但在构造时需要注意SpEL字符串中的引号转义和命令中的特殊字符处理，这往往是利用成功的关键，也是容易踩坑的地方。
4. 源码深度剖析：漏洞如何产生
复现成功只是第一步，作为开发者或安全研究员，我们更关心漏洞在代码层面到底是怎么发生的。下面我们就深入Spring Cloud Function的源码（以3.1.6版本为例），一探究竟。
4.1 请求入口与路由表达式提取
Spring Cloud Function的Web适配器核心处理类是FunctionComponent和FunctionController。当请求到达/functionRouter端点时，最终会由RoutingFunction来处理。关键代码位于org.springframework.cloud.function.context.config.RoutingFunction类中。
在RoutingFunction的apply方法或相关调用链中，框架会从请求的Message（封装了HTTP请求）的Headers中查找spring.cloud.function.routing-expression这个键。找到后，直接获取其字符串值。这里没有任何过滤或白名单校验。
// 伪代码，示意流程 String expression = (String) message.getHeaders().get(\"spring.cloud.function.routing-expression\"); if (expression != null) { // 直接使用该表达式 Object functionName = evaluateExpression(expression); // ... 根据functionName路由到具体函数 }4.2 SpEL表达式的解析与执行
获取到表达式字符串后，框架会使用Spring的StandardEvaluationContext和SpelExpressionParser来解析并执行它。
// 伪代码，关键在EvaluationContext的类型 ExpressionParser parser = new SpelExpressionParser(); StandardEvaluationContext context = new StandardEvaluationContext(); // 注意：这里可能将包含请求信息的Message对象等设置为RootObject或变量 context.setRootObject(message); // ... 可能设置其他变量 Expression exp = parser.parseExpression(expression); Object result = exp.getValue(context); // 危险操作在此发生！致命点在于使用了StandardEvaluationContext。这是SpEL中功能最全、但也最危险的上下文环境。它允许表达式拥有几乎完整的Java反射和执行能力。与之相对的是SimpleEvaluationContext，它是为了安全而设计的受限上下文，默认不支持Java类型引用（T()操作符）、Bean引用和构造函数调用等危险特性。
4.3 从表达式到命令执行
当攻击者传入T(java.lang.Runtime).getRuntime().exec('touch /tmp/success')时，SpEL解析器会：
- 解析
T(java.lang.Runtime)：获取java.lang.Runtime类的引用。 - 调用
getRuntime()：这是一个静态方法调用，返回Runtime的单例对象。 - 调用
exec(String)：实例方法调用，执行系统命令。
由于StandardEvaluationContext的强大能力，这一切都畅通无阻。表达式执行的结果（理论上应该是一个函数名）被返回，但框架此时可能已经因为流程异常而崩溃，不过命令早已在exec()调用时被执行。
4.4 官方修复方案解读
Spring官方在后续版本中修复了此漏洞。修复的核心思路非常清晰：
- 彻底移除或禁用动态SpEL路由：在某些修复版本中，直接移除了通过HTTP头进行SpEL表达式路由的功能。
- 使用安全的EvaluationContext：如果保留相关功能，则必须将
StandardEvaluationContext替换为SimpleEvaluationContext，并严格限制可访问的属性和方法。 - 输入校验与白名单：对来自客户端的路由表达式进行严格的校验，只允许简单的字符串（如函数名），或使用一套严格的白名单机制来控制允许的操作。
查看修复后的代码，你会发现相关处理逻辑中，要么不再从header中读取该表达式，要么在解析前进行了严格的检查，并使用了受限的上下文环境。这给我们一个重要的启示：在任何用户输入被当作代码或表达式执行的地方，必须使用最小权限原则和最安全的解析模式。
5. 漏洞防御与安全开发实践
分析完漏洞，我们更应该思考如何避免在自己的项目中引入类似问题。
5.1 立即修复：升级与验证
对于使用Spring Cloud Function的项目，最直接有效的措施是：
- 立即升级：将Spring Cloud Function升级到官方修复的安全版本（3.1.7+ 或 3.2.3+）。
- 依赖检查：使用
mvn dependency:tree或gradle dependencies命令，检查所有传递依赖，确保整个依赖树中不存在有漏洞的版本。有时你的直接依赖可能没问题，但一个间接依赖引入了危险版本。 - 安全扫描：集成OWASP Dependency-Check、Snyk或GitHub Dependabot等工具到CI/CD流程中，自动检查项目依赖的已知漏洞。
5.2 安全编码准则：避免表达式注入
作为开发者，在编码时应牢记以下原则：
- 永远不要信任用户输入：任何来自客户端（HTTP请求参数、头、Cookie、Body）的数据都应视为不可信的。
- 避免动态执行用户输入的代码：尽量避免使用
Runtime.exec()、ProcessBuilder、JavaScript引擎（如ScriptEngine）、OGNL、SpEL、MVEL等来执行用户可控的字符串。如果业务必须，则需要建立严格的沙箱环境。 - 使用安全的API：如果必须使用SpEL，在不需要完整功能的情况下，优先使用
SimpleEvaluationContext替代StandardEvaluationContext。这是防止SpEL注入最有效的一招。 - 实施白名单机制：如果业务需要动态性，应设计一套白名单机制。例如，只允许用户从预定义的几个函数名中选择，而不是传入任意表达式。对输入进行严格的格式校验和内容过滤。
5.3 架构设计层面的思考
从更高层面看，这个漏洞也提醒我们：
- 默认安全原则：框架的默认配置应该是安全的。像动态路由这种高风险功能，默认应关闭或处于最严格的模式下，由开发者显式开启并了解风险。
- 功能与安全的平衡：为框架添加强大灵活的功能时，必须同步评估其安全影响。文档中应明确警示危险配置的使用方法。
- 纵深防御：即使应用层存在漏洞，也可以通过网络层的WAF（Web应用防火墙）设置规则，拦截包含可疑
spring.cloud.function.routing-expression头或类似攻击特征的请求，作为一道额外的防线。
6. 拓展与关联漏洞思考
CVE-2022-22963并非孤例，它与安全史上一些著名的漏洞有相似之处：
- 与Log4Shell (CVE-2021-44228) 的对比：两者都是通过用户可控的输入触发某种“表达式”的解析和执行。Log4Shell是JNDI查找触发的远程类加载和代码执行，而CVE-2022-22963是直接的SpEL表达式执行。它们的共同点在于，一个原本用于提供灵活性的功能（Log4j的日志消息查找、Spring的动态路由），因为对用户输入缺乏控制而变成了致命的漏洞。
- Spring框架历史上的其他SpEL漏洞：Spring框架本身及其组件历史上也出现过多次SpEL注入问题，例如在某些版本的Spring Data Commons、Spring Security OAuth中。审计Spring应用时，需要重点关注所有使用
StandardEvaluationContext和SpelExpressionParser解析外部数据的地方。 - 表达式注入漏洞的通用挖掘思路：这类漏洞的挖掘模式相对固定。首先在项目中全局搜索
SpelExpressionParser、StandardEvaluationContext、@Value（动态解析时）、parseExpression、getValue等关键词。然后逆向追踪这些表达式解析时所使用的字符串来源，如果来源最终可追溯到用户输入（HTTP请求、数据库、文件等），且没有经过充分的安全处理，那么就存在潜在的风险。
通过对CVE-2022-22963的源码级分析和亲手复现，我们不仅掌握了一个具体漏洞的利用方法，更重要的是建立起了一种针对“表达式注入”类漏洞的分析模型和防御意识。在软件开发中，强大的功能往往伴随着潜在的风险，作为技术人员，我们既要善于利用工具提升效率，也必须时刻对安全保持敬畏，将安全编码的原则内化为开发习惯。