1. 项目概述为什么选择若依作为代码审计的起点在安全从业者的圈子里若依RuoYi这个名字几乎无人不晓。它不仅仅是一个基于Spring Boot的权限管理系统更像是一个“国民级”的Java企业级开发脚手架。我选择它作为代码审计实战的切入点原因有三。第一它的普及度极高无数中小型公司、外包项目甚至一些内部系统都基于若依进行二次开发这意味着你挖到的漏洞很可能具有普适性实战价值拉满。第二它的代码结构清晰模块化做得不错对于新手来说不像一些庞杂的祖传项目那样让人无从下手是学习Java Web应用代码审计的绝佳“标本”。第三若依本身集成了大量常用功能如用户管理、角色权限、菜单管理、定时任务、系统监控等这些功能点恰恰是漏洞的高发区比如越权、SQL注入、文件上传、逻辑漏洞等几乎涵盖了Web安全的核心议题。所以这次实战的目标很明确我们不只停留在“看代码”而是模拟一个完整的白盒审计流程。从零开始在本地部署一套若依系统让它跑起来然后像一名真正的安全研究员一样带着问题去阅读代码结合动态调试和静态分析亲手挖出几个有代表性的漏洞。这个过程你会深刻理解一个功能从用户点击到数据库操作的完整链路以及在这条链路上开发者可能在哪里“埋了雷”。无论你是想入门代码审计还是想巩固Java安全知识这都是一次不可多得的动手机会。2. 环境准备与若依系统部署动手之前先把“战场”布置好。一个稳定、可复现的环境是后续所有审计和漏洞验证的基础。我强烈建议在虚拟机里操作方便随时快照和回滚。2.1 基础环境搭建首先我们需要一套标准的Java Web开发环境。若依的官方文档推荐使用JDK 1.8、Maven 3.x和MySQL 5.7。这里我选择JDK 8u202这是一个长期稳定的版本Maven 3.6.3以及MySQL 5.7.36。为什么不直接用最新的因为企业生产环境往往存在滞后性使用这些经典版本能更好地模拟真实目标。注意务必记录下你安装的每一个组件的具体版本号。在后续审计中如果遇到因环境差异导致的问题版本信息是首要的排查线索。安装过程不赘述重点是配置。Maven的settings.xml里建议配置阿里云的镜像仓库下载依赖会快很多。MySQL安装后记得创建一个新的数据库比如叫ry-vue字符集用utf8mb4。这些细节看似琐碎但能避免很多“明明跟着教程做却跑不起来”的尴尬。2.2 获取与编译若依源码若依的代码在Gitee和GitHub上都有托管。我们使用前后端分离的版本RuoYi-Vue这也是目前最主流的架构。直接克隆项目git clone https://gitee.com/y_project/RuoYi-Vue.git cd RuoYi-Vue项目根目录下通常有sql文件夹里面存放着数据库初始化脚本。按顺序执行ry_2021xxxx.sql基础数据和quartz.sql定时任务相关表将表结构导入刚才创建的ry-vue数据库。接下来是关键一步修改配置文件。找到后端项目通常是ruoyi-admin模块下的resources目录里的application-druid.yml。这里配置了数据库连接# 数据源配置 spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driverClassName: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/ry-vue?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLtrueserverTimezoneGMT%2B8 username: root password: your_password_here # 改成你的MySQL密码把url中的数据库名、username和password替换成你自己的配置。这里有个小技巧如果连接失败可以尝试将useSSLtrue改为useSSLfalse并确认MySQL服务是否已启动且允许远程连接本地localhost一般没问题。配置好后在项目根目录下执行Maven编译命令mvn clean package -DskipTests-DskipTests参数是为了跳过单元测试加快打包速度。编译成功后在ruoyi-admin/target目录下会生成一个ruoyi-admin.jar文件。2.3 启动后端与前端服务后端启动很简单进入target目录运行java -jar ruoyi-admin.jar看到控制台输出“RuoYi启动成功”字样并且没有报错说明后端服务已经跑起来了默认端口是8080。前端部分需要Node.js环境。进入项目中的ruoyi-ui目录先安装依赖npm install --registryhttps://registry.npmmirror.com同样这里使用了淘宝的npm镜像加速。安装完成后运行开发服务器npm run dev前端服务默认会在端口80启动。此时打开浏览器访问http://localhost应该能看到若依的登录页面。默认账号是admin密码是admin123。成功登录后一个完整的若依系统就在你的本地运行起来了。实操心得部署过程最容易出问题的地方就是依赖下载和环境配置。如果npm install或mvn clean package失败九成是网络问题或镜像源配置不对。耐心查看错误日志根据提示调整镜像源或代理设置。另外建议在部署成功后对整个虚拟机或服务器做一个快照命名为“纯净若依环境”。这样以后审计搞乱了可以瞬间恢复节省大量重装时间。3. 代码审计核心思路与工具链配置系统跑起来了现在可以进入正题——看代码。但面对成千上万个Java文件从哪里开始看怎么高效地看这就需要一套清晰的审计思路和顺手的工具。3.1 审计切入点与核心关注模块盲目阅读代码效率极低。我的习惯是“以功能为导向以数据流为线索”进行审计。具体到若依可以重点关注以下几个高危模块用户认证与授权模块这是越权漏洞的温床。重点关注LoginController、SysUserController以及权限校验的拦截器或过滤器如PreAuthorize注解的使用。数据管理模块任何涉及增删改查CRUD的地方都是SQL注入和逻辑漏洞的潜在风险点。例如SysUserMapper.xmlMyBatis的SQL映射文件、SysMenuService等。文件上传与下载模块在CommonController或独立的FileController中寻找文件上传功能检查后缀名过滤、内容校验、存储路径是否安全。系统监控与配置模块像Druid监控、Swagger接口、Actuator端点等如果配置不当如未授权访问会直接暴露敏感信息或成为攻击入口。第三方组件与依赖检查pom.xml文件看看引入了哪些第三方库如Fastjson、Shiro、Log4j2等这些组件的历史漏洞也需要关注。3.2 静态分析工具链配置工欲善其事必先利其器。仅靠肉眼和文本编辑器是远远不够的我们需要借助工具来提高审计效率。IDEIntelliJ IDEA (Ultimate版)这是Java开发者的首选。它的强大之处在于全局搜索(CtrlShiftF)快速定位关键词如select *、executeUpdate、RequestMapping等。调用链分析(CtrlAltH)选中一个方法可以查看它在哪些地方被调用理清代码执行路径。数据库工具可以直接连接项目配置的数据库查看表结构对照SQL语句理解数据操作。Git集成方便对比历史更改看看哪些代码是后来修补的修补点往往就是曾经的漏洞点。代码扫描工具Fortify SCA / SonarQube如果有条件可以使用Fortify进行自动化静态扫描。它能识别出大量的潜在安全缺陷如SQL注入、XSS、路径遍历等。虽然误报率不低但其扫描报告是一个非常好的“线索清单”可以指引我们进行人工深度审计。开源方案可以用SonarQube配合FindSecBugs插件。反编译工具JD-GUI / CFR如果审计的目标不是源码而是JAR/WAR包这些反编译工具就派上用场了。它们能将字节码还原成可读性较高的Java代码。HTTP代理工具Burp Suite / OWASP ZAP用于动态测试。在审计过程中我们需要发送特定的HTTP请求来验证漏洞Burp的Repeater、Intruder、Scanner模块不可或缺。我的典型工作流是先用IDEA打开项目利用其强大的代码导航功能对整体结构有一个把握。然后针对某个具体功能比如“用户管理”在IDEA中追踪从Controller到Service再到Mapper的完整调用链。同时打开Burp Suite配置浏览器代理在页面上操作该功能捕获HTTP请求。将请求发送到Repeater然后根据代码逻辑修改参数尝试触发异常行为或漏洞。这种“动静结合”的方式效率最高验证也最直接。4. 漏洞挖掘实战从入口点到漏洞验证理论说再多不如亲手挖一个洞来得实在。我们以若依系统中一个经典的、也是很多Java Web应用的通病——Thymeleaf模板注入为例来走一遍完整的审计流程。4.1 漏洞背景与原理浅析Thymeleaf是Spring Boot推荐的一款模板引擎。正常情况下它负责将后端数据渲染到HTML页面上。但是如果开发者错误地将用户输入直接拼接到模板路径或模板名称中并且这个拼接后的字符串最终被Thymeleaf引擎解析就可能造成模板注入。攻击者可以插入Thymeleaf表达式从而执行任意代码危害极大。4.2 静态代码追踪在IDEA中我们使用全局搜索 (CtrlShiftF) 寻找关键词。因为Thymeleaf渲染通常涉及视图解析我们可以搜索GetMapping或RequestMapping中返回字符串即视图名的控制器方法同时关注这些方法中是否有参数直接用于拼接视图路径。一个更精准的思路是搜索redirect:或forward:因为Spring MVC中重定向和转发有时会与视图解析耦合。在若依的代码库中搜索我们可能会在某个控制器比如处理错误页面的控制器或一些通用控制器中发现类似下面的代码模式GetMapping(/demo/page) public String getPage(String pageName) { // 危险操作未对pageName进行过滤直接拼接或返回 return admin/ pageName; }或者搜索Thymeleaf相关的解析方法如TemplateEngine.process()。在若依中我们重点检查CommonController或任何处理文件预览、内容加载的控制器。经过一番搜索和排查我们可能会定位到一个用于加载特定模块页面的接口。假设我们找到了一个方法它接收一个module参数并返回modules/ module /index这样的视图。这就是一个潜在的注入点。4.3 动态测试与漏洞验证找到可疑代码后我们需要通过Burp Suite进行动态验证。捕获请求在浏览器中找到调用该接口的前端功能点可能是某个下拉菜单选择或链接点击用Burp抓包。修改参数将捕获到的HTTP请求发送到Burp的Repeater模块。找到那个可疑的参数比如modulesystem尝试修改其值。构造PayloadThymeleaf模板注入的Payload通常形如__${T(java.lang.Runtime).getRuntime().exec(\calc\)}__::.x。但实际利用需要根据上下文调整。一个更通用的测试Payload是使用Thymeleaf表达式来触发一个明显的延迟以确认漏洞存在。例如可以尝试注入__${T(java.lang.Thread).sleep(5000)}__::.x。如果服务器响应延迟了5秒说明表达式被执行了。验证与利用如果延迟测试成功就可以尝试构造真正的命令执行Payload。但由于Java安全机制如SecurityManager和Spring Boot的默认配置直接执行系统命令可能受限。更常见的利用方式是进行文件读取、SSRF服务器端请求伪造或与其它漏洞结合。注意事项在本地测试时可以大胆尝试。但如果是在授权测试的真实环境绝对禁止使用可能造成破坏的Payload如rm -rf、format等。测试命令执行时可以使用ping命令并搭配DNSLog平台如dnslog.cn来接收外带请求这是一种无害的验证方式。例如执行ping然后在DNSLog平台查看是否有该子域的解析记录。4.4 漏洞挖掘深度技巧一次成功的挖掘往往需要一些“骚操作”和深入的理解。关注错误处理很多漏洞暴露在错误信息里。故意提交畸形参数看服务器返回的异常栈信息。栈信息里可能会泄露物理路径、SQL语句片段、使用的框架和方法这些都是宝贵的线索。追踪数据流的每一个环节看到一个用户输入username不要只看Controller。要一直追下去看Service层怎么处理Mapper的SQL怎么写甚至看MyBatis的XML文件里是否有动态SQLif、foreach标签这些地方是SQL注入的高发区。理解框架特性与“安全”配置比如Spring Boot默认的error.path配置、Druid监控台的默认访问路径、Swagger文档的地址。开发者如果忘记修改这些默认配置或没有做访问控制就会导致未授权访问。在若依中检查application.yml里关于这些组件的配置。对比历史版本在Gitee上查看若依项目的提交历史。关注那些标记为“fix”、“security”、“漏洞”的commit。看看开发者修复了什么问题怎么修的。这不仅能帮你找到已修复的漏洞点更能教你修复漏洞的正确姿势理解漏洞的根源。通过这样一个从信息搜集、静态分析到动态验证的完整流程你挖到的不仅仅是一个CVE编号更是对Java Web应用安全缺陷的深刻认知。这种能力是任何自动化工具都无法替代的。5. 高频漏洞模式归纳与审计清单经过对若依以及类似框架的多次审计我总结出一些高频出现的漏洞模式。你可以把下面这个清单当作你的审计“检查单”在查看代码时逐一核对。漏洞类型常见代码位置/特征审计关键点若依中的潜在风险点示例SQL注入MyBatis Mapper XML文件、Select注解、JdbcTemplate、String拼接的SQL语句。寻找${}的使用这是参数拼接非预编译检查动态SQL标签(if,foreach)内的参数是否经过过滤。用户管理、数据字典、日志查询等带搜索框的功能对应的Mapper文件。越权访问Controller方法上的权限注解(PreAuthorize,RequiresPermissions)、自定义拦截器、Session/Token校验逻辑。检查注解是否齐全、权限字符串是否硬编码且与前端菜单权限匹配、是否有接口漏加了权限控制。查看所有RequestMapping注解的方法特别是那些操作数据增删改的接口。文件上传漏洞文件上传控制器、工具类如FileUploadUtils、配置中的允许后缀列表。检查是否仅在前端验证后缀、后端是否做二次校验、是否校验文件头MIME Type、存储路径是否可控、文件名是否随机化。系统工具-文件上传功能对应的后端代码。路径遍历文件下载、读取配置文件、模板包含等功能。参数中包含../等目录跳转符。检查文件路径参数是否经过标准化normalize和合法性校验是否将用户输入直接拼接在基础路径后。日志文件下载、头像查看、导入导出模板加载等功能。反射型/存储型XSS返回给前端的数据未经过转义、富文本编辑器内容保存与展示。检查后端输出到HTML、JavaScript、属性中的变量是否使用了合适的转义函数如Thymeleaf的th:text默认转义。用户昵称、公告内容、个人简介等用户可控且会回显的字段。不安全的反序列化使用ObjectInputStream读取外部数据、使用存在漏洞的组件如Fastjson, Jackson。检查是否接收序列化数据、pom.xml中相关组件的版本是否存在已知漏洞。RPC接口、缓存数据读取、第三方接口交互处。敏感信息泄露错误页面、调试接口(/actuator)、配置文件、注释、客户端JS。检查生产环境是否关闭了debug模式、actuator端点是否鉴权、代码注释中是否包含密码/密钥。访问不存在的路径看错误信息、检查application-prod.yml配置。逻辑漏洞业务流程的关键判断点如订单支付、状态修改、优惠券领取、密码重置。梳理核心业务流程图寻找每个状态判断是否可被绕过、步骤是否可乱序、验证是否可重放。用户注册短信轰炸、密码重置Token泄露、权限修改流程。拿着这份清单去审视若依的代码你会发现很多值得深挖的地方。例如在审计“用户管理”的编辑功能时不仅要看它是否检查了当前用户能否修改目标用户垂直越权还要看修改的字段里是否包含了用户本不应自行修改的字段如userType管理员标识这属于水平越权或业务逻辑问题。6. 审计报告撰写与漏洞修复建议挖到漏洞不是终点清晰地呈现它并推动修复才是安全工作的价值所在。一份专业的审计报告能让开发人员快速理解问题并愿意配合修复。6.1 报告核心要素一份好的漏洞报告至少应包含以下部分漏洞标题简明扼要如“若依系统XX模块Thymeleaf模板注入漏洞”。风险等级通常分为“高危”、“中危”、“低危”、“信息”。可根据CVSS标准或内部规范定级。影响版本明确指出受影响的若依版本号如“RuoYi-Vue 4.7.0”。漏洞描述用一两句话说明这是什么漏洞可能造成什么影响。漏洞细节定位信息完整的类名、方法名、代码行号。例如com.ruoyi.web.controller.system.SysProfileController.updateAvatar()第85行。请求与响应提供完整的、可重放的HTTP请求数据包Burp Suite可以直接复制Copy as curl command或Copy to file。以及服务器正常的响应和攻击时的响应。漏洞原理分析结合代码片段图文并茂地说明用户输入如何经过处理最终触发了漏洞。可以画简单的数据流图。复现步骤按步骤列出从登录到触发漏洞的详细操作让任何一个人都能按照步骤复现。修复建议给出具体、可操作的修复方案。最好是直接提供修复后的代码diff差异对比。6.2 修复建议的给出艺术给修复建议不是简单地丢一句“要对输入做过滤”。那等于没说。好的建议应该对症下药针对漏洞根因。如果是SQL注入就建议使用预编译#{}替换拼接${}如果是路径遍历就建议使用Path.get().normalize()并检查是否跳出基目录。提供代码示例直接给出修改后的代码块让开发可以“抄作业”。例如// 修复前危险 String viewName modules/ module /index; return viewName; // 修复后安全 // 使用白名单校验module参数 ListString allowedModules Arrays.asList(system, monitor, tool); if (!allowedModules.contains(module)) { throw new IllegalArgumentException(Invalid module parameter); } String viewName modules/ module /index; return viewName;考虑兼容性与性能提出的方案不能破坏现有功能最好也不要引入明显的性能损耗。推荐安全实践除了修复当前点还可以建议一些长期安全增强措施如“建议在项目层面引入OWASP ESAPI进行统一的输入输出处理”、“建议定期使用依赖扫描工具如OWASP Dependency-Check更新第三方库”。6.3 沟通与跟进报告写好了怎么交给开发团队我的经验是先私下沟通如果可能先和负责该模块的开发负责人简单沟通一下说明你发现了一个可能的安全问题想和他确认一下。这比直接扔一份报告过去更友好。提交正式报告通过团队约定的渠道如JIRA、GitLab Issue、内部安全平台提交详细的报告。跟进修复进度修复过程中开发可能会对修复方案有疑问主动提供帮助。修复完成后务必进行回归测试确认漏洞已被正确修复且没有引入新问题。复盘与分享漏洞修复后可以在团队内部进行一次简单的分享讲解这个漏洞的成因和修复方法。这能提升整个团队的安全意识达到“修复一个点提升一个面”的效果。代码审计是一场与开发者思维博弈的旅程。它要求你既能像攻击者一样思考寻找逻辑的缝隙又要像建设者一样周全提出稳固的修补方案。通过对若依这样一个典型项目的深度实战你收获的将不仅仅是几个漏洞更是一套行之有效的安全研究方法论。这套方法论可以迁移到任何你未来将要面对的Java项目乃至其他语言和技术栈的项目中去。记住保持好奇耐心追踪大胆假设小心验证安全的世界里总有新的东西等着你去发现。
