某企业MES泄露源码审计
字数 3574
更新时间 2026-02-27 13:05:19

某企业MES泄露源码审计教学文档

文档概述
本教学文档基于先知社区一篇题为《某企业MES泄露源码审计》的技术分析文章（发布于2026年2月13日）编写。该文档对一套泄露的某企业MES（制造执行系统）源码进行了全面的安全审计，旨在作为代码审计与漏洞挖掘的学习案例。目标读者为具备一定Java Web安全基础的安全研究人员、开发人员及渗透测试工程师。

1. 目标系统架构分析
被审计的MES系统采用经典的SSH（Struts2 + Spring + Hibernate）架构进行开发，前端使用JSP进行页面渲染。这种架构在传统企业应用中较为常见，其安全性依赖于框架的安全配置与应用层自身的安全编码。

2. 鉴权机制分析
审计的第一步是分析系统的访问控制（鉴权）机制。

  • 配置文件检查：通过审查 web.xml 文件，未发现配置全局的鉴权过滤器（Filter）。
  • Struts2拦截器：鉴权功能通过在 struts.xml 配置文件中自定义拦截器栈（interceptor stack）实现。审计发现了一个注释清晰的鉴权拦截器栈。
  • 鉴权逻辑：该拦截器主要通过验证用户会话（Session）中是否存在特定用户信息来进行权限判断。
  • 白名单接口：在 struts.xml 配置中，未配置上述鉴权拦截器的接口即为白名单接口，无需认证即可访问。这是后续漏洞利用中需要重点关注的点。

3. 框架级漏洞 - Struts2 远程代码执行 (RCE)
由于系统基于Struts2框架开发，且版本较低（2.0.11.2），存在多个已知的高危Struts2漏洞。

  • 受影响版本：Struts 2.0.0 - 2.3.15。
  • 相关漏洞：经版本比对，该系统可能受以下漏洞影响：
    • S2-005 (CVE-2010-1870)：通过ParameterInterceptor的OGNL表达式注入。
    • S2-009 (CVE-2011-3923)：通过参数名引用的OGNL二次评估。
    • S2-015 (CVE-2013-2134/2135)：在通配符匹配的Action名称中嵌入OGNL表达式。
    • S2-016 (CVE-2013-2251)：通过 redirect: 或 redirectAction: 前缀注入OGNL表达式。此漏洞通常无需认证即可利用，危害极高。
  • 审计结论：该低版本Struts2框架存在可利用的RCE漏洞，攻击者可能以此直接获取服务器控制权。

4. 应用层漏洞 - SQL注入
审计发现了多处SQL注入漏洞，均源于未对用户输入进行有效过滤，并将输入直接拼接至HQL（Hibernate Query Language）语句中。HQL最终会被转换为SQL执行，因此存在与传统SQL注入相同的风险。

  • 漏洞模式：漏洞代码模式高度相似。在 Service 层的 queryForPage 方法中，调用了一个 getHqlAppend 方法。该方法从HTTP请求参数（param）中提取值，并直接拼接到HQL查询语句（hqlStr）中，未进行任何过滤或参数化处理。
  • 具体漏洞点与利用：
    1. 第一处：位于 TbSysAdviseMessageAction 的 find 方法。通过GET请求参数 siteName 注入。
      • 接口：/cmt/findMessages.action
      • POC：GET /cmt/findMessages.action?siteName=1%' OR '1'='1&...
    2. 第二处：位于 TbSysImagesAction 的 find 方法。通过POST请求参数 userName、imageName、fileCategory 等注入。
      • 接口：/cmt/findImages.action
      • POC：POST /cmt/findImages.action （Body: userName=admin' AND 1=1--）
    3. 第三处：位于 SysMenuManagerAction 的 findPage 方法。通过GET请求参数 menuName 或 parentName 注入。
      • 接口：/cmt/menuManager.action
      • POC：GET /cmt/menuManager.action?menuName=1%' OR '1'='1

5. 应用层漏洞 - 任意文件读取
发现三处任意文件读取漏洞，允许攻击者读取服务器上的任意文件（如配置文件、源代码、敏感数据等）。

  • 漏洞模式：程序直接使用用户控制的输入（文件名或文件路径）拼接成绝对路径，然后读取文件内容并输出到HTTP响应中。
  • 具体漏洞点与利用：
    1. 第一处：位于 TbSysImagesAction 的 toDown -> download 方法。fileName 参数未过滤。
      • 接口：/cmt/downloadImages.action
      • POC：GET /cmt/downloadImages.action?fileName=../../etc/passwd
    2. 第二处：位于 TbSysFileAction 的 download 方法。fileName 参数未过滤。
      • 接口：/cmt/downloadLayout.action
      • POC：GET /cmt/downloadLayout.action?fileName=../../WEB-INF/web.xml
    3. 第三处：位于JSP文件 rapoo/manage/upload/imagesPreview.jsp。直接读取 imagesPath 参数指定的文件。
      • 接口：/cmt/rapoo/manage/upload/imagesPreview.jsp
      • POC：GET /cmt/rapoo/manage/upload/imagesPreview.jsp?imagesPath=../../WEB-INF/classes/config.properties

6. 应用层漏洞 - 任意文件上传
发现两处任意文件上传漏洞，由于未对上传文件的扩展名、内容做任何检查，且使用了用户控制的原始文件名，导致攻击者可上传恶意文件（如JSP Webshell）并执行。

  • 漏洞模式：使用Struts2的文件上传机制，获取上传文件的原始文件名（uploadFileName），直接与固定上传目录（uploadUrl）拼接，然后写入磁盘。未做后缀过滤，且存在目录穿越风险。
  • 具体漏洞点与利用：
    1. 第一处：位于 TbSysImagesAction 的 upload 方法。
      • 接口：/cmt/uploadImages.action
      • POC：构造一个 multipart/form-data 的POST请求，上传一个包含恶意代码的 test.jsp 文件。
    2. 第二处：位于 TbSysFileAction 的 upload 方法。
      • 接口：/cmt/uploadFile.action
      • POC：同上，构造请求上传恶意JSP文件。

7. 总结与修复建议
本次审计揭示了一套典型老旧企业应用系统的常见安全风险：

  • 框架陈旧且未更新：使用存在已知RCE漏洞的低版本Struts2框架，是最高危的风险。
  • 输入验证缺失：在所有SQL注入、文件读取、文件上传漏洞中，根本原因均为完全信任用户输入，未做任何验证、过滤或参数化处理。
  • 不安全的数据流传递：用户输入从Controller层到Service层，最终拼接至数据库查询或文件操作，全程缺乏安全校验。

修复建议：

  1. 立即升级/修复框架：将Struts2框架升级到最新安全版本，或应用官方安全补丁。
  2. 实施参数化查询：将所有数据库查询（HQL）改为使用预编译（PreparedStatement）或Hibernate的参数化查询（setParameter），杜绝SQL注入。
  3. 强化文件操作安全：
    • 对文件读取功能，采用白名单机制限制可读取的路径和文件类型。
    • 对文件上传功能，禁止使用用户提供的文件名，应使用随机生成的文件名（如UUID）保存；对文件内容进行严格校验（如文件头、MIME类型）；将上传目录设置为不可执行脚本。
  4. 增加全局输入验证：在拦截器或过滤器中增加对关键参数的格式、长度、类型检查。
  5. 最小化白名单：重新评估并严格限制无需鉴权的接口（白名单）范围。
  6. 代码安全培训：对开发团队进行安全编码培训，建立代码审计流程，在开发阶段杜绝此类漏洞。
 全屏