JeecgBoot积木报表AviatorScript注入漏洞深度解析与修复实战

1. 项目概述：从一次紧急安全告警说起

那天下午，我正在调试一个基于JeecgBoot 1.7.8版本开发的内部管理系统，突然收到安全扫描平台发来的高危告警，直指系统中的“积木报表”模块存在表达式注入风险。告警信息里赫然写着“AviatorScript Injection”，这让我心头一紧。JeecgBoot作为国内流行的低代码开发平台，其内置的积木报表模块被大量用于快速生成各种统计图表和数据报表，如果这里存在注入漏洞，意味着所有使用了该模块的报表，其背后的数据乃至整个应用服务器都可能暴露在风险之下。这绝不是危言耸听，攻击者完全可能通过精心构造的报表参数，让AviatorScript引擎执行任意系统命令，从而窃取数据、破坏服务。

我立刻停下了手头的工作，开始深入排查。问题的核心在于AviatorScript这个表达式引擎。它本是一个优秀的工具，设计用于安全地执行如userAge > 18、totalPrice * discount这类简单的逻辑或运算表达式，常被集成在规则引擎、报表计算等场景中。但在积木报表1.7.8的某些实现中，由于对用户输入缺乏严格的过滤和沙箱隔离，导致本应只用于数据计算的表达式，变成了攻击者注入恶意代码的“后门”。这就像你给计算器输入算式，它却突然能打开你的文件管理器一样危险。

本次排查与修复的目标非常明确：第一，精准定位JeecgBoot积木报表1.7.8版本中AviatorScript表达式被不当执行的具体代码位置；第二，深入理解漏洞产生的根本原因与可利用的途径；第三，提供一套可立即落地、有效且对业务影响最小的修复方案。无论你是该平台的使用者、维护者，还是对Java应用安全感兴趣的安全工程师，理解这个漏洞的来龙去脉及修复方法，都至关重要。接下来，我将带你一步步还原我的排查过程，并分享最终的修复代码与加固思路。

2. 漏洞原理深度解析：AviatorScript为何会“失控”

要修复漏洞，必须先吃透原理。AviatorScript不是一个全功能的脚本语言（如JavaScript或Groovy），它主要专注于表达式求值。其基本用法是通过AviatorEvaluator.execute(expression, env)来执行，其中expression是字符串形式的表达式，env是一个存放变量的Map环境。在理想的安全模型中，expression应该是开发人员预定义或经过严格校验的，而env中的变量是用户可控的数据。危险就潜伏在这个分工的模糊地带。

2.1 积木报表中的表达式应用场景

在积木报表中，AviatorScript表达式被广泛用于实现动态报表逻辑，主要集中在以下几个功能点：

1. 数据集SQL参数动态化：在定义数据集时，SQL语句的WHERE条件可能包含类似WHERE dept_id = ${deptId}的占位符。报表设计者可以在“参数配置”中，将deptId这个参数的值设置为一个AviatorScript表达式，例如user.getDeptId()，以期在报表渲染时动态获取当前用户的部门ID。
2. 单元格高级计算：在报表设计界面，单元格的值可以设置为表达式，例如对同一列的数据进行求和sum(C2)，或者进行复杂的条件判断。
3. 条件显示与格式化：控制某行、某列是否显示的规则，或者单元格背景色等格式化逻辑，也可能通过表达式驱动。

问题的关键在于，这些表达式的内容从何而来？如果报表的设计者（通常是内部开发或实施人员）是表达式的唯一编写者，风险相对可控。但积木报表为了灵活性，往往允许将表达式本身或表达式中的关键部分（如函数名、参数）作为报表参数，由前端用户传入。这就打开了潘多拉魔盒。

2.2 漏洞产生的核心链：用户输入直达执行引擎

漏洞产生的典型链条如下：

1. 入口：攻击者通过浏览器访问报表页面，在报表参数输入框中，并非输入一个普通的数值或字符串，而是输入一段恶意的AviatorScript表达式代码。
2. 传递：这个恶意参数通过HTTP请求被传递到后端控制器。
3. 拼接/替换：后端代码未经过滤或校验，直接将用户输入的字符串拼接进即将执行的AviatorScript表达式字符串中，或者直接将其设置为表达式本身。
4. 执行：拼接后的完整表达式字符串被传递给AviatorEvaluator.getInstance().execute()方法。
5. 失控：AviatorScript引擎忠实地执行了该字符串，由于AviatorScript支持通过java.lang.Runtime等类执行系统命令，攻击者便实现了远程代码执行。

一个最简单的恶意输入可能是：__。这行表达式的含义是：通过java.lang.Runtime类的getRuntime()方法获取运行时环境，然后执行calc.exe命令（在Windows上会弹出计算器）。在Linux系统上，则可以尝试执行/bin/sh -c等命令。

2.3 为什么默认配置不安全？

许多人有一个误解：AviatorScript不是有安全模式吗？是的，AviatorEvaluator可以通过setOption配置一些安全选项，例如禁用某些函数。但在积木报表1.7.8的默认集成方式中，往往使用的是无任何安全限制的、功能全开的单例实例。更关键的是，即使用户输入被包裹在字符串引号内，如"${userInput}"，攻击者也可以通过闭合引号、添加运算符等方式“逃逸”出来，构造出有效的恶意表达式。例如，如果代码是拼接成"dept_id = '" + userInput + "'"，攻击者输入' && system('calc') && '1'=='1，最终形成的表达式就可能被解析为有效的逻辑语句并执行。

注意：这里提到的system函数是AviatorScript的一个内置函数，用于执行系统命令，是此类注入漏洞最直接的利用目标。在修复时，我们必须考虑彻底禁用或重写此类危险函数。

3. 手把手漏洞定位与排查实战

理论清晰后，我们进入实战排查环节。我的环境是JeecgBoot 1.7.8，积木报表模块作为其一部分集成。

3.1 第一步：全局搜索AviatorScript执行入口

在IDE中打开项目，使用全局搜索功能，查找关键词：

• AviatorEvaluator
• .execute(
• import com.googlecode.aviator

很快，在积木报表的源码包（通常类似org.jeecg.modules.jmreport.*）中，我发现了多个可疑的类。其中，一个名为JmReportBaseQuery或AviatorUtil的类（具体类名可能因版本略有差异）引起了我的注意。这个类通常负责解析报表参数中的表达式并执行。

关键排查点：查看所有调用AviatorEvaluator.getInstance().execute()或类似方法的地方。重点关注第一个参数，即表达式字符串expression，它的构成方式。

3.2 第二步：分析表达式字符串的构造逻辑

我找到了核心的代码段，简化后如下所示：

// 模拟漏洞代码片段 public Object evaluateExpression(String expressionStr, Map<String, Object> env) { // 通常，expressionStr可能来自报表配置，但env中的某个变量可能直接由用户输入填充 // 危险操作：直接将用户可控的字符串拼接进表达式 // 例如，来自前端的参数 paramValue 被直接放入env env.put("paramFromUser", request.getParameter("dangerousParam")); // 然后，在另一个地方，表达式可能被这样构造： String dynamicExpression = "someLogic(" + env.get("paramFromUser") + ")"; // 或者更隐蔽的，表达式模板来自数据库，用户参数直接替换占位符 // String template = "age > #{value}"; // 从数据库读取 // String finalExpression = template.replace("#{value}", userInput); return AviatorEvaluator.getInstance().execute(dynamicExpression, env); }

在上面的伪代码中，如果dangerousParam的值是1) && system('calc') && (1==1，那么拼接后的dynamicExpression就可能变成someLogic(1) && system('calc') && (1==1)，从而在someLogic函数执行后，继续执行system('calc')。

实操心得：不要只盯着明显的execute调用看。要逆向追踪传入execute方法的那个expressionStr字符串，看它是否由StringBuilder拼接、是否经过replace处理、其部分子串是否来源于HttpServletRequest.getParameter()、JSONObject.getString()等直接从外部获取数据的方法。

3.3 第三步：确定攻击面与验证漏洞

根据代码分析，我梳理出几个最有可能的攻击面：

1. 数据集参数值：在报表预览时，传入的查询参数值如果被解析为表达式。
2. 报表SQL中的表达式占位符：在SQL语句中使用${...}包裹的表达式。
3. 单元格值表达式：虽然较少由用户直接输入，但如果设计不当也可能存在风险。

为了验证，我搭建了一个简单的测试报表。在报表中定义一个参数testParam，并在数据集的SQL中引用它：SELECT * FROM sys_user WHERE username = '${testParam}'。理论上，${testParam}应该被替换为一个具体的值。

然后，我在报表预览界面，不输入普通的用户名，而是尝试输入一个简单的AviatorScript表达式，例如'admin' == 'admin'。如果后端直接将其作为表达式求值，返回true，那么SQL可能会变成WHERE username = 'true'，这显然不正常，但也证明了表达式被执行。更进一步，可以尝试输入1==1 ? ‘admin‘ : ‘guest‘这类三元表达式，观察返回的数据是否变成了admin用户的数据。请注意，在授权的测试环境中进行，切勿在生产环境尝试任何可能造成破坏的payload。

重要警告：漏洞验证环节务必在隔离的测试环境进行。切勿使用真实的、危害性的命令执行payload（如system(‘rm -rf /‘)）进行测试，这可能导致测试环境瘫痪。使用无害的验证方式，如计算一个表达式1+2，或者访问一个不存在的Java类来触发异常，从而观察执行行为。

4. 多层次修复方案设计与实现

找到漏洞根源后，修复思路必须立体化，不能只打一个补丁。我设计了从“紧急止血”到“长治久安”的三层修复方案。

4.1 第一层：代码层修复——严格过滤与安全调用

这是最直接、最快速的修复方式。修改执行AviatorScript表达式的核心工具类。

修复目标：确保任何来自用户输入（前端参数、数据库存储的模板变量部分）的内容，在进入AviatorScript引擎前，都只被当作数据（字符串、数字），而绝不能成为表达式逻辑的一部分。

方案一：白名单变量替换法（推荐）这是最安全的方法。彻底改变使用方式：不拼接表达式，而是将用户输入作为环境变量中的值，表达式只引用变量名。

1. 重构表达式模板：将原来SQL中或表达式中的直接拼接点，改为变量占位符。例如，将“age > ” + userInput改为“age > #{ageParam}”。
2. 安全替换：在代码中，解析出#{ageParam}，然后从用户请求参数中获取ageParam的值（假设为“25”）。
3. 关键步骤：不进行字符串替换！而是将ageParam=25这个键值对放入执行环境Map (env) 中。
4. 执行：执行一个固定的表达式“age > ageParam”，并将env（其中ageParam=25）传入。这样，用户输入的“25”始终是一个数值型数据，没有任何机会被解析为表达式片段。

// 修复后的安全调用示例 public Object evaluateExpressionSafely(String fixedExpression, Map<String, Object> params) { // fixedExpression 是开发人员预定义的，如 "age > ageParam && status == statusParam" // params 来自用户输入，但已经过基础类型转换（如字符串转数字） Map<String, Object> env = new HashMap<>(); for (Map.Entry<String, Object> entry : params.entrySet()) { Object value = entry.getValue(); // 进行基础的数据清洗和类型转换，确保value是简单类型（String, Number, Boolean） // 绝对禁止value是一个包含AviatorScript代码的字符串 env.put(entry.getKey(), convertToSimpleType(value)); } // 使用一个经过安全配置的AviatorEvaluator实例 return getSecureAviatorEvaluator().execute(fixedExpression, env); } private AviatorEvaluatorInstance getSecureAviatorEvaluator() { // 创建独立的评估器实例，而非使用全局单例 AviatorEvaluatorInstance instance = AviatorEvaluator.newInstance(); // 禁用system等危险函数 instance.disableFunction("system"); instance.disableFunction("exec"); instance.disableFunction("load"); // 可选：设置运行模式为安全模式（限制访问类） // instance.setOption(Options.FEATURE_SET, Feature.asSet(Feature.Assignment, Feature...)); // 仅开启必要特性 return instance; }

方案二：黑名单过滤与转义（应急方案）如果无法立即重构所有表达式逻辑，可以采取临时加固措施。对即将拼接进表达式的用户输入进行严格的过滤。

• 过滤所有危险字符：如反引号、分号、括号、以及java.lang、Runtime、ProcessBuilder、system、exec等关键词。但这种方法很容易被绕过（如大小写变形、编码、字符串拼接），因此只能作为临时补充。
• 强制字符串化：确保用户输入在表达式中始终被当作字符串字面量。例如，在拼接时，无论用户输入什么，都为其加上单引号，并对输入中的单引号进行转义。但这种方式在复杂表达式构造中极易出错。

实操心得：白名单变量替换法是治本之策。它彻底切断了用户输入“升级”为代码逻辑的路径。实施时，需要梳理所有报表的表达式使用点，工作量可能不小，但安全收益是永久的。对于存量报表，可以分批改造；对于新报表，必须强制使用新规范。

4.2 第二层：配置层加固——定制安全的AviatorEvaluator实例

不要使用全局的AviatorEvaluator.getInstance()。应该为积木报表模块创建一个独立的、经过严格安全配置的实例。

1. 禁用危险函数：通过AviatorEvaluatorInstance.disableFunction(“system”)等方法，禁用命令执行、文件访问、类加载等所有高危函数。
2. 限制可访问的Java类：通过自定义FunctionLoader和覆盖getProperty方法，可以严格控制表达式能够访问的Java类和方法。例如，只允许访问特定的工具类、数据模型类，禁止访问java.lang.Runtime、java.lang.ProcessBuilder、java.io.File等。
3. 设置求值超时：通过AviatorEvaluatorInstance.setOption(Options.MAX_LOOP_COUNT, 100)或超时机制，防止恶意表达式陷入死循环消耗资源。

@Configuration public class AviatorSecurityConfig { @Bean(name = "reportAviatorEvaluator") public AviatorEvaluatorInstance secureAviatorEvaluator() { AviatorEvaluatorInstance instance = AviatorEvaluator.newInstance(); // 1. 禁用危险内置函数 String[] dangerousFunctions = {"system", "exec", "load", "read", "write", "delete"}; for (String func : dangerousFunctions) { try { instance.disableFunction(func); } catch (Exception e) { // 忽略函数不存在的异常 } } // 2. 设置安全模式选项（限制能力集） EnumSet<Feature> safeFeatures = EnumSet.of( Feature.Assignment, // 允许赋值 Feature.Lambda, // 允许lambda（根据需求） Feature.If, // 允许三元表达式 Feature.Loop, // 允许循环（可酌情关闭） Feature.Let // 允许let // 谨慎开启：Feature.New， Feature.InstanceOf 等 ); instance.setOption(Options.FEATURE_SET, safeFeatures); // 3. 设置求值超时（单位：毫秒） instance.setOption(Options.EVAL_TIMEOUT, 5000L); // 5秒超时 return instance; } }

然后在报表服务中，注入这个reportAviatorEvaluatorBean来使用。

4.3 第三层：架构层建议——输入校验与权限最小化

1. 强化参数校验：在报表参数入口处（Controller层），使用JSR 303注解或自定义校验器，对参数进行强类型和范围校验。例如，如果参数应该是部门ID，则校验其必须为整数且在有效ID列表内。
2. 表达式签名或审核：对于需要高安全级别的场景，可以考虑对报表中使用的表达式模板进行“签名”或“审核”流程。只有经过预审、签名的表达式模板才允许被执行。动态从用户端传来的表达式字符串应被直接拒绝。
3. 权限隔离：运行报表服务的应用服务器账户，应遵循权限最小化原则，避免使用root或高权限账户运行。这样即使发生命令执行，其破坏力也受到限制。

5. 修复步骤实操与代码示例

假设我们定位到的漏洞核心类为JmReportExpressionEngine。以下展示具体的修复步骤。

5.1 步骤一：创建安全配置类

首先，创建上述AviatorSecurityConfig配置类，定义安全的AviatorEvaluator实例。

5.2 步骤二：改造表达式引擎类

找到原来的JmReportExpressionEngine（类名可能不同），注入安全实例，并重写表达式求值方法。

@Service public class JmReportExpressionEngine { @Autowired @Qualifier("reportAviatorEvaluator") // 注入我们配置的安全实例 private AviatorEvaluatorInstance aviatorEvaluator; /** * 安全的表达式求值方法 * @param expression 固定的表达式模板，如 “param1 > 0 && param2 == ‘active‘” * @param paramMap 用户参数Map，其中的值只能是简单类型（String, Number, Boolean, Collection等） * @return 求值结果 */ public Object evaluateSafe(String expression, Map<String, Object> paramMap) { if (StringUtils.isBlank(expression)) { return null; } // 深度清洗参数：确保paramMap中的值没有嵌套Map/List包含危险内容（可根据需要递归检查） Map<String, Object> safeEnv = sanitizeParameters(paramMap); try { // 设置一个线程局部的超时钩子（双重保障） Future<Object> future = Executors.newSingleThreadExecutor().submit(() -> aviatorEvaluator.execute(expression, safeEnv) ); return future.get(5, TimeUnit.SECONDS); // 获取结果，超时则中断 } catch (TimeoutException e) { throw new RuntimeException("表达式求值超时，可能存在恶意循环: " + expression, e); } catch (InterruptedException | ExecutionException e) { throw new RuntimeException("表达式求值失败: " + expression, e); } } /** * 参数清洗：将用户输入转换为安全的数据 */ private Map<String, Object> sanitizeParameters(Map<String, Object> rawParams) { Map<String, Object> safeParams = new HashMap<>(); for (Map.Entry<String, Object> entry : rawParams.entrySet()) { Object value = entry.getValue(); // 只允许基本类型、字符串、以及简单集合（集合元素也需为简单类型） if (isSimpleType(value)) { safeParams.put(entry.getKey(), value); } else { // 对于复杂对象，可以尝试只取其安全属性，或者直接记录日志并忽略/抛出异常 log.warn("发现非简单类型参数，已忽略。key: {}, type: {}", entry.getKey(), value.getClass()); // 安全策略：可以抛异常，或者转换为字符串（需警惕toString方法的风险） // safeParams.put(entry.getKey(), String.valueOf(value)); } } return safeParams; } private boolean isSimpleType(Object obj) { return obj == null || obj instanceof String || obj instanceof Number || obj instanceof Boolean || obj instanceof Character || obj instanceof Collection || // 集合需要递归检查元素 obj instanceof Map; // Map需要递归检查key和value // 注意：对Collection和Map需要递归检查其内部元素是否为简单类型，这里为简化示例 } }

5.3 步骤三：修改报表数据查询服务

找到原来执行SQL拼接和表达式替换的Service类（例如JmReportBaseQuery或DatasetService）。

修改前（危险代码示例）：

String sqlTemplate = “SELECT * FROM order WHERE amount > #{value}”; String userInput = params.get(“value”); // 用户输入可能是 “100) OR (1=1” // 危险：直接字符串替换 String finalSql = sqlTemplate.replace(“#{value}”, userInput); // 然后执行 finalSql...

修改后（安全代码示例）：

// 假设SQL模板解析后，识别出表达式参数为 #{expr:filterCondition} String sqlTemplate = “SELECT * FROM order WHERE #{expr:filterCondition}”; String expressionTemplate = “amount > amountParam”; // 从报表设计元数据中读取，是固定的 Map<String, Object> env = new HashMap<>(); env.put(“amountParam”, params.get(“amount”)); // params.get(“amount”) 应该是清洗过的数字 // 使用安全的表达式引擎求值 Object conditionResult = expressionEngine.evaluateSafe(expressionTemplate, env); // conditionResult 应该是布尔值 true/false // 但这里逻辑需要调整：我们不应该将表达式结果拼回SQL，而是应该用表达式结果来动态生成SQL的WHERE部分 // 更安全的做法是使用预编译SQL（PreparedStatement）和参数化查询 String safeSql = “SELECT * FROM order”; List<Object> queryParams = new ArrayList<>(); if (Boolean.TRUE.equals(conditionResult)) { safeSql += “ WHERE amount > ?”; queryParams.add(params.get(“amount”)); // 使用预编译参数 } // 然后使用 jdbcTemplate 或 MyBatis 执行 safeSql 和 queryParams

关键转变：从“将用户数据拼接到表达式或SQL中”转变为“将用户数据作为参数传递给一个固定的、安全的表达式或预编译SQL”。这个思维转变是修复的核心。

6. 回归测试与验证要点

修复完成后，必须进行全面的回归测试。

1. 功能测试：

   • 测试所有现有报表，确保正常参数下，报表能正确生成，数据准确。
   • 测试表达式功能是否按预期工作（如条件显示、动态计算）。

2. 安全测试：

   • 输入验证：在报表参数中输入各种边界值和异常值（空值、超长字符串、特殊字符）。
   • 注入尝试：输入之前发现的漏洞Payload，例如包含system、Runtime、反引号、括号的字符串。预期结果应该是：报表渲染失败，并返回一个清晰的、非泄露性的错误信息（如“参数格式错误”），绝对不允许执行Payload。
   • 模糊测试：使用工具或脚本，随机生成大量非常规输入，观察系统行为是否稳定，有无错误信息泄露、服务崩溃等情况。

3. 性能测试：由于引入了额外的参数清洗和安全检查，以及可能使用了独立的AviatorEvaluator实例，需关注对报表加载性能的影响。在高并发下进行压力测试，确保响应时间在可接受范围内。

4. 日志与监控：在表达式引擎的关键位置添加详细的日志记录（注意不要记录敏感参数）。监控日志中是否有频繁的表达式执行失败或安全警告，这可能是攻击试探的迹象。

7. 总结与长效安全治理建议

通过这次对JeecgBoot积木报表1.7.8 AviatorScript注入漏洞的深度排查与修复，我们不仅解决了一个具体的安全问题，更梳理出了一套针对表达式引擎使用的安全最佳实践。核心要点再强调一次：永远不要信任用户输入，永远不要将用户输入直接作为代码逻辑的一部分。

对于使用JeecgBoot或类似集成AviatorScript、OGNL、SpEL等表达式引擎的框架，我建议将安全检查纳入开发流程：

• 代码审计：定期对使用表达式引擎的代码进行人工或工具辅助的审计，重点关注字符串拼接、replace、format等方法。
• 依赖管理：及时升级框架和组件。关注JeecgBoot官方仓库的Security Advisories，看是否有针对此漏洞的官方补丁发布。
• 安全编码规范：在团队内建立规范，明确要求所有动态表达式必须使用“白名单变量替换”模式，禁止任何形式的字符串拼接。
• 运行时防护：考虑在WAF（Web应用防火墙）或RASP（运行时应用自保护）层面，增加对特定漏洞特征（如Runtime.getRuntime()）的检测和阻断，作为最后一道防线。

修复这个漏洞的过程，就像给一扇原本虚掩的门加了一把结实的锁。门的功能（报表灵活性）没有丢失，但未经授权的访问被彻底杜绝。安全是一个持续的过程，保持警惕，遵循最小权限和零信任原则，才能让我们的应用在享受便利的同时，抵御住外部的风雨。