JeecgBoot高危漏洞CVE-2023-41544：表达式注入导致RCE的深度剖析与修复-平芜编程栈

1. 项目概述：一次对低代码平台高危漏洞的深度剖析

最近在梳理一些开源低代码平台的安全风险时，JeecgBoot这个国内开发者圈子里相当流行的框架进入了我的视野。它主打快速开发，通过可视化配置生成代码，确实能极大提升中小型项目的交付效率。但“效率”和“安全”往往像天平的两端，这次要聊的CVE-2023-41544，就是一个典型的因功能强大但安全边界模糊而导致的高危远程代码执行漏洞。这个漏洞的核心出在报表模块jmreport的一个接口loadTableData上，攻击者能够通过精心构造的请求，最终在服务器上执行任意系统命令。对于任何使用了受影响版本JeecgBoot的系统来说，这无异于将服务器的最高控制权拱手让人。今天，我就从一个安全研究兼开发者的角度，带大家完整地走一遍这个漏洞的复现与分析过程，不仅要知道怎么“打”，更要明白它为什么会产生，以及在实际开发中如何规避此类问题。

2. 漏洞背景与影响范围解析

2.1 JeecgBoot与jmreport模块简介

JeecgBoot是一个基于Spring Boot的快速开发平台，它的一大亮点就是强大的在线报表设计器jmreport。这个模块允许开发者甚至业务人员通过拖拽的方式，配置复杂的SQL查询、API数据源，并生成各种图表和表格，无需编写后端代码。loadTableData接口正是这个报表引擎的核心接口之一，负责根据前端的查询条件，动态加载和返回报表所需的数据。其设计初衷是为了灵活性，能够解析前端传递的复杂JSON参数来动态拼接查询逻辑。

2.2 CVE-2023-41544漏洞本质

这个漏洞的根源在于表达式注入。为了实现高度的动态性，jmreport在解析loadTableData接口传入的某些参数时，使用了类似SpEL的表达式引擎进行处理，而这个过程没有对用户输入进行充分的过滤和沙箱隔离。攻击者可以将恶意的Java代码片段嵌入到请求参数中，当服务器解析这些参数时，恶意代码会被当作表达式执行，从而导致远程代码执行。

注意：这与常见的SQL注入有本质区别。SQL注入是让数据库执行非法SQL，而表达式注入是让后端的Java应用服务器本身执行Java代码，危害等级通常更高，因为它直接威胁应用服务器主机。

2.3 受影响版本与严重性

根据公开的漏洞公告，受影响的JeecgBoot版本主要集中在某个版本范围之内。由于低代码平台常被用于开发内部管理系统、甚至一些对外的运营后台，一旦被利用，攻击者可以读取数据库敏感数据、植入webshell、窃取服务器文件，甚至利用服务器作为跳板进行内网横向移动。在CVSS 3.x评分体系中，此类漏洞的评分通常高达9.0以上，属于严重级别。对于企业而言，这意味着必须立即进行版本升级或漏洞修复。

3. 漏洞原理深度拆解与代码溯源

要真正理解一个漏洞，光知道利用方法是不够的，必须深入到代码层面，看看安全防线是在哪一环被突破的。下面我们结合漏洞原理，进行推演和拆解。

3.1 动态查询参数的处理流程

在JeecgBoot的jmreport模块中，loadTableData接口会接收一个包含查询条件、排序、分页等信息的复杂JSON对象。为了将前端的过滤条件转换为后端的SQL查询，框架需要解析这些条件。例如，前端可能传递一个过滤条件：“name”: “like ‘%张三%’”。后端需要将这个条件解析为SQL的WHERE子句片段。

问题就出在解析机制上。为了实现类似“通过字段名动态调用查询方法”这类高级功能，开发人员可能会引入表达式引擎来解析参数值。一段伪代码可能如下所示：

// 危险示例：说明性伪代码 public Object loadTableData(QueryParams params) { for (Condition condition : params.getConditions()) { String field = condition.getField(); // 字段名，如“userName” String operator = condition.getOperator(); // 操作符，如“eq” Object value = condition.getValue(); // 值，可能来自用户输入 // 为了动态调用，可能会使用表达式来构造方法调用或值处理 if (value instanceof String && ((String) value).startsWith(“$”)) { // 假设以$开头的字符串是需要解析的表达式 String expression = ((String) value).substring(1); // 危险操作：直接将用户输入传入表达式解析器 Object evaluatedValue = expressionParser.parseExpression(expression).getValue(); condition.setValue(evaluatedValue); } // ... 后续使用condition拼接查询 } }

上面这段伪代码清晰地展示了风险点：如果condition.getValue()的内容用户可控，并且系统以某种标识（如$）认定其为需要解析的表达式，那么用户传入${T(java.lang.Runtime).getRuntime().exec(‘calc’)}这样的字符串，就会被表达式引擎执行。

3.2 表达式引擎的安全沙箱缺失

Spring框架的SpEL表达式功能强大，但在默认情况下，它能够访问任意类、调用任意方法。安全的做法是配置一个受限的EvaluationContext，例如使用SimpleEvaluationContext来限制可访问的属性。然而，在追求功能灵活性的快速开发框架中，开发者有时会直接使用功能更强大但也更危险的StandardEvaluationContext，或者自定义的解析器没有做任何限制，这就为表达式注入敞开了大门。

在实际的CVE-2023-41544漏洞中，攻击路径可能更迂回一些。攻击者可能并非直接传入一个显式的表达式，而是通过控制某个参数，该参数在后续的流程中，被拼接到了某个即将被解析的表达式字符串里。例如，参数a的值被拼接到了“${” + a + “}”这个模板中，然后整个字符串被送去解析。如果用户控制a为T(Runtime).getRuntime().exec(“touch /tmp/poc”)，那么最终执行的表达式就是灾难性的。

3.3 漏洞触发的必要条件

总结起来，这个漏洞触发需要几个关键条件：

存在一个用户输入可控的接口参数：在loadTableData的请求体中，至少有一个参数值能被攻击者完全控制。
输入被传入表达式解析器：框架内部的处理逻辑将该参数值或其衍生字符串，传递给了表达式解析引擎（如SpEL、OGNL、MVEL等）。
表达式解析器处于高权限模式：解析器没有运行在安全沙箱中，允许执行任意Java代码。

4. 漏洞复现环境搭建与实操

理解了原理，我们动手搭建环境进行复现。请注意，所有操作请在授权的测试环境进行。

4.1 环境准备与漏洞版本部署

首先，我们需要一个存在漏洞的JeecgBoot版本。你可以从官方的GitHub仓库的Release历史中，找到对应的漏洞版本进行下载。这里假设我们使用一个基于Spring Boot的JeecgBoot war包进行部署。

基础环境：准备一台Linux测试服务器或本地虚拟机，安装JDK 8或11，Maven，以及Tomcat 9。
获取漏洞版本代码：从版本控制历史中checkout出漏洞版本的代码，或者直接下载对应版本的发布包。

编译与部署：

# 进入项目根目录 cd jeecg-boot # 使用Maven打包。如果网络问题，可能需要配置国内镜像。 mvn clean package -DskipTests # 打包后，在jeecg-module-system/jeecg-module-system-start/target目录下找到生成的war包（如jeecg-system-start-3.5.0.war） # 将war包复制到Tomcat的webapps目录下 cp jeecg-system-start-*.war /opt/tomcat/webapps/jeecgboot.war # 启动Tomcat /opt/tomcat/bin/startup.sh

初始化与访问：启动后，访问http://your-server-ip:8080/jeecgboot，根据引导完成数据库初始化（通常需要创建一个空的MySQL数据库，并在安装页面配置数据源）。完成初始化后，使用默认账号（如admin/123456）登录。

实操心得：部署老版本开源项目时，经常遇到依赖库无法下载的问题。一个实用的技巧是检查项目根目录的pom.xml，将其中的Maven仓库地址临时替换为阿里云镜像，可以极大提升下载速度。另外，数据库版本也要注意，JeecgBoot老版本可能对MySQL 8.x兼容性不好，建议使用MySQL 5.7。

4.2 构造漏洞验证请求

成功登录系统后，我们需要找到报表设计模块，并创建一个最简单的报表来触发loadTableData接口。但作为漏洞复现，我们更直接的方式是分析网络请求，直接构造攻击Payload。

定位接口：通过浏览器开发者工具（F12），进入“网络”标签页。在报表列表页面点击预览某个报表，观察发出的请求。通常会找到一个指向/jmreport/loadTableData的POST请求。
分析请求结构：查看该请求的请求体（Request Payload），它通常是一个复杂的JSON结构，包含了sql、params、queryParams等字段。我们需要找到那个可以被注入的“参数点”。
构造恶意Payload：根据漏洞披露的细节，攻击载荷可能隐藏在queryParams或某个条件值中。一个典型的攻击请求可能如下所示（以下为示例，实际参数名需根据版本调整）：

POST /jeecgboot/jmreport/loadTableData HTTP/1.1 Host: your-target-ip:8080 Content-Type: application/json;charset=UTF-8 Cookie: JSESSIONID=xxxxxx { “apiId”: “test_report”, “queryParams”: { “id”: 1, “filter”: “${T(org.apache.commons.io.IOUtils).toString(T(java.lang.Runtime).getRuntime().exec(‘whoami’).getInputStream())}” } }

关键点解释：

T(org.apache.commons.io.IOUtils).toString(...)：这是利用Spring SpEL表达式调用静态方法。T()操作符用于指定类。
T(java.lang.Runtime).getRuntime().exec(‘whoami’)：执行系统命令whoami。
.getInputStream()：获取命令执行的输出流。
整个表达式的目的是执行whoami命令，并将输出结果转换为字符串，这个字符串可能会被框架当作查询参数值，从而在响应中返回给攻击者。

4.3 执行复现与结果确认

使用Burp Suite、Postman或Curl工具发送上述构造的恶意请求。

发送请求：将构造好的JSON替换到实际的请求体中，发送POST请求。
观察响应：
- 漏洞存在：如果服务器存在漏洞，你可能会在HTTP响应中看到命令执行的结果（例如，当前服务器进程的用户名root或tomcat）。也可能服务器会返回一个500错误，但错误信息中包含了命令执行的输出。更隐蔽的情况下，命令可能已执行但无回显，此时可以尝试执行一个带延时的命令（如ping -c 4 127.0.0.1）或写文件的命令（如touch /tmp/success），然后通过其他方式验证。
- 漏洞不存在或已修复：服务器可能返回一个正常的业务错误（如“参数解析失败”），或者直接忽略该参数，响应中不包含命令执行结果。

注意事项：在实际测试中，命令执行可能受到目标服务器环境的影响。例如，Java的Runtime.exec()处理带空格的参数或管道符|、重定向符>时，行为可能与直接在shell中执行不同。通常更可靠的方式是编码后执行，或者使用bash -c {command}来执行复杂命令。另外，绝对不要在生产环境或未授权的系统上进行测试。

5. 漏洞修复方案与安全加固建议

复现漏洞是为了更好地防御。对于使用JeecgBoot的开发者或运维人员，应立即采取以下措施。

5.1 官方修复方案

最直接有效的方法是升级JeecgBoot到已修复该漏洞的最新版本。官方在后续版本中，针对jmreport模块的表达式解析逻辑进行了加固，主要措施包括：

禁用或严格限制表达式解析：移除了对参数值进行动态表达式解析的功能，或者将其限制在一个极小的、预定义的安全白名单内。
使用安全的EvaluationContext：如果确实需要表达式功能，则改用SimpleEvaluationContext替代StandardEvaluationContext，从根本上限制可访问的类和方法。
输入过滤与校验：在参数进入核心处理逻辑前，增加强力的过滤，对包含特殊字符（如$,{,},T(),#等SpEL元字符）的参数进行拦截或转义。

5.2 临时缓解措施

如果因种种原因无法立即升级，可以考虑以下临时缓解方案：

WAF防护：在应用前端部署Web应用防火墙，配置规则拦截包含T(java.lang.Runtime),getRuntime(),exec(等关键字的请求。但这种方法可能被绕过。

代码层临时修补：找到项目中处理loadTableData（或更通用的参数解析）的类文件，手动添加输入过滤逻辑。例如，在参数解析入口处，对字符串类型的参数值进行扫描和拒绝。

// 临时补丁示例：在参数处理入口处添加过滤 public Object sanitizeParameter(Object value) { if (value instanceof String) { String strValue = (String) value; // 简单的黑名单过滤，实际需要更完善的规则 if (strValue.contains(“T(”) && strValue.contains(“getRuntime”) && strValue.contains(“exec”)) { throw new IllegalArgumentException(“检测到非法参数内容”); } // 更严格的做法：禁止所有SpEL表达式特征字符 if (strValue.matches(“.*[${}T()#].*”)) { // 进行转义或直接拒绝 return strValue.replaceAll(“[$”, “\\$”).replaceAll(“{“, “\\{“); // 简单转义，需谨慎评估 } } return value; }

提示：临时补丁的过滤规则需要精心设计，避免影响正常业务（比如正常业务参数里可能包含花括号），同时也要防止被各种编码方式绕过。这只是一个应急方案，治本之道仍是升级。

5.3 安全开发规范启示

这个漏洞给所有开发者，尤其是低代码平台和快速开发框架的开发者，敲响了警钟：

永远不要信任用户输入：这是安全的第一原则。任何来自客户端（前端、接口调用方）的数据都必须视为不可信的，必须经过严格的校验、过滤和转义。
谨慎使用动态代码/表达式执行：eval()、SpEL、OGNL、ScriptEngine等功能极其危险。如非必要，避免使用。如果必须使用，务必配置在严格的白名单沙箱环境中。
依赖组件安全扫描：将安全左移，在CI/CD流程中集成依赖项漏洞扫描工具（如OWASP Dependency-Check），及时更新存在已知漏洞的第三方库。
最小权限原则：运行Java应用的服务器账户（如tomcat用户）应遵循最小权限原则，避免使用root权限运行，以限制漏洞成功利用后造成的破坏范围。