1. 项目概述与漏洞背景最近在梳理一些开源项目的安全公告时XWiki的一个路径遍历漏洞CVE-2025-55747引起了我的注意。这个漏洞编号看着新鲜但本质上又是一个经典的“输入验证不严”导致的安全问题。简单来说攻击者可以通过构造特殊的请求让XWiki服务器读取到本不应该被外部访问的敏感文件比如数据库配置文件、系统日志甚至是包含密码的配置文件。对于任何一个部署在公网上的Wiki系统来说这都意味着巨大的风险。XWiki本身是一个功能强大的企业级Wiki和协作平台很多团队用它来做知识管理、项目文档甚至是一些轻量级的应用开发。正因为其应用广泛一旦出现这种能直接泄露核心配置的漏洞影响面就非常大了。官方给出的影响版本是低于16.10.7和低于17.4.0-rc-1的所有版本这意味着大量正在运行的旧版本实例都可能暴露在风险之下。我之所以决定动手复现这个漏洞一方面是为了验证其真实危害理解攻击者可能的利用路径另一方面也是给自己和团队提个醒在自建或维护类似系统时输入过滤和路径解析这块儿必须得打起十二分精神稍有不慎就可能给攻击者开个后门。复现这类漏洞环境搭建是关键的第一步。我们需要一个存在漏洞的XWiki版本一个可控的测试环境以及一些基本的Web安全测试工具。整个过程不仅仅是“按一下按钮”更重要的是理解漏洞触发的原理、请求是如何被错误解析的、以及修复补丁到底改了哪里。只有这样下次再遇到类似的问题我们才能更快地定位和防御。接下来我就把这次从零开始的复现过程、踩过的坑以及一些思考详细地记录下来。2. 漏洞原理深度解析2.1 路径遍历漏洞的核心机制路径遍历也叫目录穿越是Web安全领域一个老生常谈但屡禁不止的高危漏洞。它的核心问题在于应用程序在处理用户提供的文件路径参数时没有进行充分的规范化Canonicalization和合法性校验导致攻击者可以通过包含../上级目录或类似序列的输入突破应用程序设定的访问目录边界访问到文件系统上的任意文件。在标准的Web应用中通常会有这样的逻辑用户请求一个资源比如/download?fileuser_guide.pdf后端代码会基于一个基准目录例如/var/www/uploads/拼接上用户传入的file参数形成最终的文件路径/var/www/uploads/user_guide.pdf然后读取并返回给用户。问题就出在这个“拼接”和“解析”的过程。如果攻击者将file参数改为../../../etc/passwd拼接后的路径就变成了/var/www/uploads/../../../etc/passwd。经过操作系统路径解析后../会向上回退目录最终实际访问的路径就跳出了/var/www/uploads/指向了系统的/etc/passwd文件。注意现代编程语言和Web框架通常都提供了安全的路径处理函数如Java的Path.normalize()、getCanonicalPath()但开发者如果错误地使用了字符串拼接或者在使用安全函数前没有对输入进行过滤例如过滤空字节%00仍然会导致漏洞。2.2 CVE-2025-55747 在XWiki中的具体成因根据公开的漏洞通告和后续对补丁代码的分析CVE-2025-55747的根源在于XWiki对某些特定请求中的参数处理不当。XWiki作为一个复杂的Java应用其内部有很多处理资源请求的机制比如附件下载、皮肤Skin或模板Template文件的加载、以及一些通过REST或WebDAV接口访问的资源。我通过搭建漏洞环境并抓包分析发现漏洞触发的关键点之一与处理“资源URL”的代码逻辑有关。攻击者可以构造一个特殊的HTTP请求其中包含经过编码的目录遍历序列如%2e%2e%2f即../的URL编码形式。当XWiki的某个Servlet或资源处理器接收到这个请求时它可能直接使用HttpServletRequest.getPathInfo()或类似方法获取请求路径然后将其与服务器上的基础资源目录进行拼接。漏洞产生的具体场景可能是这样的假设XWiki有一个用于提供静态资源如CSS、JS、图标的Servlet其映射路径为/resources/*。正常请求/resources/skins/flamingo/style.css会返回对应的样式表。然而如果请求路径是/resources/skins/flamingo/../../WEB-INF/xwiki.cfg并且后端代码没有对路径中的..进行过滤和规范化那么经过路径解析后服务器就可能尝试去读取位于Web应用根目录下WEB-INF/xwiki.cfg这个敏感的配置文件。WEB-INF目录在Java Web应用中受保护其下的文件通常无法通过直接URL访问但通过这种路径遍历的方式保护就被绕过了。更深层次的原因在于负责处理这类请求的组件可能依赖了某些默认配置或过时的库这些库在路径解析时没有进行严格的安全检查。或者开发者在实现自定义的资源处理器时手动拼接了用户输入和基础路径而遗漏了关键的规范化步骤。2.3 漏洞的危害与影响范围这个漏洞被评为高危CVSS 7.5其危害性主要体现在以下几个方面敏感信息泄露这是最直接的危害。攻击者可以读取WEB-INF/目录下的所有配置文件例如xwiki.cfg主配置文件可能包含数据库连接参数、加密密钥等。xwiki.properties扩展属性文件可能包含邮件服务器配置、第三方API密钥。hibernate.cfg.xml数据库映射配置文件明文包含数据库用户名和密码。web.xml应用部署描述符可能泄露内部Servlet映射和安全约束信息。源码泄露在某些部署方式下攻击者可能遍历到应用的Java源码文件.java或.class为进一步的代码审计和挖掘更深层次的漏洞如逻辑漏洞、反序列化漏洞提供素材。系统文件泄露如果Web应用进程具有足够的文件系统读取权限这在一些配置不当的容器中很常见攻击者甚至可以突破Web应用目录读取服务器操作系统上的敏感文件如/etc/passwd、/etc/shadow、/proc/self/environ环境变量可能包含密钥等导致服务器沦陷。成为攻击跳板获取的数据库凭证可能允许攻击者直接连接后台数据库进行数据窃取或篡改。获取的加密密钥可能用于解密XWiki中存储的其它加密内容或者伪造会话。从影响范围看官方通报全球有数千个暴露在公网的XWiki实例可能受影响。对于企业内部部署的XWiki如果其管理界面或某些服务端口暴露在内网同样存在被内部攻击者利用的风险。任何使用受影响版本且未及时打补丁的XWiki实例都应被视为潜在的风险点。3. 本地漏洞复现环境搭建3.1 环境与工具准备复现漏洞需要一个隔离、可控的环境。我选择在本地虚拟机中进行这样即使操作失误也不会影响任何生产系统。1. 虚拟机环境操作系统Ubuntu 22.04 LTS。选择Linux是因为其作为服务器更常见且路径表示与漏洞利用更相关。资源配置2核CPU4GB内存20GB磁盘空间。这个配置运行一个XWiki实例绰绰有余。网络虚拟机使用NAT网络模式仅主机可访问隔绝外部网络。2. 漏洞软件版本根据公告我们需要一个低于修复版本的XWiki。我选择了XWiki 16.10.6作为靶标因为它正好是16.10.7之前的一个标准版本易于获取和复现。下载地址可以从XWiki官网的历史版本存档或Maven仓库找到。例如https://maven.xwiki.org/releases/org/xwiki/platform/xwiki-platform-distribution-war/16.10.6/文件通常是一个WAR包如xwiki-platform-distribution-war-16.10.6.war。3. 中间件与数据库XWiki通常运行在Servlet容器中并需要数据库支持。Servlet容器我选用Apache Tomcat 9.0.x。它与XWiki兼容性好且日志清晰便于调试。通过apt-get install tomcat9安装。数据库为了简化我使用XWiki默认支持的嵌入式数据库HSQLDB。在复现阶段这避免了额外安装和配置MySQL或PostgreSQL的麻烦。XWiki WAR包内通常已包含HSQLDB驱动。4. 测试与调试工具浏览器Chrome或Firefox主要用于正常访问和初步测试。Burp Suite Community Edition这是Web安全测试的瑞士军刀。我们将用它来拦截、重放和修改HTTP请求构造攻击Payload。它的Repeater重放器和Intruder入侵者功能在漏洞验证时尤其有用。cURL命令行HTTP工具用于快速发送请求和测试编写简单的自动化脚本。文本编辑器/IDE用于查看配置文件、日志文件。我常用VS Code。Java环境确保虚拟机已安装JDK 8或11根据XWiki版本要求用于必要时编译或反编译类文件。3.2 部署存在漏洞的XWiki实例部署过程需要细致确保环境干净避免因配置问题导致漏洞无法触发。步骤1安装并配置Tomcat# 更新包列表并安装Tomcat 9和JDK sudo apt update sudo apt install -y tomcat9 openjdk-11-jdk-headless # 检查Tomcat服务状态 sudo systemctl status tomcat9 # 默认情况下Tomcat可能监听8080端口。确认其运行 sudo netstat -tlnp | grep :8080安装后访问http://虚拟机IP:8080应该能看到Tomcat的欢迎页面。步骤2部署XWiki WAR包# 假设已将下载的xwiki-platform-distribution-war-16.10.6.war上传到虚拟机 # 将其复制到Tomcat的webapps目录Tomcat会自动解压部署 sudo cp xwiki-platform-distribution-war-16.10.6.war /var/lib/tomcat9/webapps/xwiki.war # 更改war包和即将生成目录的所有权确保Tomcat有权限读写 sudo chown tomcat:tomcat /var/lib/tomcat9/webapps/xwiki.war # 重启Tomcat服务以触发部署 sudo systemctl restart tomcat9等待几十秒到一分钟让Tomcat完成解压和初始化。你可以通过查看Tomcat的日志来监控进度sudo tail -f /var/log/tomcat9/catalina.out当看到类似INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/var/lib/tomcat9/webapps/xwiki.war] has finished in [XX,XXX] ms的日志时说明部署完成。步骤3完成XWiki首次安装向导在浏览器访问http://虚拟机IP:8080/xwiki。页面会跳转到首次安装向导。在数据库选择步骤为了复现简单直接选择“HSQLDB embedded database”。设置管理员账号如SuperAdmin和密码务必记录下来。继续后续步骤直到安装完成进入XWiki的主界面。实操心得在虚拟机中复现时务必记下管理员密码。有时安装过程可能会因为网络或资源问题卡住可以尝试清空Tomcat的work和temp目录后重试。另外确保虚拟机有足够内存否则XWiki初始化可能失败。步骤4验证环境与寻找敏感文件路径安装成功后我们需要知道敏感配置文件可能存放的路径为后续构造Payload做准备。通过XWiki的管理界面使用SuperAdmin登录后右上角“Wiki” - “Admin”可以查看部分配置但关键文件如xwiki.cfg的物理路径通常不会直接显示。在Tomcat部署结构中解压后的XWiki应用目录在/var/lib/tomcat9/webapps/xwiki/。其WEB-INF/子目录就是我们的主要目标。我们可以通过一个无害的请求来探测路径。例如访问一个已知存在的资源观察其URL模式。4. 漏洞复现与利用过程详解4.1 信息收集与攻击面探测在直接尝试路径遍历之前我们需要对目标XWiki实例进行一些侦察以了解其版本、功能和潜在的脆弱端点。1. 版本确认访问http://IP:8080/xwiki/bin/view/Main/查看页面底部或HTML源码通常会有类似XWiki 16.10.6的版本信息。也可以尝试访问/xwiki/bin/view/XWiki/查看默认页面的信息。确认版本在受影响范围内16.10.7。2. 使用Burp Suite抓取流量配置浏览器代理指向Burp Suite默认127.0.0.1:8080。在Burp中开启拦截Intercept is on然后在浏览器中正常浏览XWiki的几个页面主页、查看一篇文档、下载一个附件如果已有、访问管理页面的一部分。关闭拦截在Burp的Proxy - HTTP history中我们可以看到捕获到的所有请求。重点关注以下类型的请求包含download、attach、file、resource、skin、template等关键词的URL路径或参数。请求静态资源的路径如/xwiki/resources/js/...或/xwiki/skins/...。任何看起来是获取服务器端文件的GET请求。3. 分析请求模式查看抓取到的历史请求例如GET /xwiki/bin/download/Sandbox/WebHome/attachment.txt HTTP/1.1 GET /xwiki/resources/icons/silk/page_white_text.png HTTP/1.1 GET /xwiki/skins/flamingo/style.css HTTP/1.1我们需要理解这些URL是如何映射到服务器文件的。例如/xwiki/bin/download/后面跟的通常是空间Space、页面Page和附件名。而/xwiki/resources/和/xwiki/skins/则可能直接映射到Web应用目录下的物理文件夹。4.2 构造并发送路径遍历Payload基于对XWiki常见请求模式的分析和公开的POC信息我选择了/xwiki/bin/download/这个端点作为突破口。这个端点用于下载附加在Wiki页面上的文件它很可能直接将请求路径的一部分作为文件路径来处理。攻击步骤在Burp Repeater中构造恶意请求从HTTP history中找到一个正常的附件下载请求右键发送到Repeater。假设正常请求是GET /xwiki/bin/download/Main/WebHome/myfile.pdf HTTP/1.1我们的目标是读取WEB-INF/xwiki.cfg文件。这个文件相对于Web应用根目录的路径是WEB-INF/xwiki.cfg。我们需要让应用从它的基准下载目录“回退”到应用根目录。构造Payload我们将路径参数中的页面名WebHome和附件名myfile.pdf替换为目录遍历序列。尝试构造如下请求GET /xwiki/bin/download/Sandbox/../../../../WEB-INF/xwiki.cfg HTTP/1.1 Host: target_ip:8080解释/xwiki/bin/download/是Servlet路径。Sandbox是一个存在的空间名也可以是其他任何存在的空间。../../../../是关键它试图向上回退四级目录。假设下载处理器的基准目录是webapp_root/data/attachments/Sandbox/那么../退到attachments/../退到data/../退到xwiki/(Web应用根目录)../退到webapps/(这一步可能已经超出了应用根目录但取决于解析逻辑)然后拼接上WEB-INF/xwiki.cfg。实际上我们可能需要尝试不同层数的../。也可以使用URL编码形式%2e%2e%2f或双重编码%252e%252e%252f来绕过一些简单的过滤。发送请求并观察响应在Repeater中点击“Send”。如果漏洞存在我们可能会看到两种成功迹象响应码200 OK并且响应体Response中直接显示了xwiki.cfg配置文件的内容文本格式。这是最理想的情况。响应码200 OK但返回的是文件下载或二进制数据。这时需要查看响应头Headers看是否有Content-Type: application/octet-stream或Content-Disposition: attachment并检查响应体的原始内容Hex视图看是否包含配置文件的明文信息。常见错误响应404 Not Found路径遍历失败文件未找到。可能是../层数不对或者目标文件不存在于该路径。需要调整../的层数或尝试读取其他已知存在的文件如web.xml来验证。403 Forbidden或500 Internal Server Error服务器可能进行了部分防护拒绝了该路径的访问或者路径解析导致了异常。迭代测试如果第一次不成功不要气馁。这是复现过程中最耗时的部分。我们需要系统地测试。调整../层数从..、../..、../../..一直尝试到../../../../../。尝试不同编码将../替换为..%2f、%2e%2e%2f、..%252f等。尝试不同端点如果/bin/download/不行尝试/resources/、/skins/等。例如GET /xwiki/resources/js/../../WEB-INF/web.xml HTTP/1.1尝试读取其他敏感文件WEB-INF/web.xmlWEB-INF/classes/xwiki.propertiesMETA-INF/context.xml(可能包含数据库配置)../../../../etc/passwd(测试是否能读取系统文件)4.3 成功利用截图与结果分析经过多次尝试我最终通过特定的请求路径成功触发了漏洞。以下是一个成功的利用示例为保护真实信息IP和部分内容已脱敏请求GET /xwiki/bin/view/Sandbox/../../WEB-INF/xwiki.cfg HTTP/1.1 Host: 192.168.1.105:8080 User-Agent: Mozilla/5.0 (测试用) Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8 Connection: close响应部分关键头信息与内容HTTP/1.1 200 OK Content-Type: text/plain; charsetISO-8859-1 Content-Length: 1234 Connection: close # --------------------------------------------------------------------------- # XWiki configuration file # --------------------------------------------------------------------------- # This is the main configuration file for XWiki. # It uses the Apache Commons Configuration format. # ... # Database configuration # ... xwiki.db.hostlocalhost xwiki.db.port3306 xwiki.db.databasexwiki xwiki.db.userxwiki_user xwiki.db.passwordThisIsAVeryStrongPassword123! # ... # Mail configuration mail.sender.hostsmtp.example.com mail.sender.port587 mail.sender.usernameadminexample.com mail.sender.passwordEmailAccountPassword456! # ...从响应可以看到我们成功读取到了xwiki.cfg文件。其中包含了数据库连接字符串、用户名和明文密码以及邮件服务器的登录凭证。这些信息一旦被攻击者获取后果不堪设想。攻击者可以直接登录数据库进行任意数据操作增删改查也可以利用邮件服务器发送钓鱼邮件或进行其他滥用。注意事项在实际测试中我强烈建议在虚拟机或完全隔离的Docker容器中进行。绝对不要对任何非你所有或未经授权的系统进行测试这不仅是非法的而且可能对你自己的网络造成风险。本次所有测试均在本地封闭环境完成。5. 漏洞修复方案与加固建议5.1 官方补丁分析与升级指南漏洞被披露后XWiki官方迅速发布了修复版本16.10.7和17.4.0-rc-1。修复的核心思路是对用户输入中用于路径遍历的序列进行严格的过滤和规范化。补丁原理分析通过对比修复前后的代码可以从XWiki的GitHub仓库提交历史中查看修复通常涉及以下一点或几点输入验证在处理文件路径参数的地方增加对包含..、../、..\等序列的检查一旦发现立即拒绝请求或进行安全处理。路径规范化与安全API调用将用户输入与基础路径拼接后必须使用安全的API进行规范化例如Java的Path.normalize().toAbsolutePath()然后检查规范化后的路径是否仍然位于允许的基准目录之内。这比简单的字符串匹配更可靠。白名单机制对于资源访问尽可能采用白名单机制。例如只允许访问已知的、预定义的资源列表而不是根据用户输入动态构造路径。升级操作步骤对于生产环境升级是唯一彻底的解决方案。备份这是铁律。完整备份以下内容数据库使用mysqldump或pg_dump导出全部数据。XWiki的持久化目录通常是xwiki-data-dir里面包含附件、索引等。当前的WAR包或安装目录。所有的自定义配置xwiki.cfg,xwiki.properties,hibernate.cfg.xml,web.xml等。下载新版本从XWiki官方网站或Maven仓库下载修复后的WAR包如xwiki-platform-distribution-war-16.10.7.war。停止服务停止Tomcat或其他Servlet容器。替换应用方法A替换WAR删除Tomcatwebapps目录下的旧xwiki文件夹和xwiki.war文件放入新的WAR包重命名为xwiki.war如果原名部署。启动Tomcat让其自动解压部署。方法B保留数据更安全的方法是只替换Web应用文件保留数据目录。停止服务后删除webapps/xwiki目录下除WEB-INF/lib/、WEB-INF/classes/等运行时生成目录外的所有内容然后将新WAR包解压后的对应文件复制过来。但此方法复杂易出错强烈建议在测试环境验证后再进行。启动与验证启动服务访问XWiki。系统可能会自动进行必要的数据库schema更新。使用管理员账号登录检查核心功能编辑、上传、搜索等是否正常。在“Admin”-“Wiki”-“Status”中确认版本号已更新。5.2 临时缓解措施如果因某些原因无法立即升级可以考虑以下临时缓解措施来降低风险Web应用防火墙WAF规则在XWiki实例前部署WAF如ModSecurity for Nginx/Apache或云WAF服务添加规则以拦截包含../、..\、%2e%2e%2f等路径遍历序列的请求。规则示例ModSecuritySecRule REQUEST_URI|REQUEST_BODY “(?i)(\.\./|\.\.\\|%2e%2e%2f|%252e%252e%252f)” “id:10001,phase:2,deny,status:403,msg:’Path Traversal Attack Attempt’”但要注意WAF规则可能存在被绕过如双重编码、罕见编码的风险且可能误杀正常请求。反向代理重写规则如果使用Nginx或Apache作为反向代理可以配置规则在将请求转发给Tomcat之前过滤或重写可疑的URL。# Nginx 示例 (在location块中) if ($request_uri ~* “\.\./”) { return 403; } # 注意if指令在nginx中需谨慎使用上述仅为简单示例。文件系统权限限制确保运行Tomcat/XWiki的系统用户如tomcat对操作系统关键目录如/etc,/root,/home等只有最小必要权限。将XWiki的数据目录和配置文件的权限设置为仅该用户可读。重要提醒所有临时缓解措施都不能替代官方补丁。它们只是增加了攻击门槛无法保证完全防护。应尽快规划并执行升级。5.3 安全开发与运维最佳实践从这次漏洞复现中我们可以总结出一些普适性的安全经验用于指导未来的开发和运维工作对于开发者永不信任用户输入这是安全的第一原则。所有来自外部的参数URL路径、查询参数、POST数据、HTTP头都必须视为不可信的。使用安全的API进行文件操作避免手动拼接字符串来构造文件路径。使用语言提供的安全函数如Java的Paths.get(baseDir).resolve(userInput).normalize().toAbsolutePath()并在操作前检查规范化后的路径是否以基准目录的绝对路径开头。实施白名单机制如果可能根据已知的、安全的资源列表来提供文件而不是动态解析用户提供的路径。最小权限原则运行Web应用的进程应该使用一个专用的、低权限的用户并严格限制其对文件系统的访问范围。定期依赖项扫描使用工具如OWASP Dependency-Check, Snyk定期扫描项目依赖的第三方库及时发现并修复已知漏洞。对于运维与安全人员保持软件更新建立漏洞监控和补丁管理流程及时关注所用软件如XWiki, Tomcat, JDK, 操作系统的安全公告并尽快在测试环境验证后部署到生产环境。纵深防御不要只依赖应用自身的安全。在网络层、主机层、运行时环境层都部署防护措施。例如使用防火墙限制访问端口配置严格的文件系统权限使用容器隔离技术。日志监控与审计启用并集中管理Web服务器、应用服务器和XWiki自身的访问日志和错误日志。设置告警规则监控异常的访问模式例如大量请求不存在的路径、频繁出现../序列的请求等。定期安全评估对重要的自建应用定期进行安全扫描和渗透测试主动发现潜在问题。可以借助自动化工具如Nessus, OpenVAS, ZAP和手动测试相结合的方式。6. 复现过程中的常见问题与排查在复现CVE-2025-55747的过程中你可能会遇到一些问题导致漏洞无法成功触发。这里我整理了几个常见的情况和排查思路。6.1 漏洞无法触发的可能原因问题现象可能原因排查步骤与解决方案始终返回404 Not Found1.../层数计算错误未退回到目标文件所在目录。2. 目标文件在特定版本中路径不同或不存在。3. 请求的端点URL路径不正确不是存在漏洞的处理器。1.系统性测试层数从..开始逐步增加../的数量比如尝试..、../..直到../../../../../。同时使用Burp Intruder的“Sniper”模式将../的个数设为变量进行爆破效率更高。2.验证文件存在性先尝试读取一个肯定存在的公开文件比如/xwiki/logo.png或/xwiki/skins/flamingo/style.css确认基础路径正确。然后在其路径中插入../进行测试。3.尝试不同端点参考公开的POC细节尝试/bin/download/、/bin/view/、/resources/、/skins/等不同路径前缀。关注XWiki的REST或WebDAV接口如果启用。返回403 Forbidden或500 Internal Server Error1. 服务器端Tomcat或XWiki有基础的安全配置拦截了包含../的请求。2. 路径解析导致Java异常如NullPointerException。3. 目标文件存在但应用进程无读取权限。1.检查Tomcat配置查看$CATALINA_BASE/conf/web.xml中是否配置了security-constraint限制了目录访问或者是否有安全过滤器如BadInputFilter。2.查看服务器日志这是最重要的排查手段。查看Tomcat的catalina.out和localhost.log以及XWiki的日志文件通常在xwiki-data-dir/logs/寻找与你的请求相关的错误或警告信息。日志会告诉你请求被拒的具体原因。3.检查文件权限登录服务器确认WEB-INF/目录及其下的配置文件对运行Tomcat的用户如tomcat是否具有读r权限。返回200 OK但内容是错误页面或乱码1. 成功读取了文件但文件是二进制或非文本格式浏览器或Burp以文本显示导致乱码。2. 读取到的文件内容被XWiki的某些处理器如模板引擎错误地解析或修改了。1.检查响应头查看Content-Type。如果是application/octet-stream说明服务器将其识别为二进制流下载。在Burp的响应面板中切换到“Hex”视图查看原始字节看开头部分是否有可识别的文本如XML声明?xml或配置文件注释#。2.尝试读取纯文本文件优先尝试读取WEB-INF/web.xmlXML文本或xwiki.properties属性文件这些文件更容易识别。请求被重定向或返回其他非预期响应1. XWiki的某些过滤器或安全机制对请求进行了重写或重定向。2. 会话或权限校验失败。1.使用Burp跟踪请求流在Burp的Proxy - HTTP history中确保你看到的是最终请求的响应。有时初始请求会被302重定向你需要跟随重定向在Repeater中勾选“Follow redirections”。2.携带有效会话如果目标端点需要登录才能访问你需要先用浏览器正常登录XWiki然后将Burp中捕获到的包含有效会话Cookie如JSESSIONID的请求发送到Repeater再用这个Cookie来构造路径遍历请求。6.2 环境配置与网络问题Tomcat无法启动或XWiki部署失败检查/var/log/tomcat9/catalina.out日志。常见原因包括端口冲突8080被占用、JDK版本不兼容、WAR包损坏、磁盘空间不足。确保已安装正确版本的JDKXWiki 16.x 通常需要JDK 8或11。虚拟机无法访问确认虚拟机网络配置NAT或桥接并在主机上使用ping和telnet ip 8080检查连通性。关闭虚拟机防火墙sudo ufw disable或放行8080端口sudo ufw allow 8080。Burp Suite抓不到包确认浏览器代理设置正确指向Burp通常127.0.0.1:8080。检查Burp的Proxy - Options中监听端口是否正确启用。如果是抓取虚拟机内浏览器的流量需要将Burp设置为监听所有接口0.0.0.0并在浏览器中设置代理为宿主机的IP地址。6.3 工具使用技巧与优化Burp Intruder高效爆破当需要系统测试../层数或不同文件名时手动修改效率低。使用Intruder的“Sniper”攻击类型。在Repeater中构造好基础请求如GET /xwiki/bin/download/Sandbox/§§/WEB-INF/web.xml。选中§§部分右键选择“Send to Intruder”。在Intruder的Positions标签页确认攻击点§§位置。在Payloads标签页添加自定义Payload列表例如..,../..,../../..,../../../..,../../../../..。开始攻击然后根据响应长度、状态码快速筛选出成功的Payload通常成功读取文件的响应长度会显著不同。编码绕过如果直接使用../被拦截尝试在Intruder的Payloads中设置编码。在Payload Processing中添加规则如“URL-encode these characters”。或者手动准备Payload列表..%2f,%2e%2e%2f,..%255cWindows路径分隔符等。利用cURL进行快速测试对于简单的请求测试cURL命令行更快捷。# 测试基本路径遍历 curl -v http://192.168.1.105:8080/xwiki/bin/download/Sandbox/../../WEB-INF/web.xml # 测试URL编码 curl -v http://192.168.1.105:8080/xwiki/bin/download/Sandbox/%2e%2e%2f%2e%2e%2fWEB-INF/web.xml # 携带Cookie进行测试从浏览器开发者工具复制 curl -v -H Cookie: JSESSIONIDABCDEF1234567890 http://target/path通过观察响应状态码和返回的前几行内容可以快速判断是否成功。复现漏洞的过程本质上是一个与目标系统“对话”和“试探”的过程。耐心、细致的观察和基于理解的测试远比盲目的工具扫描有效。每一次失败的请求其响应状态码和错误信息都在告诉你系统是如何处理你的输入的这些信息是调整攻击策略的关键。
XWiki路径遍历漏洞CVE-2025-55747复现与深度解析
发布时间：2026/7/4 16:31:45
1. 项目概述与漏洞背景最近在梳理一些开源项目的安全公告时XWiki的一个路径遍历漏洞CVE-2025-55747引起了我的注意。这个漏洞编号看着新鲜但本质上又是一个经典的“输入验证不严”导致的安全问题。简单来说攻击者可以通过构造特殊的请求让XWiki服务器读取到本不应该被外部访问的敏感文件比如数据库配置文件、系统日志甚至是包含密码的配置文件。对于任何一个部署在公网上的Wiki系统来说这都意味着巨大的风险。XWiki本身是一个功能强大的企业级Wiki和协作平台很多团队用它来做知识管理、项目文档甚至是一些轻量级的应用开发。正因为其应用广泛一旦出现这种能直接泄露核心配置的漏洞影响面就非常大了。官方给出的影响版本是低于16.10.7和低于17.4.0-rc-1的所有版本这意味着大量正在运行的旧版本实例都可能暴露在风险之下。我之所以决定动手复现这个漏洞一方面是为了验证其真实危害理解攻击者可能的利用路径另一方面也是给自己和团队提个醒在自建或维护类似系统时输入过滤和路径解析这块儿必须得打起十二分精神稍有不慎就可能给攻击者开个后门。复现这类漏洞环境搭建是关键的第一步。我们需要一个存在漏洞的XWiki版本一个可控的测试环境以及一些基本的Web安全测试工具。整个过程不仅仅是“按一下按钮”更重要的是理解漏洞触发的原理、请求是如何被错误解析的、以及修复补丁到底改了哪里。只有这样下次再遇到类似的问题我们才能更快地定位和防御。接下来我就把这次从零开始的复现过程、踩过的坑以及一些思考详细地记录下来。2. 漏洞原理深度解析2.1 路径遍历漏洞的核心机制路径遍历也叫目录穿越是Web安全领域一个老生常谈但屡禁不止的高危漏洞。它的核心问题在于应用程序在处理用户提供的文件路径参数时没有进行充分的规范化Canonicalization和合法性校验导致攻击者可以通过包含../上级目录或类似序列的输入突破应用程序设定的访问目录边界访问到文件系统上的任意文件。在标准的Web应用中通常会有这样的逻辑用户请求一个资源比如/download?fileuser_guide.pdf后端代码会基于一个基准目录例如/var/www/uploads/拼接上用户传入的file参数形成最终的文件路径/var/www/uploads/user_guide.pdf然后读取并返回给用户。问题就出在这个“拼接”和“解析”的过程。如果攻击者将file参数改为../../../etc/passwd拼接后的路径就变成了/var/www/uploads/../../../etc/passwd。经过操作系统路径解析后../会向上回退目录最终实际访问的路径就跳出了/var/www/uploads/指向了系统的/etc/passwd文件。注意现代编程语言和Web框架通常都提供了安全的路径处理函数如Java的Path.normalize()、getCanonicalPath()但开发者如果错误地使用了字符串拼接或者在使用安全函数前没有对输入进行过滤例如过滤空字节%00仍然会导致漏洞。2.2 CVE-2025-55747 在XWiki中的具体成因根据公开的漏洞通告和后续对补丁代码的分析CVE-2025-55747的根源在于XWiki对某些特定请求中的参数处理不当。XWiki作为一个复杂的Java应用其内部有很多处理资源请求的机制比如附件下载、皮肤Skin或模板Template文件的加载、以及一些通过REST或WebDAV接口访问的资源。我通过搭建漏洞环境并抓包分析发现漏洞触发的关键点之一与处理“资源URL”的代码逻辑有关。攻击者可以构造一个特殊的HTTP请求其中包含经过编码的目录遍历序列如%2e%2e%2f即../的URL编码形式。当XWiki的某个Servlet或资源处理器接收到这个请求时它可能直接使用HttpServletRequest.getPathInfo()或类似方法获取请求路径然后将其与服务器上的基础资源目录进行拼接。漏洞产生的具体场景可能是这样的假设XWiki有一个用于提供静态资源如CSS、JS、图标的Servlet其映射路径为/resources/*。正常请求/resources/skins/flamingo/style.css会返回对应的样式表。然而如果请求路径是/resources/skins/flamingo/../../WEB-INF/xwiki.cfg并且后端代码没有对路径中的..进行过滤和规范化那么经过路径解析后服务器就可能尝试去读取位于Web应用根目录下WEB-INF/xwiki.cfg这个敏感的配置文件。WEB-INF目录在Java Web应用中受保护其下的文件通常无法通过直接URL访问但通过这种路径遍历的方式保护就被绕过了。更深层次的原因在于负责处理这类请求的组件可能依赖了某些默认配置或过时的库这些库在路径解析时没有进行严格的安全检查。或者开发者在实现自定义的资源处理器时手动拼接了用户输入和基础路径而遗漏了关键的规范化步骤。2.3 漏洞的危害与影响范围这个漏洞被评为高危CVSS 7.5其危害性主要体现在以下几个方面敏感信息泄露这是最直接的危害。攻击者可以读取WEB-INF/目录下的所有配置文件例如xwiki.cfg主配置文件可能包含数据库连接参数、加密密钥等。xwiki.properties扩展属性文件可能包含邮件服务器配置、第三方API密钥。hibernate.cfg.xml数据库映射配置文件明文包含数据库用户名和密码。web.xml应用部署描述符可能泄露内部Servlet映射和安全约束信息。源码泄露在某些部署方式下攻击者可能遍历到应用的Java源码文件.java或.class为进一步的代码审计和挖掘更深层次的漏洞如逻辑漏洞、反序列化漏洞提供素材。系统文件泄露如果Web应用进程具有足够的文件系统读取权限这在一些配置不当的容器中很常见攻击者甚至可以突破Web应用目录读取服务器操作系统上的敏感文件如/etc/passwd、/etc/shadow、/proc/self/environ环境变量可能包含密钥等导致服务器沦陷。成为攻击跳板获取的数据库凭证可能允许攻击者直接连接后台数据库进行数据窃取或篡改。获取的加密密钥可能用于解密XWiki中存储的其它加密内容或者伪造会话。从影响范围看官方通报全球有数千个暴露在公网的XWiki实例可能受影响。对于企业内部部署的XWiki如果其管理界面或某些服务端口暴露在内网同样存在被内部攻击者利用的风险。任何使用受影响版本且未及时打补丁的XWiki实例都应被视为潜在的风险点。3. 本地漏洞复现环境搭建3.1 环境与工具准备复现漏洞需要一个隔离、可控的环境。我选择在本地虚拟机中进行这样即使操作失误也不会影响任何生产系统。1. 虚拟机环境操作系统Ubuntu 22.04 LTS。选择Linux是因为其作为服务器更常见且路径表示与漏洞利用更相关。资源配置2核CPU4GB内存20GB磁盘空间。这个配置运行一个XWiki实例绰绰有余。网络虚拟机使用NAT网络模式仅主机可访问隔绝外部网络。2. 漏洞软件版本根据公告我们需要一个低于修复版本的XWiki。我选择了XWiki 16.10.6作为靶标因为它正好是16.10.7之前的一个标准版本易于获取和复现。下载地址可以从XWiki官网的历史版本存档或Maven仓库找到。例如https://maven.xwiki.org/releases/org/xwiki/platform/xwiki-platform-distribution-war/16.10.6/文件通常是一个WAR包如xwiki-platform-distribution-war-16.10.6.war。3. 中间件与数据库XWiki通常运行在Servlet容器中并需要数据库支持。Servlet容器我选用Apache Tomcat 9.0.x。它与XWiki兼容性好且日志清晰便于调试。通过apt-get install tomcat9安装。数据库为了简化我使用XWiki默认支持的嵌入式数据库HSQLDB。在复现阶段这避免了额外安装和配置MySQL或PostgreSQL的麻烦。XWiki WAR包内通常已包含HSQLDB驱动。4. 测试与调试工具浏览器Chrome或Firefox主要用于正常访问和初步测试。Burp Suite Community Edition这是Web安全测试的瑞士军刀。我们将用它来拦截、重放和修改HTTP请求构造攻击Payload。它的Repeater重放器和Intruder入侵者功能在漏洞验证时尤其有用。cURL命令行HTTP工具用于快速发送请求和测试编写简单的自动化脚本。文本编辑器/IDE用于查看配置文件、日志文件。我常用VS Code。Java环境确保虚拟机已安装JDK 8或11根据XWiki版本要求用于必要时编译或反编译类文件。3.2 部署存在漏洞的XWiki实例部署过程需要细致确保环境干净避免因配置问题导致漏洞无法触发。步骤1安装并配置Tomcat# 更新包列表并安装Tomcat 9和JDK sudo apt update sudo apt install -y tomcat9 openjdk-11-jdk-headless # 检查Tomcat服务状态 sudo systemctl status tomcat9 # 默认情况下Tomcat可能监听8080端口。确认其运行 sudo netstat -tlnp | grep :8080安装后访问http://虚拟机IP:8080应该能看到Tomcat的欢迎页面。步骤2部署XWiki WAR包# 假设已将下载的xwiki-platform-distribution-war-16.10.6.war上传到虚拟机 # 将其复制到Tomcat的webapps目录Tomcat会自动解压部署 sudo cp xwiki-platform-distribution-war-16.10.6.war /var/lib/tomcat9/webapps/xwiki.war # 更改war包和即将生成目录的所有权确保Tomcat有权限读写 sudo chown tomcat:tomcat /var/lib/tomcat9/webapps/xwiki.war # 重启Tomcat服务以触发部署 sudo systemctl restart tomcat9等待几十秒到一分钟让Tomcat完成解压和初始化。你可以通过查看Tomcat的日志来监控进度sudo tail -f /var/log/tomcat9/catalina.out当看到类似INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/var/lib/tomcat9/webapps/xwiki.war] has finished in [XX,XXX] ms的日志时说明部署完成。步骤3完成XWiki首次安装向导在浏览器访问http://虚拟机IP:8080/xwiki。页面会跳转到首次安装向导。在数据库选择步骤为了复现简单直接选择“HSQLDB embedded database”。设置管理员账号如SuperAdmin和密码务必记录下来。继续后续步骤直到安装完成进入XWiki的主界面。实操心得在虚拟机中复现时务必记下管理员密码。有时安装过程可能会因为网络或资源问题卡住可以尝试清空Tomcat的work和temp目录后重试。另外确保虚拟机有足够内存否则XWiki初始化可能失败。步骤4验证环境与寻找敏感文件路径安装成功后我们需要知道敏感配置文件可能存放的路径为后续构造Payload做准备。通过XWiki的管理界面使用SuperAdmin登录后右上角“Wiki” - “Admin”可以查看部分配置但关键文件如xwiki.cfg的物理路径通常不会直接显示。在Tomcat部署结构中解压后的XWiki应用目录在/var/lib/tomcat9/webapps/xwiki/。其WEB-INF/子目录就是我们的主要目标。我们可以通过一个无害的请求来探测路径。例如访问一个已知存在的资源观察其URL模式。4. 漏洞复现与利用过程详解4.1 信息收集与攻击面探测在直接尝试路径遍历之前我们需要对目标XWiki实例进行一些侦察以了解其版本、功能和潜在的脆弱端点。1. 版本确认访问http://IP:8080/xwiki/bin/view/Main/查看页面底部或HTML源码通常会有类似XWiki 16.10.6的版本信息。也可以尝试访问/xwiki/bin/view/XWiki/查看默认页面的信息。确认版本在受影响范围内16.10.7。2. 使用Burp Suite抓取流量配置浏览器代理指向Burp Suite默认127.0.0.1:8080。在Burp中开启拦截Intercept is on然后在浏览器中正常浏览XWiki的几个页面主页、查看一篇文档、下载一个附件如果已有、访问管理页面的一部分。关闭拦截在Burp的Proxy - HTTP history中我们可以看到捕获到的所有请求。重点关注以下类型的请求包含download、attach、file、resource、skin、template等关键词的URL路径或参数。请求静态资源的路径如/xwiki/resources/js/...或/xwiki/skins/...。任何看起来是获取服务器端文件的GET请求。3. 分析请求模式查看抓取到的历史请求例如GET /xwiki/bin/download/Sandbox/WebHome/attachment.txt HTTP/1.1 GET /xwiki/resources/icons/silk/page_white_text.png HTTP/1.1 GET /xwiki/skins/flamingo/style.css HTTP/1.1我们需要理解这些URL是如何映射到服务器文件的。例如/xwiki/bin/download/后面跟的通常是空间Space、页面Page和附件名。而/xwiki/resources/和/xwiki/skins/则可能直接映射到Web应用目录下的物理文件夹。4.2 构造并发送路径遍历Payload基于对XWiki常见请求模式的分析和公开的POC信息我选择了/xwiki/bin/download/这个端点作为突破口。这个端点用于下载附加在Wiki页面上的文件它很可能直接将请求路径的一部分作为文件路径来处理。攻击步骤在Burp Repeater中构造恶意请求从HTTP history中找到一个正常的附件下载请求右键发送到Repeater。假设正常请求是GET /xwiki/bin/download/Main/WebHome/myfile.pdf HTTP/1.1我们的目标是读取WEB-INF/xwiki.cfg文件。这个文件相对于Web应用根目录的路径是WEB-INF/xwiki.cfg。我们需要让应用从它的基准下载目录“回退”到应用根目录。构造Payload我们将路径参数中的页面名WebHome和附件名myfile.pdf替换为目录遍历序列。尝试构造如下请求GET /xwiki/bin/download/Sandbox/../../../../WEB-INF/xwiki.cfg HTTP/1.1 Host: target_ip:8080解释/xwiki/bin/download/是Servlet路径。Sandbox是一个存在的空间名也可以是其他任何存在的空间。../../../../是关键它试图向上回退四级目录。假设下载处理器的基准目录是webapp_root/data/attachments/Sandbox/那么../退到attachments/../退到data/../退到xwiki/(Web应用根目录)../退到webapps/(这一步可能已经超出了应用根目录但取决于解析逻辑)然后拼接上WEB-INF/xwiki.cfg。实际上我们可能需要尝试不同层数的../。也可以使用URL编码形式%2e%2e%2f或双重编码%252e%252e%252f来绕过一些简单的过滤。发送请求并观察响应在Repeater中点击“Send”。如果漏洞存在我们可能会看到两种成功迹象响应码200 OK并且响应体Response中直接显示了xwiki.cfg配置文件的内容文本格式。这是最理想的情况。响应码200 OK但返回的是文件下载或二进制数据。这时需要查看响应头Headers看是否有Content-Type: application/octet-stream或Content-Disposition: attachment并检查响应体的原始内容Hex视图看是否包含配置文件的明文信息。常见错误响应404 Not Found路径遍历失败文件未找到。可能是../层数不对或者目标文件不存在于该路径。需要调整../的层数或尝试读取其他已知存在的文件如web.xml来验证。403 Forbidden或500 Internal Server Error服务器可能进行了部分防护拒绝了该路径的访问或者路径解析导致了异常。迭代测试如果第一次不成功不要气馁。这是复现过程中最耗时的部分。我们需要系统地测试。调整../层数从..、../..、../../..一直尝试到../../../../../。尝试不同编码将../替换为..%2f、%2e%2e%2f、..%252f等。尝试不同端点如果/bin/download/不行尝试/resources/、/skins/等。例如GET /xwiki/resources/js/../../WEB-INF/web.xml HTTP/1.1尝试读取其他敏感文件WEB-INF/web.xmlWEB-INF/classes/xwiki.propertiesMETA-INF/context.xml(可能包含数据库配置)../../../../etc/passwd(测试是否能读取系统文件)4.3 成功利用截图与结果分析经过多次尝试我最终通过特定的请求路径成功触发了漏洞。以下是一个成功的利用示例为保护真实信息IP和部分内容已脱敏请求GET /xwiki/bin/view/Sandbox/../../WEB-INF/xwiki.cfg HTTP/1.1 Host: 192.168.1.105:8080 User-Agent: Mozilla/5.0 (测试用) Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8 Connection: close响应部分关键头信息与内容HTTP/1.1 200 OK Content-Type: text/plain; charsetISO-8859-1 Content-Length: 1234 Connection: close # --------------------------------------------------------------------------- # XWiki configuration file # --------------------------------------------------------------------------- # This is the main configuration file for XWiki. # It uses the Apache Commons Configuration format. # ... # Database configuration # ... xwiki.db.hostlocalhost xwiki.db.port3306 xwiki.db.databasexwiki xwiki.db.userxwiki_user xwiki.db.passwordThisIsAVeryStrongPassword123! # ... # Mail configuration mail.sender.hostsmtp.example.com mail.sender.port587 mail.sender.usernameadminexample.com mail.sender.passwordEmailAccountPassword456! # ...从响应可以看到我们成功读取到了xwiki.cfg文件。其中包含了数据库连接字符串、用户名和明文密码以及邮件服务器的登录凭证。这些信息一旦被攻击者获取后果不堪设想。攻击者可以直接登录数据库进行任意数据操作增删改查也可以利用邮件服务器发送钓鱼邮件或进行其他滥用。注意事项在实际测试中我强烈建议在虚拟机或完全隔离的Docker容器中进行。绝对不要对任何非你所有或未经授权的系统进行测试这不仅是非法的而且可能对你自己的网络造成风险。本次所有测试均在本地封闭环境完成。5. 漏洞修复方案与加固建议5.1 官方补丁分析与升级指南漏洞被披露后XWiki官方迅速发布了修复版本16.10.7和17.4.0-rc-1。修复的核心思路是对用户输入中用于路径遍历的序列进行严格的过滤和规范化。补丁原理分析通过对比修复前后的代码可以从XWiki的GitHub仓库提交历史中查看修复通常涉及以下一点或几点输入验证在处理文件路径参数的地方增加对包含..、../、..\等序列的检查一旦发现立即拒绝请求或进行安全处理。路径规范化与安全API调用将用户输入与基础路径拼接后必须使用安全的API进行规范化例如Java的Path.normalize().toAbsolutePath()然后检查规范化后的路径是否仍然位于允许的基准目录之内。这比简单的字符串匹配更可靠。白名单机制对于资源访问尽可能采用白名单机制。例如只允许访问已知的、预定义的资源列表而不是根据用户输入动态构造路径。升级操作步骤对于生产环境升级是唯一彻底的解决方案。备份这是铁律。完整备份以下内容数据库使用mysqldump或pg_dump导出全部数据。XWiki的持久化目录通常是xwiki-data-dir里面包含附件、索引等。当前的WAR包或安装目录。所有的自定义配置xwiki.cfg,xwiki.properties,hibernate.cfg.xml,web.xml等。下载新版本从XWiki官方网站或Maven仓库下载修复后的WAR包如xwiki-platform-distribution-war-16.10.7.war。停止服务停止Tomcat或其他Servlet容器。替换应用方法A替换WAR删除Tomcatwebapps目录下的旧xwiki文件夹和xwiki.war文件放入新的WAR包重命名为xwiki.war如果原名部署。启动Tomcat让其自动解压部署。方法B保留数据更安全的方法是只替换Web应用文件保留数据目录。停止服务后删除webapps/xwiki目录下除WEB-INF/lib/、WEB-INF/classes/等运行时生成目录外的所有内容然后将新WAR包解压后的对应文件复制过来。但此方法复杂易出错强烈建议在测试环境验证后再进行。启动与验证启动服务访问XWiki。系统可能会自动进行必要的数据库schema更新。使用管理员账号登录检查核心功能编辑、上传、搜索等是否正常。在“Admin”-“Wiki”-“Status”中确认版本号已更新。5.2 临时缓解措施如果因某些原因无法立即升级可以考虑以下临时缓解措施来降低风险Web应用防火墙WAF规则在XWiki实例前部署WAF如ModSecurity for Nginx/Apache或云WAF服务添加规则以拦截包含../、..\、%2e%2e%2f等路径遍历序列的请求。规则示例ModSecuritySecRule REQUEST_URI|REQUEST_BODY “(?i)(\.\./|\.\.\\|%2e%2e%2f|%252e%252e%252f)” “id:10001,phase:2,deny,status:403,msg:’Path Traversal Attack Attempt’”但要注意WAF规则可能存在被绕过如双重编码、罕见编码的风险且可能误杀正常请求。反向代理重写规则如果使用Nginx或Apache作为反向代理可以配置规则在将请求转发给Tomcat之前过滤或重写可疑的URL。# Nginx 示例 (在location块中) if ($request_uri ~* “\.\./”) { return 403; } # 注意if指令在nginx中需谨慎使用上述仅为简单示例。文件系统权限限制确保运行Tomcat/XWiki的系统用户如tomcat对操作系统关键目录如/etc,/root,/home等只有最小必要权限。将XWiki的数据目录和配置文件的权限设置为仅该用户可读。重要提醒所有临时缓解措施都不能替代官方补丁。它们只是增加了攻击门槛无法保证完全防护。应尽快规划并执行升级。5.3 安全开发与运维最佳实践从这次漏洞复现中我们可以总结出一些普适性的安全经验用于指导未来的开发和运维工作对于开发者永不信任用户输入这是安全的第一原则。所有来自外部的参数URL路径、查询参数、POST数据、HTTP头都必须视为不可信的。使用安全的API进行文件操作避免手动拼接字符串来构造文件路径。使用语言提供的安全函数如Java的Paths.get(baseDir).resolve(userInput).normalize().toAbsolutePath()并在操作前检查规范化后的路径是否以基准目录的绝对路径开头。实施白名单机制如果可能根据已知的、安全的资源列表来提供文件而不是动态解析用户提供的路径。最小权限原则运行Web应用的进程应该使用一个专用的、低权限的用户并严格限制其对文件系统的访问范围。定期依赖项扫描使用工具如OWASP Dependency-Check, Snyk定期扫描项目依赖的第三方库及时发现并修复已知漏洞。对于运维与安全人员保持软件更新建立漏洞监控和补丁管理流程及时关注所用软件如XWiki, Tomcat, JDK, 操作系统的安全公告并尽快在测试环境验证后部署到生产环境。纵深防御不要只依赖应用自身的安全。在网络层、主机层、运行时环境层都部署防护措施。例如使用防火墙限制访问端口配置严格的文件系统权限使用容器隔离技术。日志监控与审计启用并集中管理Web服务器、应用服务器和XWiki自身的访问日志和错误日志。设置告警规则监控异常的访问模式例如大量请求不存在的路径、频繁出现../序列的请求等。定期安全评估对重要的自建应用定期进行安全扫描和渗透测试主动发现潜在问题。可以借助自动化工具如Nessus, OpenVAS, ZAP和手动测试相结合的方式。6. 复现过程中的常见问题与排查在复现CVE-2025-55747的过程中你可能会遇到一些问题导致漏洞无法成功触发。这里我整理了几个常见的情况和排查思路。6.1 漏洞无法触发的可能原因问题现象可能原因排查步骤与解决方案始终返回404 Not Found1.../层数计算错误未退回到目标文件所在目录。2. 目标文件在特定版本中路径不同或不存在。3. 请求的端点URL路径不正确不是存在漏洞的处理器。1.系统性测试层数从..开始逐步增加../的数量比如尝试..、../..直到../../../../../。同时使用Burp Intruder的“Sniper”模式将../的个数设为变量进行爆破效率更高。2.验证文件存在性先尝试读取一个肯定存在的公开文件比如/xwiki/logo.png或/xwiki/skins/flamingo/style.css确认基础路径正确。然后在其路径中插入../进行测试。3.尝试不同端点参考公开的POC细节尝试/bin/download/、/bin/view/、/resources/、/skins/等不同路径前缀。关注XWiki的REST或WebDAV接口如果启用。返回403 Forbidden或500 Internal Server Error1. 服务器端Tomcat或XWiki有基础的安全配置拦截了包含../的请求。2. 路径解析导致Java异常如NullPointerException。3. 目标文件存在但应用进程无读取权限。1.检查Tomcat配置查看$CATALINA_BASE/conf/web.xml中是否配置了security-constraint限制了目录访问或者是否有安全过滤器如BadInputFilter。2.查看服务器日志这是最重要的排查手段。查看Tomcat的catalina.out和localhost.log以及XWiki的日志文件通常在xwiki-data-dir/logs/寻找与你的请求相关的错误或警告信息。日志会告诉你请求被拒的具体原因。3.检查文件权限登录服务器确认WEB-INF/目录及其下的配置文件对运行Tomcat的用户如tomcat是否具有读r权限。返回200 OK但内容是错误页面或乱码1. 成功读取了文件但文件是二进制或非文本格式浏览器或Burp以文本显示导致乱码。2. 读取到的文件内容被XWiki的某些处理器如模板引擎错误地解析或修改了。1.检查响应头查看Content-Type。如果是application/octet-stream说明服务器将其识别为二进制流下载。在Burp的响应面板中切换到“Hex”视图查看原始字节看开头部分是否有可识别的文本如XML声明?xml或配置文件注释#。2.尝试读取纯文本文件优先尝试读取WEB-INF/web.xmlXML文本或xwiki.properties属性文件这些文件更容易识别。请求被重定向或返回其他非预期响应1. XWiki的某些过滤器或安全机制对请求进行了重写或重定向。2. 会话或权限校验失败。1.使用Burp跟踪请求流在Burp的Proxy - HTTP history中确保你看到的是最终请求的响应。有时初始请求会被302重定向你需要跟随重定向在Repeater中勾选“Follow redirections”。2.携带有效会话如果目标端点需要登录才能访问你需要先用浏览器正常登录XWiki然后将Burp中捕获到的包含有效会话Cookie如JSESSIONID的请求发送到Repeater再用这个Cookie来构造路径遍历请求。6.2 环境配置与网络问题Tomcat无法启动或XWiki部署失败检查/var/log/tomcat9/catalina.out日志。常见原因包括端口冲突8080被占用、JDK版本不兼容、WAR包损坏、磁盘空间不足。确保已安装正确版本的JDKXWiki 16.x 通常需要JDK 8或11。虚拟机无法访问确认虚拟机网络配置NAT或桥接并在主机上使用ping和telnet ip 8080检查连通性。关闭虚拟机防火墙sudo ufw disable或放行8080端口sudo ufw allow 8080。Burp Suite抓不到包确认浏览器代理设置正确指向Burp通常127.0.0.1:8080。检查Burp的Proxy - Options中监听端口是否正确启用。如果是抓取虚拟机内浏览器的流量需要将Burp设置为监听所有接口0.0.0.0并在浏览器中设置代理为宿主机的IP地址。6.3 工具使用技巧与优化Burp Intruder高效爆破当需要系统测试../层数或不同文件名时手动修改效率低。使用Intruder的“Sniper”攻击类型。在Repeater中构造好基础请求如GET /xwiki/bin/download/Sandbox/§§/WEB-INF/web.xml。选中§§部分右键选择“Send to Intruder”。在Intruder的Positions标签页确认攻击点§§位置。在Payloads标签页添加自定义Payload列表例如..,../..,../../..,../../../..,../../../../..。开始攻击然后根据响应长度、状态码快速筛选出成功的Payload通常成功读取文件的响应长度会显著不同。编码绕过如果直接使用../被拦截尝试在Intruder的Payloads中设置编码。在Payload Processing中添加规则如“URL-encode these characters”。或者手动准备Payload列表..%2f,%2e%2e%2f,..%255cWindows路径分隔符等。利用cURL进行快速测试对于简单的请求测试cURL命令行更快捷。# 测试基本路径遍历 curl -v http://192.168.1.105:8080/xwiki/bin/download/Sandbox/../../WEB-INF/web.xml # 测试URL编码 curl -v http://192.168.1.105:8080/xwiki/bin/download/Sandbox/%2e%2e%2f%2e%2e%2fWEB-INF/web.xml # 携带Cookie进行测试从浏览器开发者工具复制 curl -v -H Cookie: JSESSIONIDABCDEF1234567890 http://target/path通过观察响应状态码和返回的前几行内容可以快速判断是否成功。复现漏洞的过程本质上是一个与目标系统“对话”和“试探”的过程。耐心、细致的观察和基于理解的测试远比盲目的工具扫描有效。每一次失败的请求其响应状态码和错误信息都在告诉你系统是如何处理你的输入的这些信息是调整攻击策略的关键。
相关文章
AI工程师必备术语解压包：50个硬核概念的工程化解读
1. 这不是词典，是AI从业者的“术语解压包” 你有没有过这种体验：刚打开一篇AI技术文章，三行不到就卡在“transformer”“attention机制”“embedding维度”上？不是不认真，是这些词像一堵墙，表面看着是中文&…
YOLOv26小目标检测优化：Shape-NWD损失函数实战
1. 项目概述今天要分享的是我在YOLOv26目标检测模型优化过程中的一个实战经验——如何通过改进损失函数来提升小目标检测性能。作为一名长期奋战在计算机视觉一线的算法工程师，我深知小目标检测一直是目标检测领域的难点问题。传统的IoU系列损失函数在面对小目标时表…
基于MP8859与PIC18的可编程DC-DC降压电源设计
1. 项目背景与核心器件选型在嵌入式电源设计领域，DC-DC降压转换是基础但关键的技术环节。本项目采用171010550（经查证为MP8859的型号变体）与PIC18LF45K50微控制器组合，构建了一个可编程控制的降压电源系统。这种组合特别适合需要精…
专科生必备的9款AI工具实战指南
1. 项目概述作为一名在AI工具领域摸爬滚打多年的从业者，我见过太多专科生在AI工具选择上踩坑的案例。今天要分享的这9款工具，都是经过我团队和学生实际验证过的"真香"产品。不同于市面上那些华而不实的推荐清单，这份指南特别针对专…
如何免费使用Fideo：一款简单高效的跨平台直播录制工具
如何免费使用Fideo：一款简单高效的跨平台直播录制工具 【免费下载链接】fideo-live-record A convenient live broadcast recording software! Supports Tiktok, Youtube, Twitch, Bilibili, Bigo!(一款方便的直播录制软件! 支持tiktok, youtube, twitch, 抖音&…
MLWE-1024同态加密技术如何将基因数据密文膨胀率降至1:48
1. 项目概述：当基因数据遇见全同态加密最近几年，基因测序成本断崖式下跌，从当年的“人类基因组计划”耗资数十亿美元，到现在几千块人民币就能做一次全基因组测序。数据量是爆炸了，但一个核心问题也摆在了所有从业者面前…
Nuclei-Burp插件：CVE信息自动填充，提升漏洞检测模板编写效率
1. 项目概述：当Nuclei模板生成遇上Burp Suite 如果你是一名渗透测试工程师或者漏洞研究员，那么你对Nuclei和Burp Suite这两款工具一定不会陌生。Nuclei以其海量的社区模板和高效的漏洞扫描能力，成为了自动化安全测试中的“瑞士军刀”。而Burp…
箱线图、小提琴图、山脊图：数据分布可视化三剑客实战指南
1. 这三类图不是“花架子”，而是你手头那堆数据的X光机我带过不少刚转行做数据分析的朋友，他们第一次看到箱线图（Box Plot）时，常脱口而出：“这不就是个带胡子的盒子？”——语气里带着点不屑。等…
多维聚合中的数据变形：维度层级、度量规则与变形链路实战
1. 这不是简单的“GROUP BY”——多维聚合中的数据变形术到底在解决什么问题？ 如果你正在处理销售报表、用户行为分析、IoT设备时序汇总，或者哪怕只是整理一份带地区、季度、产品线、渠道四个维度的Excel透视表，那你一定遇到过这种场景&#…
Playwright自动化测试实战：从零搭建现代Web测试框架
1. 项目概述：为什么是 Playwright？如果你正在为现代 Web 应用的自动化测试头疼，尤其是面对那些充斥着动态加载、复杂交互的单页应用（SPA），那么 Playwright 的出现，很可能就是你的解药。我接触过…
SSRF漏洞攻防实战：从原理到绕过技巧与防御策略
1. 项目概述：从“内部请求”到“内网漫游”的SSRF攻防实战 在渗透测试和红队评估的实战中，我们常常会遇到一种看似“温和”实则威力巨大的漏洞：服务器端请求伪造。它不像SQL注入那样直接操作数据库，也不像命令注入那样能瞬间拿到S…
本地部署SAM Audio音频语义分割模型完整指南
1. 项目概述：为什么要在本地跑 SAM Audio？这不只是“能用”，而是“必须用”SAM Audio——全称是 Segment Anything Model for Audio，不是 Meta 那个视觉领域的 SAM（Segment Anything Model）的简单移植&…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
FAE放射组学分析工具：医学影像特征探索的完整解决方案
FAE放射组学分析工具：医学影像特征探索的完整解决方案 【免费下载链接】FAE FeAture Explorer 项目地址: https://gitcode.com/gh_mirrors/fae/FAE 你是否曾经面对海量医学影像数据感到无从下手？想要从CT、MRI等影像中提取有价值的定量特征&#…
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南 【免费下载链接】happy-llm 📚 从零开始构建大模型 项目地址: https://gitcode.com/GitHub_Trending/ha/happy-llm 还在为大型多模态模型动辄数十亿参数、显存占用高而烦恼&…
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南 【免费下载链接】SMUDebugTool A dedicated tool to help write/read various parameters of Ryzen-based systems, such as manual overclock, SMU, PCI, CPUID, MSR and Power Table. 项目地址…