1. 这个漏洞不是“又一个Struts2远程命令执行”而是OGNL解析器的逻辑断层S2-062CVE-2021-31805在2021年8月被披露时很多安全从业者第一反应是“哦Struts2又爆RCE了”。但真正动手复现、读透补丁代码后你会发现它和S2-045、S2-046、S2-057这些经典漏洞有本质区别——它不依赖OGNL表达式注入触发任意代码执行而是利用OGNL解析器在处理特定语法结构时的短路逻辑缺陷绕过所有已知的防护机制直接达成上下文篡改与方法调用劫持。我去年在给某省政务平台做渗透测试时就遇到一台打了S2-057补丁但未升级到2.5.30的Struts2应用常规Payload全部失效直到翻出S2-062的原始报告才打通链路。这个漏洞的核心不在“怎么注入”而在“为什么解析器会信你”。关键词里没填但热搜词已经暴露了真实语境当前一线红队和漏洞研究者最关心的不是“有没有漏洞”而是“复现率高不高、环境搭得稳不稳、Payload能不能过WAF、调试过程清不清楚”。所以这篇内容完全跳过教科书式的CVE编号介绍直接从一个真实复现失败的报错开始java.lang.ClassCastException: java.lang.String cannot be cast to ognl.Node。这个异常不是你写错了Payload而是你用错了Struts2版本——S2-062只影响2.0.0至2.5.29之间的版本且必须启用DynamicMethodInvocationDMI功能默认开启而2.5.30版本通过重构OGNL解析树构建逻辑彻底堵死了该路径。它不是一个“补丁一打就完事”的漏洞而是一次对OGNL引擎底层设计哲学的拷问当解析器为了性能牺牲语法严谨性时攻击面会以何种形式反噬我实测过17种常见Struts2部署组合包括Tomcat 7/8/9 JDK 7/8/11、WebLogic 12c、JBoss EAP 6.4发现只要满足版本条件且未禁用DMI漏洞稳定触发。但真正卡住多数人的从来不是环境搭建而是Payload构造逻辑的误解。网上流传的%{#context[xwork.MethodAccessor.denyMethodExecution]false, #_memberAccess.allowStaticMethodAccesstrue, java.lang.RuntimegetRuntime().exec(calc)}这类“万能模板”在S2-062下根本无效——因为该漏洞不走OGNL表达式求值主路径而是通过ActionMapping对象的methodName字段触发解析器的“非预期分支”。换句话说你不是在“执行命令”而是在“欺骗解析器认为某个字符串是合法的方法名”进而让它调用你指定的静态方法。这种思维转换才是复现成功的关键门槛。2. 漏洞根源OGNL解析器的“方法名解析”逻辑断层要理解S2-062必须先看清Struts2中Action调用的完整链条。用户请求/login.action?methodexecute时Struts2会经历①Dispatcher解析URL获取Action名称和method参数②ActionMapping构建映射对象其中methodName字段被赋值为execute③DefaultActionProxy调用invocation.invoke()执行目标方法。而问题就出在第②步——当method参数值包含特殊字符如#、、{时ActionMapping的setMethodName()方法会直接将该字符串赋给methodName字段不做任何校验。这本身没问题但后续DefaultActionProxy在调用invocation.invoke()前会尝试通过OGNL解析器解析methodName字段的值以支持动态方法调用DMI。这里就是断层所在。2.1 OGNL解析器的“短路信任”机制OGNL解析器在处理形如#someStaticMethod()的字符串时本应将其识别为“静态方法调用表达式”并进入严格的语法校验流程。但在S2-062影响的版本中解析器存在一个优化逻辑当遇到以#开头的字符串且后续字符符合“类名.方法名()”格式时会跳过完整的AST抽象语法树构建直接尝试反射调用。这个优化本意是提升常用静态方法调用的性能却埋下致命隐患——它没有验证#之后的字符串是否真的指向一个可访问的静态方法也没有检查调用上下文是否允许此类操作。更关键的是这个“短路路径”完全绕过了SecurityMemberAccess的拦截逻辑因为SecurityMemberAccess的检查发生在AST遍历阶段而短路路径根本不生成AST。我用Ghidra反编译ognl-3.1.26.jar的NodeCompiler类时发现问题代码集中在compileExpression()方法的第142行附近当expression.startsWith(#) expression.contains(.) expression.endsWith(())为真时直接调用OgnlRuntime.compileExpression()的简化分支跳过SecurityMemberAccess的checkMemberAccess()调用。这就是整个漏洞的物理位置。你可以把它想象成一栋大楼的消防通道——设计初衷是紧急疏散但门锁坏了且监控摄像头正对着通道口却没录像权限。攻击者不需要撬锁只需要按响消防警报发送特定格式的method参数门就会自动弹开。2.2 Struts2的DMI机制如何放大风险Dynamic Method InvocationDMI是Struts2早期为简化开发提供的特性允许用户通过URL参数methodxxx直接调用Action类的任意public方法而非仅限于execute()。虽然官方文档早已标注“DMI存在安全风险请禁用”但大量遗留系统仍默认开启。S2-062的威力正在于此它不是独立漏洞而是DMI机制与OGNL解析器缺陷的“组合技”。当DMI启用时ActionMapping.setMethodName()接收的恶意字符串会被DefaultActionProxy.prepare()方法传递给OGNL解析器触发前述短路路径。如果DMI被禁用struts.enable.DynamicMethodInvocationfalsemethod参数会被直接忽略漏洞自然失效。我在复现时特意对比了启用/禁用DMI的两种场景。启用DMI时发送GET /login.action?method%23%40java.lang.Runtime%40getRuntime%28%29.exec%28%22calc%22%29URL编码后的#[java.lang.RuntimegetRuntime().exec(calc)]服务器立即弹出计算器禁用DMI后同一请求返回404或默认Action页面。这证明漏洞利用严格依赖DMI开关状态也解释了为何部分扫描器报告“存在S2-062”却无法RCE——它们只检测版本未验证DMI配置。2.3 与S2-045/S2-057的本质差异很多初学者会把S2-062和S2-045基于Content-Type头的OGNL注入或S2-057基于redirect:协议的OGNL注入混为一谈这是复现失败的首要原因。三者利用点完全不同S2-045攻击面在HTTP请求头利用Content-Type等头字段被Struts2错误解析为OGNL表达式触发ognl.OgnlUtil.setValue()。S2-057攻击面在redirect:结果类型利用redirect:后拼接的URL被当作OGNL表达式解析。S2-062攻击面在method请求参数利用DMI机制下methodName字段的OGNL解析短路。这意味着S2-062的Payload必须放在method参数中放Content-Type或redirect:里完全无效它不依赖%{}包裹因为根本没走OGNL表达式求值主流程WAF规则若只拦截%{或#context等特征对S2-062的#[...]Payload大概率放行——因为这是“合法”的方法名语法不是“可疑”的表达式。我曾用某国产WAF测试其规则库明确拦截%{.*?}和#context但对method%23%40java.lang.Runtime%40getRuntime%28%29.exec%28%22id%22%29毫无反应直到我手动添加method.*?%23%40.*?%28.*?%29规则才阻断。这印证了S2-062的隐蔽性它伪装成正常业务参数而非典型攻击载荷。3. 复现环境搭建避开90%新手踩的“版本陷阱”复现S2-062最大的坑不是技术细节而是环境版本选择。网上教程普遍推荐struts2-showcase-2.3.32.war但这个版本实际对应Struts2 2.3.32而S2-062影响范围是2.0.0–2.5.29。2.3.32在2.5.29之前理论上可利用但实测发现其ognl依赖版本为ognl-3.0.21而漏洞核心在ognl-3.1.26的NodeCompiler类。我花两天时间逐个测试了12个官方Demo WAR包最终确认唯一稳定复现的版本是struts2-showcase-2.5.20.war对应ognl-3.1.26其他版本要么因OGNL版本不符要么因Tomcat/JDK兼容性问题导致500错误。3.1 推荐环境组合与验证步骤组件推荐版本验证命令关键说明Struts2struts2-showcase-2.5.20.warjar -tf struts2-showcase-2.5.20.war | grep ognl必须看到ognl-3.1.26.jar否则无效Servlet容器Tomcat 8.5.90curl -I http://localhost:8080/struts2-showcase/返回200且含Server: Apache-Coyote/1.1JDKOpenJDK 8u362java -versionJDK 11因模块化限制可能触发ClassNotFoundException操作系统Ubuntu 20.04 LTSuname -r内核5.4.x对Java进程兼容性最佳提示不要用Docker一键部署镜像我测试过5个公开的struts2-vuln镜像4个预装了2.5.30版本或禁用了DMI。务必手动下载WAR包部署。部署步骤以Ubuntu为例# 1. 下载并解压Tomcat wget https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.90/bin/apache-tomcat-8.5.90.tar.gz tar -xzf apache-tomcat-8.5.90.tar.gz # 2. 下载Struts2 Showcase 2.5.20 wget https://github.com/apache/struts/releases/download/STRUTS_2_5_20/struts2-showcase-2.5.20.war cp struts2-showcase-2.5.20.war apache-tomcat-8.5.90/webapps/ # 3. 启动Tomcat关键添加JVM参数禁用SecurityManager echo JAVA_OPTS-Djava.security.manager -Djava.security.policy/dev/null apache-tomcat-8.5.90/bin/setenv.sh apache-tomcat-8.5.90/bin/startup.sh # 4. 验证OGNL版本进入Tomcat日志目录 tail -f apache-tomcat-8.5.90/logs/catalina.out \| grep ognl # 正常应输出Loading OGNL library: ognl-3.1.26.jar3.2 DMI配置的双重确认法很多复现失败源于DMI看似启用实则被覆盖。Struts2的配置优先级是struts.xmlstruts.properties 默认值。必须双重确认检查webapps/struts2-showcase/WEB-INF/classes/struts.xml搜索constant namestruts.enable.DynamicMethodInvocation valuetrue/若不存在则需手动添加检查webapps/struts2-showcase/WEB-INF/classes/struts.properties确认struts.enable.DynamicMethodInvocation true注意空格运行时验证访问http://localhost:8080/struts2-showcase/user/login.action?methodtoString若返回java.lang.String即调用了Object.toString()证明DMI生效若返回404或登录页则配置失败。注意struts.xml中的constant必须放在struts根节点内且不能被注释掉。我曾因复制粘贴时多了一个!--导致配置失效排查3小时才发现。3.3 Payload构造的三个黄金法则S2-062的Payload不是“越复杂越好”而是“越贴近方法名语法越稳”。遵循以下法则可100%绕过基础WAF必须以#开头且#后紧跟#[...]是触发短路路径的唯一入口%{...}或#context均无效类名必须完整且方法必须存在java.lang.RuntimegetRuntime()比RuntimegetRuntime()可靠因为后者可能因类加载器问题找不到类括号必须闭合参数必须匹配exec(calc)在Windows有效但Linux需用exec(sh -c id)且引号必须URL编码。实测最简有效PayloadLinuxGET /struts2-showcase/user/login.action?method%23%40java.lang.Runtime%40getRuntime%28%29.exec%28%22sh-cid%22%29 HTTP/1.1 Host: localhost:8080URL解码后为method#[java.lang.RuntimegetRuntime().exec(sh -c id)]提示不要用Burp Suite的Auto-encode功能它会把(编码为%28但把编码为%27而某些WAF会拦截%27。手动编码更可控sh -c id→sh-cid用替代空格保留。4. 深度调试用IDEA源码级跟踪还原漏洞触发链复现成功只是开始真正掌握S2-062需要源码级调试。我用IntelliJ IDEA Ultimate版配合struts2-core-2.5.20-sources.jar和ognl-3.1.26-sources.jar完整跟踪了从HTTP请求到命令执行的17个关键方法调用。这不是为了炫技而是因为只有看到NodeCompiler.compileExpression()跳过SecurityMemberAccess.checkMemberAccess()的那一刻你才会真正理解“为什么这个漏洞无法被传统WAF规则覆盖”。4.1 断点设置的精准位置在IDEA中按以下顺序设置断点必须全部命中缺一不可org.apache.struts2.dispatcher.Dispatcher.serviceAction()—— 请求入口确认method参数被正确解析org.apache.struts2.dispatcher.mapper.ActionMapper.getMapping()—— 查看ActionMapping对象的methodName字段值com.opensymphony.xwork2.DefaultActionProxy.prepare()—— 关键此处调用invocation.invoke()前会触发OGNL解析ognl.OgnlRuntime.compileExpression()—— 在NodeCompiler.compileExpression()方法内找到if (expression.startsWith(#) ...)分支ognl.OgnlRuntime.getValue()—— 观察Node对象是否为ASTStaticMethod而非ASTChain。注意第4步断点必须设在NodeCompiler.java的compileExpression()方法内部而非OgnlRuntime.compileExpression()。后者是门面方法实际逻辑在NodeCompiler。4.2 调试过程中的关键观察点启动调试后发送Payload请求IDEA会在第1个断点暂停。此时按F8逐步执行重点关注Step 1在Dispatcher.serviceAction()中params.get(method)的值应为URL解码后的#[java.lang.RuntimegetRuntime().exec(sh -c id)]Step 2在ActionMapper.getMapping()中mapping.getMethodName()返回值应与Step 1完全一致Step 3在DefaultActionProxy.prepare()中invocation.invoke()调用前mapping.getMethodName()被传入OgnlUtil.compile()Step 4在NodeCompiler.compileExpression()中当expression.startsWith(#)为真时代码进入// Short-circuit for static method calls注释块跳过SecurityMemberAccess相关代码约第150行Step 5在OgnlRuntime.getValue()中node对象类型为ASTStaticMethodnode.getClassName()返回java.lang.Runtimenode.getMethodName()返回getRuntime证明静态方法调用已确立。我截图保存了Step 4的调试视图左侧变量窗显示expression#[java.lang.RuntimegetRuntime().exec(sh -c id)]右侧代码高亮显示return new ASTStaticMethod(...)而下方SecurityMemberAccess.checkMemberAccess(...)被灰色未执行。这就是漏洞的“犯罪现场”。4.3 修复方案的源码级验证Struts2 2.5.30的修复方案是重构NodeCompiler.compileExpression()移除短路逻辑强制所有#开头的表达式都走完整AST构建流程。在IDEA中对比2.5.20和2.5.30的NodeCompiler.java2.5.20版本存在if (expression.startsWith(#) expression.contains(.) expression.endsWith(())) { return new ASTStaticMethod(...); }2.5.30版本该if块被删除所有表达式统一调用Parser.parseExpression()再由SecurityMemberAccess检查。验证修复效果将struts2-core-2.5.30.jar替换进Tomcat的webapps/struts2-showcase/WEB-INF/lib/重启后发送相同PayloadIDEA会在SecurityMemberAccess.checkMemberAccess()处中断member参数为getRuntimeaccessType为MemberAccess.PUBLIC_MEMBER_ACCESS最终抛出IllegalAccessException。这证明修复有效——不是堵住某个Payload而是让所有静态方法调用都经过安全检查。5. 实战防御不止于“升级版本”的五层加固策略单纯告诉运维“升级到2.5.30以上”是不负责任的。在真实企业环境中升级可能涉及兼容性测试、回归验证、停机窗口等成本。S2-062的防御必须分层实施每层解决不同风险维度。我给三家金融客户实施的加固方案均在72小时内完成且零业务影响。5.1 应用层禁用DMI的硬性配置首选这是最直接、最有效的缓解措施。修改struts.xmlstruts !-- 禁用动态方法调用 -- constant namestruts.enable.DynamicMethodInvocation valuefalse/ !-- 同时禁用通配符映射防止method参数被滥用 -- constant namestruts.mapper.alwaysSelectFullNamespace valuetrue/ /struts提示struts.mapper.alwaysSelectFullNamespacetrue可防止/action!method语法绕过DMI禁用。我曾见某银行系统只禁用DMI但未关通配符攻击者用/user!toString.action仍可触发漏洞。5.2 容器层JVM SecurityManager强化即使Struts2版本未升级也可通过JVM层拦截危险调用。在Tomcat的bin/setenv.sh中添加JAVA_OPTS$JAVA_OPTS -Djava.security.manager -Djava.security.policy/opt/tomcat/conf/java.policy创建/opt/tomcat/conf/java.policygrant { permission java.lang.RuntimePermission exitVM; permission java.lang.RuntimePermission getClassLoader; // 移除以下权限即可阻止Runtime.exec // permission java.lang.RuntimePermission setSecurityManager; };重启Tomcat后S2-062 Payload会抛出AccessControlException: access denied (java.lang.RuntimePermission exec)。此方案不影响业务但需测试第三方SDK是否依赖Runtime.exec如某些PDF生成库。5.3 网关层Nginx/WAF的精准规则针对无法立即升级的系统Nginx可添加如下规则nginx.conf# 拦截method参数中的危险模式 if ($args ~* method.*%23%40.*%28.*%29) { return 403; } # 或更精确地匹配静态方法调用 if ($args ~* method%23%40[a-zA-Z0-9._]%40[a-zA-Z0-9_]%28.*%29) { return 403; }WAF规则建议以ModSecurity为例SecRule ARGS:method rx ^#\[[a-zA-Z0-9._][a-zA-Z0-9_]\(\)$ \ id:1001,phase:2,deny,status:403,msg:S2-062 Attempt注意规则必须放在ARGS:method而非通用ARGS避免误杀正常参数。我帮某电商客户部署时因规则写成ARGS:rx导致所有含的邮箱参数被拦截损失订单。5.4 监控层ELK日志的异常行为检测在Logstash中添加过滤规则捕获可疑method参数filter { if [url] ~ /\/.*\.action\?method/ { grok { match [url, \?method(?method[^])] } if [method] ~ /^#\[.*\(\)$/ { mutate { add_tag [s2-062-suspicious] } } } }Kibana中创建告警tags:s2-062-suspicious and status:200即成功触发且返回200的请求。这比被动扫描更主动——我们曾用此方案在漏洞披露前3天捕获到内部测试人员的误操作流量。5.5 开发层代码审计的自动化脚本编写Python脚本扫描项目中所有struts.xml文件import xml.etree.ElementTree as ET import sys def check_dmi_disabled(file_path): try: tree ET.parse(file_path) root tree.getroot() for constant in root.iter(constant): if constant.get(name) struts.enable.DynamicMethodInvocation: if constant.get(value) false: print(f[OK] {file_path}: DMI disabled) return True print(f[ALERT] {file_path}: DMI not disabled!) return False except Exception as e: print(f[ERROR] {file_path}: {e}) if __name__ __main__: for f in sys.argv[1:]: check_dmi_disabled(f)集成到CI/CD流水线在代码提交时自动扫描。某证券公司上线此脚本后3个月内拦截了17次开发人员误开启DMI的提交。6. 复现之外从S2-062看Java Web框架的安全演进S2-062不是Struts2的终点而是Java Web安全史的一个坐标点。它揭示了一个残酷事实框架的安全性不取决于单次补丁而取决于其底层依赖的设计哲学。OGNL作为Struts2的“血液”其解析器的每一次优化都可能在未知角落埋下新的雷。我参与过Spring Framework 5.3的审计发现其SpelExpressionParser同样存在类似短路逻辑——当表达式以T(开头时会跳过部分类型检查。这并非巧合而是性能与安全永恒博弈的必然产物。当前主流框架的应对策略已转向“隔离”而非“修补”Spring Boot 3.x默认禁用SpEL在Value中的使用Quarkus通过编译期AOTAhead-of-Time将OGNL表达式编译为字节码彻底移除运行时解析Micronaut则干脆弃用反射用编译时生成的代理类替代动态调用。这些方案的共同点是把安全检查从运行时前置到编译时把“能否执行”变成“能否编译”。对红队而言S2-062的价值在于训练一种思维不要只盯着“Payload怎么写”更要问“为什么这个Payload能过”。当我看到#[...]时第一反应不再是“这是OGNL表达式”而是“这是OGNL解析器的快捷入口它的验证逻辑在哪里被绕过了”——这种溯源能力才是穿透层层WAF和加固的真实武器。最后分享一个实战技巧在渗透测试中若目标系统Struts2版本模糊可用/struts2-showcase/路径试探。返回Welcome to Struts Showcase页面后立即发送?methodtoString若响应体含class org.apache.struts2.views.freemarker.FreemarkerResult则DMI启用且版本可能受影响若返回404则DMI已禁用或版本过高。这个技巧帮我快速筛掉了70%的无效目标把时间留给真正有价值的系统。
