JeecgBoot报表组件SQL注入漏洞分析与防护建议

问题背景

JeecgBoot作为一款流行的低代码开发平台，其内置的jimureport报表组件在v3.7.1版本中被发现存在安全风险。攻击者可通过未授权访问/drag/onlDragDatasetHead/getTotalData接口实施SQL查询操作，可能威胁数据库安全。

技术原理分析

问题成因

1. 权限控制缺失：ShiroConfig配置中未对该接口设置访问权限校验
2. 动态SQL拼接：报表组件在处理tableName参数时未做充分过滤
3. JSON参数操作：通过构造的JSON请求体可控制SQL查询字段

风险特征

典型风险请求包含以下特征：

{
  "tableName":"sys_user",
  "compName":"test",
  "condition":{"filter":{}},
  "config":{
    "name":[{
      "fieldName":"concat(username,0x3a,password)",
      "fieldType":"string"
    }]
  }
}

攻击者通过特定函数拼接字段，利用编码方式绕过字符过滤，可能泄露用户名密码等核心数据。

影响范围

• 受影响版本：v3.7.1及使用jimureport-dashboard-spring-boot-starter-1.8.1-beta的衍生版本
• 风险等级：高危（CVSS 3.1评分8.8）

修复方案

临时缓解措施

1. 在ShiroConfig中增加接口鉴权：

filterChainDefinitionMap.put("/drag/onlDragDatasetHead/**", "authc");

2. 添加WAF规则拦截包含特定特征的请求

根本解决方案

1. 参数白名单校验：对tableName等参数实施严格的表名白名单机制
2. 预编译语句：改造SQL查询逻辑，使用PreparedStatement
3. 字段映射机制：建立字段别名映射，避免直接使用用户输入作为查询字段

安全开发建议

1. 始终遵循最小权限原则配置接口权限
2. 对动态查询场景实施以下防护：
   • 输入验证（Validation）
   • 输出编码（Encoding）
   • 查询分离（Query Separation）
3. 定期进行安全代码审计，特别关注：
   • 动态SQL拼接点
   • JSON/XML反序列化点
   • 文件包含操作

总结

该问题典型反映了低代码平台在追求灵活性的同时可能忽视的安全风险。开发团队应当建立安全开发生命周期(SDLC)，在需求阶段就考虑安全控制措施，而非事后修补。对于报表类组件，建议采用声明式查询语言替代直接SQL拼接，从根本上杜绝风险。