1. 一次典型后台管理系统的安全评估实战

最近在内部的一次安全评估项目中，我接触到了一个基于若依（RuoYi）框架构建的后台管理系统。这其实是一个非常典型的场景，很多中小型项目，无论是内部OA、CRM还是业务运营平台，都倾向于使用这类成熟的开源后台框架来快速搭建。若依凭借其前后端分离、模块化、代码生成器等特性，确实极大地提升了开发效率。但作为安全从业者，我深知“效率”与“安全”往往需要权衡。这次评估的目标，并非要证明某个框架“不安全”，而是希望通过一个真实案例，来梳理针对这类标准化、组件化系统的安全评估思路与方法论。毕竟，攻击者不会因为系统用了流行框架而手下留情，他们恰恰会研究这些框架的通用模式和常见配置缺陷。

这次实战的核心，是模拟一个具备基本安全意识的攻击者（或内部红队）视角，对一套部署在公网、默认配置居多的若依后台系统进行渗透测试。整个过程更像是一次系统的“健康体检”，旨在发现那些由于快速上线、默认配置、二次开发疏忽或组件集成带来的潜在风险。你会发现，很多高危漏洞并非源于框架核心代码的致命缺陷，而是源于“想当然”的部署和使用方式。下面，我将完整复盘这次评估的关键路径、发现的问题、背后的原理以及修复建议，希望能为开发者和安全工程师提供一份可落地的自查清单。

2. 前期信息收集与资产测绘

渗透测试的第一步永远是信息收集，对于若依这类有显著特征的系统更是如此。盲目测试效率极低，有方向的信息搜集能事半功倍。

2.1 指纹识别与版本确认

若依框架有非常明显的指纹特征。访问目标系统首页，查看网页源代码，通常能在注释、引用的静态资源路径（如/ruoyi/、/profile/）或前端JavaScript全局变量中找到“RuoYi”字样。此外，其登录页面、内置图标、默认的“若依后台管理系统”标题都是强指纹。通过浏览器开发者工具的网络（Network）面板，观察加载的JS、CSS文件命名规则（如ruoyi.js，index.xxxxxx.css带有哈希值），也能快速确认。

更关键的是确定其具体版本。若依的社区版（单体、前后端分离、微服务）不同版本间，甚至与商业版之间，可能存在已知的漏洞差异。方法包括：

1. 接口探测：尝试访问一些默认接口，如/prod-api/captchaImage（获取验证码）、/common/download（通用下载）等，响应头或返回的JSON数据结构可能包含版本信息。
2. 错误信息：故意构造非法请求（如访问不存在的路径/ruoyi/admin），有时错误页面会泄露框架版本、Spring Boot版本甚至服务器路径。
3. 依赖分析：如果存在未授权访问的依赖信息接口（如Spring Boot Actuator的/actuator/env或/actuator/mappings，但若依默认不开启），可以获取到详尽的组件版本。

注意：信息收集阶段务必控制请求频率，避免触发WAF或风控规则的告警。使用代理工具（如Burp Suite）的爬虫功能时，要设置合理的延迟和线程数。

2.2 目录与接口枚举

明确了是若依系统后，下一步就是扩大攻击面，寻找可能被遗忘在公网的管理后台、测试接口、文档页面等。

1. 常见目录爆破：使用目录字典进行扫描，重点关註：

   • 后台登录入口：除了常见的/admin，/login， 若依默认是/根目录即登录页，但二次开发后可能改变。/system，/monitor等目录也可能存在。
   • 文档与调试接口：/swagger-ui.html，/v2/api-docs，/doc.html（Knife4j），/druid/index.html（阿里Druid监控）。
   • 静态资源与上传目录：/profile/upload/（若依默认上传路径），/templates/，/webjars/。
   • actuator端点：如果开发未做安全配置，/actuator，/actuator/heapdump，/actuator/env等端点可能暴露敏感信息。

2. API接口梳理：通过爬取网站所有链接，并结合Burp Suite的代理历史记录，梳理出系统的API结构。若依前后端分离版本，前端通过调用/prod-api/或/api/为前缀的接口与后端交互。分析这些接口的路径规律（如/system/user/list，/monitor/online/list），有助于理解业务逻辑和数据流，为后续的越权、注入等测试做准备。

在这个阶段，我通常会整理出一张系统资产地图，标注出已识别的登录入口、功能模块接口、疑似敏感端点，并初步判断其访问权限（是否需要认证）。

3. 认证与会话管理漏洞挖掘

后台系统的核心大门就是登录认证。这里往往是安全配置的“重灾区”。

3.1 默认凭证与弱口令

这是最经典也最高效的突破口。若依框架的默认管理员账号是admin/admin123。在实战中，令人惊讶的是，仍有相当一部分上线系统未修改此默认密码，或者修改为admin@123，Admin123!这类简单变形。针对此点的测试包括：

• 直接尝试默认口令：对识别出的后台登录接口进行尝试。
• 弱口令爆破：使用常见的弱口令字典，结合系统可能使用的命名规则（如公司名+年份）进行爆破。必须注意：爆破前需确认验证码机制。若依默认登录带有验证码，但有时开发为了方便测试会在测试环境关闭验证码，或者验证码逻辑存在缺陷（如可重复使用、前端校验等）。

3.2 验证码逻辑缺陷

验证码是防爆破的关键，但其实现可能存在多种问题：

1. 验证码可重用：在一次会话中，获取的验证码在多次登录请求中均有效。
2. 验证码前端校验：验证码仅在客户端JavaScript进行校验，提交到服务器的请求中不包含或服务器不校验验证码参数。
3. 验证码空值绕过：直接删除请求中的验证码参数（如captcha），或者置为空，服务器可能因逻辑不严谨而跳过校验。
4. 验证码复杂度低：若依默认是数字验证码，且位数较短，理论上存在被机器学习识别破解的可能，但实战成本较高。

测试方法是在Burp Suite中抓取登录包，然后发送到Intruder模块，固定正确的验证码和用户名，对密码字段进行爆破；或者尝试修改/删除验证码参数，观察响应是否不同。

3.3 会话固定与注销缺陷

登录后的会话管理同样重要。

• 会话固定：在用户登录前，系统就为其分配了一个Session ID。攻击者可以先获取一个未认证的Session ID，诱导管理员用这个Session ID登录（例如通过一个包含该SID的链接），从而使攻击者获得已认证的会话。测试时，观察登录前后JSESSIONID是否发生变化。若不变，则存在风险。
• 注销不彻底：用户点击“退出登录”后，服务器端的会话（Session）是否被真正销毁？还是仅仅清除了前端的Token？尝试用退出前的Token或Cookie继续访问需要认证的接口（如/system/user/profile），如果仍能返回数据，则说明注销机制有缺陷。

4. 越权访问与业务逻辑漏洞

突破认证后，进入系统内部，业务逻辑层面的漏洞是提权和获取敏感数据的关键。若依作为一个后台框架，其权限模型（基于角色/菜单）的实现是否严谨，直接决定了系统的安全性。

4.1 水平越权与垂直越权

这是后台系统最常见的逻辑漏洞之一。

• 水平越权：同一层级用户能访问或操作本应属于其他用户的资源。例如，用户A和用户B都是普通员工。通过修改请求参数中的用户ID（如/system/user/getInfo?userId=2），用户A能否获取到用户B的详细信息？在用户管理、订单管理、个人资料编辑等模块需重点测试。
• 垂直越权：低权限用户能执行高权限用户的操作。例如，一个只有“查看”权限的角色，能否通过直接调用“新增”或“删除”的接口（如POST /system/role/add）成功执行操作？这通常源于后端接口仅依赖前端菜单隐藏或按钮禁用，而未在接口层进行角色或权限码校验。

测试方法：使用两个不同权限的测试账号（如一个管理员admin，一个普通用户test）。用低权限账号（test）的会话Token，去尝试访问或操作本应属于高权限账号（admin）的API接口。Burp Suite的Repeater模块是进行此类测试的利器。

4.2 接口未授权访问

某些接口本应需要认证，但因开发疏忽，未添加@RequiresPermissions或@PreAuthorize等注解，或安全拦截器配置路径有误，导致可以直接访问。

• 数据字典/配置信息泄露：尝试访问/system/dict/data/type?dictType=sys_user_sex这类数据字典接口，可能泄露系统内部编码。
• 文件读取/下载：若依的通用下载接口/common/download?fileName=xxx，如果文件名参数可控且未做严格路径校验，可能造成任意文件读取（Path Traversal）。例如，尝试../../../etc/passwd。
• 信息查询接口：某些为了前端展示便利而提供的公开信息接口，可能泄露过多数据。例如，一个查询所有用户的简单列表接口，可能返回了用户的手机号、邮箱等敏感字段。

4.3 权限模型绕过：前端路由与按钮控制

在前后端分离的若依中，权限控制分为前端和后端两层。

• 前端路由控制：基于用户角色动态生成菜单路由。但攻击者可以通过直接输入URL（如/#/system/user）来尝试访问未授权的页面。如果该页面能正常加载（即使数据为空），说明前端路由守卫可能存在问题，至少暴露了页面结构。
• 前端按钮控制：按钮的显示/隐藏通过v-hasPermi指令控制。但这只是UI层面的控制。通过浏览器开发者工具，可以轻松找到“新增”、“删除”等按钮对应的API请求，然后直接在Burp Suite中重放或构造该请求，这是测试垂直越权的核心。

核心原则：前端的任何隐藏、禁用都不可信，必须以后端接口的权威校验为准。评估时要彻底忽略前端限制，直接针对API进行测试。

5. 注入类与组件漏洞深度利用

当逻辑漏洞挖掘殆尽，就需要转向更底层的技术漏洞。若依基于Spring Boot，其自身及集成的第三方组件可能带来风险。

5.1 SQL注入

虽然MyBatis框架通常使用#{}预编译方式能有效防止SQL注入，但在动态SQL、模糊查询、ORDER BY排序字段、或者不当使用${}进行字符串拼接时，风险依然存在。

• 模糊查询场景：例如用户管理中的搜索功能，后端SQL可能是WHERE user_name LIKE '%${name}%'。如果使用${}，则存在注入可能。测试时在搜索框输入' OR '1'='1或' AND SLEEP(5)--，观察响应时间或结果。
• 排序字段：前端表格点击列头排序，传递的排序字段名（如orderByColumn=createTime）如果直接拼接进SQL语句，也可能导致注入。尝试修改为orderByColumn=createTime AND SLEEP(5)。
• MyBatis Generator生成的代码：若依的代码生成器产生的Example类，如果开发者在复杂查询中手动拼接了SQL片段，需重点审查。

测试时需结合Burp Suite的Scanner和手工Payload，并观察数据库错误信息是否被直接返回（这本身也是一个信息泄露点）。

5.2 不安全的直接对象引用与文件上传

• IDOR：与水平越权类似，但更侧重于通过修改关键标识符（如文件ID、订单号）来访问未授权的资源。例如，通过/system/notice/getInfo?noticeId=1查看公告，尝试修改noticeId=0或一个非常大的数字，可能访问到已删除或草稿状态的公告。
• 文件上传漏洞：若依的上传功能通常封装在/common/upload接口。测试点包括：
  1. 文件类型绕过：检查是否仅校验了文件扩展名（如.jpg），而忽略了文件内容（Magic Number）或Content-Type。尝试将一句话木马内容保存为shell.jpg.php或修改Burp请求中的Content-Type: image/jpeg。
  2. 路径穿越：在文件名中注入目录遍历序列，如../../../tmp/shell.jsp，尝试将文件上传到非预期目录。
  3. 重写覆盖：如果上传路径和文件名可控，可能覆盖已存在的系统关键文件（如JSP文件、配置文件）。

5.3 第三方组件漏洞

这是影响范围最大的一类漏洞，往往一个组件漏洞就能导致服务器被直接控制。

• Fastjson反序列化：若依历史版本中可能集成旧版本的Fastjson，存在多个高危反序列化漏洞（如1.2.24， 1.2.47等）。需要识别其版本，并关注是否存在接收JSON参数且未做严格类型控制的接口。
• Shiro权限框架漏洞：若依使用Shiro做安全框架。需关注Shiro的RememberMe反序列化漏洞（Shiro-550， Shiro-721），以及权限校验绕过漏洞（如CVE-2020-1957， CVE-2020-11989）。测试方法包括使用已知的Shiro密钥爆破工具，以及尝试使用;、/、..等特殊字符绕过路径匹配。
• Druid未授权访问：若依集成Druid数据库连接池，其监控页面/druid/index.html如果未设置访问密码，或密码弱，会导致数据库SQL执行情况、数据源配置等敏感信息完全暴露，甚至可以在页面上直接执行SQL语句，危害极大。
• Swagger/OpenAPI未授权访问：如果开发环境配置被误带到生产环境，/swagger-ui.html等页面会暴露所有API接口及其参数，相当于给攻击者提供了一份详细的“攻击说明书”。

对于组件漏洞，保持依赖库版本更新是最有效的防御手段。在评估时，要尽可能收集系统使用的组件及其版本号。

6. 配置缺陷与信息泄露

许多安全问题源于不安全的默认配置或运维疏忽。

6.1 应用服务器与中间件配置

• 错误信息详细化：Spring Boot默认的server.error.include-stacktrace配置在开发时可能为always，如果生产环境未改为never，那么当应用抛出异常时，完整的Java堆栈信息、SQL语句、甚至部分代码片段会直接返回给用户，这为攻击者提供了宝贵的调试信息。
• Actuator端点暴露：Spring Boot Actuator提供了丰富的监控和管理端点。若依默认可能不开启，但如果在application.yml中配置了management.endpoints.web.exposure.include=*且未做安全限制，那么/actuator/env（泄露所有环境变量、数据库密码）、/actuator/heapdump（可下载内存堆转储文件，从中分析敏感数据）、/actuator/mappings（所有接口映射）将完全暴露。
• 目录列表开启：如果静态资源目录（如Nginx/Apache配置）未关闭目录浏览功能，攻击者可能直接浏览到上传的文件目录，发现上传的漏洞文件。

6.2 源码与配置信息泄露

• Git源码泄露：在Web根目录下可能存在.git文件夹，如果未被正确删除，攻击者可以使用git-dumper等工具下载整个网站源码，从而进行白盒审计，发现隐藏接口、硬编码的密钥、数据库配置等。
• 备份文件泄露：常见的备份文件如wwwroot.zip，database.sql.bak，web.config.bak等，可能被遗留在Web目录下，直接访问即可下载。
• 配置文件泄露：尝试访问/application.yml，/application.properties，/config/application.yml等路径，看是否可以直接读取到数据库连接字符串、加密密钥等。

7. 从外网到内网的横向移动思路

在本次评估的假设场景中，如果成功通过Web漏洞获取了目标服务器的权限（例如通过文件上传获取Webshell，或利用反序列化漏洞执行命令），那么视角就从“外部渗透”转向了“内网横向移动”。虽然若依框架本身不直接涉及内网，但拿下的服务器往往是进入内网的跳板。

1. 信息收集（立足点）：获取Shell后，首先收集当前服务器的信息。包括：网络配置（ipconfig /all或ifconfig）、系统用户、进程列表、安装的软件（特别是安全软件、运维工具）、历史命令、密码本文件等。在Linux下，/etc/passwd，/etc/shadow（需提权），~/.bash_history，~/.ssh/目录都是关键目标。
2. 寻找数据库：若依的配置文件application.yml中通常明文或加密存储着数据库连接信息。拿到数据库密码后，可以尝试连接数据库。MySQL中可能存储着其他系统的密码哈希、业务敏感数据。如果数据库允许远程连接（默认可能只允许本地127.0.0.1），且当前服务器有双网卡，那么这台数据库服务器可能就是下一个内网目标。
3. 探测内网存活主机：利用当前服务器作为跳板，使用ping，nmap（如果已安装或可上传）、fscan等工具扫描内网网段（如192.168.0.0/24，10.0.0.0/8），发现其他存活的主机和服务（如SSH， RDP， Redis， MySQL等）。
4. 密码复用与哈希传递：在Web服务器上发现的密码（如数据库密码、后台用户密码），很可能被系统管理员在其他服务器或服务上复用。可以尝试用这些密码进行SSH、RDP爆破或登录其他Web应用。
5. 利用若依服务器上的客户端工具：服务器上可能安装了运维常用的客户端，如MySQL客户端、Redis-cli、MongoDB shell等。利用这些工具，配合已获取的密码，可以直接连接内网的其他数据库服务，进行数据窃取或进一步利用。

重要提示：内网渗透测试必须在获得明确授权和法律许可的范围内进行，严禁对非授权目标进行任何探测和攻击。上述思路仅用于安全评估和防御体系建设参考。

8. 修复与加固建议总结

基于以上渗透测试过程中发现或可能存在的风险点，为使用若依或类似框架的开发团队提供以下加固建议：

1. 修改所有默认凭证：第一时间修改超级管理员admin的默认密码，并强制所有用户使用强密码策略（长度、复杂度、定期更换）。
2. 强化认证机制：确保验证码后端校验有效且不可重用；考虑引入双因素认证（2FA）用于管理员登录；设置登录失败锁定策略。
3. 贯彻最小权限原则：后端每个接口必须添加细粒度的权限注解（如@PreAuthorize(“hasPermi(‘system:user:list’)”)），不能仅依赖前端控制。定期审计权限分配，避免权限过度集中。
4. 输入校验与输出编码：对所有用户输入进行严格的校验和过滤，使用预编译防止SQL注入，对输出到HTML页面的内容进行编码以防止XSS。文件上传功能要校验文件类型（白名单）、重命名文件、并限制上传目录的执行权限。
5. 安全配置检查：
   • 生产环境关闭debug模式和详细的错误信息回显。
   • 禁用或严格保护监控端点（如Druid， Actuator， Swagger），必须设置强密码或限制访问IP。
   • 确保.git目录、备份文件、配置文件等敏感资源不在Web目录下或无法被直接访问。
6. 依赖组件安全管理：定期使用Mavenmvn dependency:check或依赖扫描工具（如OWASP Dependency-Check）检查项目依赖，及时升级存在已知漏洞的第三方库（Fastjson， Shiro， Log4j2等）。
7. 会话安全：确保登录后更新Session ID（防止会话固定）；设置合理的会话超时时间；Token或Cookie使用HttpOnly和Secure属性。
8. 网络与主机层加固：对后台管理系统实施网络访问控制（如仅允许办公网IP段访问）；服务器操作系统及时打补丁；关闭不必要的端口和服务。

安全是一个持续的过程，而非一次性的任务。对于基于若依这类优秀框架的开发，在享受其便捷的同时，必须将安全思维嵌入到开发、测试、部署、运维的全生命周期中。框架提供了基础的安全骨架，但最终系统的安全性，取决于开发团队如何填充和加固这个骨架。