Spring Cloud Function SpEL表达式注入

漏洞概述

Spring Cloud Function 是基于Spring Boot 的函数计算框架（FaaS），该项目提供了一个通用的模型，用于在各种平台上部署基于函数的软件，包括像 Amazon AWS Lambda 这样的 FaaS（函数即服务，function as a service）平台。它抽象出所有传输细节和基础架构，允许开发人员保留所有熟悉的工具和流程，并专注于业务逻辑。

在版本3.0.0到当前最新版本3.2.2 (@dc5128b80c6c04232a081458f637c81a64fa9b52)，默认配置下，都存在Spring Cloud Function SpEL表达式注入漏洞。

漏洞复现

在IDEA中选择新建项目，然后选择Spring Initializr，项目名称随便输入，然后选择java版本和jdk版本后点击下一步。

接着选择Spring Web和Function作为依赖项后点击完成。

这时漏洞环境就搭建完成了，因为当前官方还没出新版本，所以最新版本3.2.2也是存在漏洞的，若在官方出新版本后想要复现此漏洞，那么需要修改pom中spring-cloud-function-web的版本为3.2.2,如下图所示

确认项目中的spring-cloud-function-web是存在漏洞版本后，就可以直接启动项目了，无需进行任何修改。

然后对本地8080端口发送payload即可。

Payload

漏洞分析

先看git提交记录，https://github.com/spring-cloud/spring-cloud-function/commit/0e89ee27b2e76138c16bcba6f4bca906c4f3744f
在这个提交描述中，明确的指出修复了RoutingFunction SpEL代码注入漏洞，并且可以看到他只更新了两个文件，其中一个文件还是单元测试。

而且在测试用例中也清楚的写明了漏洞位置以及相关测试Payload.

通过测试用例我们已经知道，在给Spring Cloud Function的web服务发送包的时候，加一个相关的Header头，然后后面跟上SpEL表达式即可执行命令。

在文件org.springframework.cloud.function.context.config.RoutingFunction中，请求进入到apply方法，接着调用了route方法，然后通过判断特定的消息头信息是否为空，如果不为空则调用functionFromExpression方法

然后就调用到了SpEL对routingExpression进行解析，从而导致了SpEL表达式注入。

整个逻辑中由于完全信任从开始传入的header信息，并且在解析SpEL表达式时候的evalContext使用的是功能更强同时安全隐患较大的StandardEcalutionContext.

在官方最新的修补文件中，可以看到新增了headerEvalContext对象，该对象所对应的是使用了仅支持最基本功能的SimpleEvaluationContext。

且在调用functionFromExpression方法的时候新增了一个isViaHeader布尔类型的参数，用来判断该值是否是取自消息的header中，如果是则使用headerEvalContext对象来解析SpEL表达式。