Struts2框架的OGNL表达式漏洞是网络安全领域一个持续演变的经典案例，其核心在于Struts2对用户输入数据与OGNL表达式引擎的绑定处理存在缺陷。攻击者能够构造特定的HTTP请求参数，这些参数被框架解析时，会触发OGNL表达式在服务器端的执行，从而可能实现远程代码执行、数据窃取或服务器控制。最直接的缓解方法是严格过滤和验证所有用户输入，并在安全配置中禁用不必要的OGNL特性，例如设置"struts.ognl.disallow.class.expression=true"。然而，漏洞的“演变”意味着攻击手法和防御策略随着Struts2版本更新和补丁发布而不断变化，需要开发者持续跟踪。

OGNL表达式与Struts2的工作机制：漏洞的根源

OGNL（Object-Graph Navigation Language）是Struts2用于在视图层与模型层之间绑定和传输数据的强大表达式语言。它允许在JSP页面中通过简洁语法动态访问和操作Java对象属性。在Struts2中，HTTP请求参数的值可以通过OGNL表达式被映射到Action类的属性或直接参与计算。问题在于，框架默认对传入的参数值进行了过于“智能”的解析。当参数值包含特定的OGNL语法，如"#"、"@"等字符时，Struts2可能会将其当作真正的OGNL表达式来执行，而非简单的字符串赋值。这种设计初衷是为了便利，但却打开了安全缺口。

例如，一个正常的参数传递可能是"user.name=John"，将其赋值给Action的user对象的name属性。但如果攻击者提交参数"user.name=#{[email protected]().getRuntime().exec('calc')}"，在未做防护的旧版本中，Struts2的OGNL解析器可能会评估"#"后面的表达式，尝试执行命令。漏洞的根源就在于这种“表达式注入”。

漏洞演变史：从S2-003到S2-061的攻防博弈

Struts2 OGNL漏洞的演变是一部攻防技术不断升级的历史。早期漏洞如S2-003（CVE-2008-2674）利用了OGNL表达式对参数值本身的递归解析。官方通过引入"\u0023"作为"#"的转义修复，但很快在S2-005中被绕过，攻击者直接使用OgnlContext的"#"键值进行攻击。随后的修复引入了安全模式限制。

重大的转折点是S2-016（CVE-2013-1966）和S2-017，漏洞范围扩展到Struts2的默认Action映射和重定向参数处理。攻击者不再局限于表单参数，而是可以通过修改请求路径（如"/index.action?redirect:%{[email protected]().getRuntime().exec('cat /etc/passwd')}"）触发漏洞。Apache随后加强了重定向逻辑和对"#"字符的过滤。

// 一个简化的恶意参数示例（概念性）
http://target.com/login.action
?action=%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'whoami'})).start()}

S2-045（CVE-2017-5638）是另一个里程碑，它与文件上传组件有关。漏洞源于对上传文件内容类型（Content-Type）头部的错误解析，该头部值被直接送入OGNL引擎。这个漏洞影响极大，因为它无需认证，且攻击payload在HTTP头部，容易被防火墙遗漏。修复方式是对Multipart解析器进行了彻底的重写和安全加固。

最近的S2-061（CVE-2020-17530）展示了漏洞演变的复杂性。它是S2-059修复的绕过，证明了即使对OGNL表达式进行了沙箱化和字符过滤，攻击者仍可能通过精心构造的嵌套表达式（如双重"#"计算）达到执行目的。这体现了漏洞研究的深度：防御规则的微小缝隙都可能被利用。

漏洞利用的技术细节与攻击向量扩展

攻击者利用OGNL漏洞的技术不断精进。最初只是简单的命令执行，后来扩展到利用OGNL特性调用静态方法、访问静态字段、创建新对象、甚至操纵Struts2内部的SecurityMemberAccess设置来禁用安全限制。攻击向量也从最初的GET/POST请求参数，扩展到HTTP头部（如S2-045）、Action名称、重定向参数乃至标签属性。

一个高级技巧是利用OGNL的“表达式求值”特性。OGNL允许使用"%{}"语法强制对括号内的内容进行即时求值。攻击者将恶意代码包裹在"%{}"中，结合框架对某些参数（如"action"、"method"）的自动求值逻辑，实现注入。此外，攻击链也开始结合其他Java漏洞，例如利用OGNL表达式加载并使用危险的Java类（如"ProcessBuilder"、"ScriptEngineManager"）来执行脚本或命令。

// 利用OGNL调用静态方法获取Runtime实例（概念性）
#{[email protected]().getRuntime()}
// 或结合Java反射绕过限制
#{[email protected]('java.lang.Runtime').getMethod('getRuntime').invoke(null)}

防御策略的演变：从补丁到架构思考

防御策略同样在演变。最初的修复往往是“打补丁”——增加黑名单字符过滤或转义特定序列。但这种方法容易被绕过。随后，Apache引入了更系统的“安全模式”和OGNL表达式沙箱，通过配置"ognl.SecurityMemberAccess"类来限制可访问的类和方法范围，例如禁止访问"ClassLoader"、"Runtime"等危险类。

关键的防御配置包括：

1. 在"struts.xml"中设置严格的OGNL属性："<constant name="struts.ognl.disallow.class.expression" value="true" />" 这会禁止OGNL表达式创建新的类实例或访问静态方法，大幅降低风险。

2. 升级到最新版本并密切关注安全公告。每个重大漏洞（如S2-045, S2-061）后，Apache都会发布新版本，修复不只是针对单一漏洞，还会增强整体OGNL处理逻辑。

3. 实施全面的输入验证。不仅对用户输入进行长度、格式检查，更重要的是，在框架层拦截所有包含OGNL语法特征（"#", "%", "$", "@"等）的参数值，除非业务明确需要。

4. 最小化框架特性使用。例如，若非必要，禁用动态方法调用（"struts.enable.DynamicMethodInvocation=false"）和某些灵活的映射机制。

5. 架构层面的思考：许多团队在经历多次Struts2漏洞后，开始考虑迁移到更现代、设计更安全的框架（如Spring Boot），后者在数据绑定和表达式处理上采取了更保守和安全的设计。

对开发者和运维人员的持续建议

对于仍在使用Struts2的团队，持续安全管理是必须的。首先，建立依赖库监控机制，确保Struts2及相关库的版本及时更新。使用漏洞扫描工具定期检查应用。其次，在代码审查中，重点关注所有接收用户输入并可能传递给Struts2 Action的地方，包括控制器、拦截器和标签库。

运维层面，在Web应用防火墙（WAF）中配置针对Struts2 OGNL漏洞特征的规则，拦截包含典型恶意模式（如"#{[email protected]", "new ProcessBuilder"）的请求。同时，确保服务器运行在最小权限下，即使命令被执行，也能限制其破坏力。

最后，认识到OGNL漏洞的演变不会停止。只要Struts2继续使用强大的表达式语言作为核心数据绑定机制，潜在的风险就会存在。安全是一个持续的过程，需要结合框架配置、代码实践、基础设施防护和威胁情报，形成多维度的防御体系。

总结：从OGNL漏洞看框架安全设计

Struts2 OGNL表达式漏洞的演变史，揭示了框架安全设计中的一个深刻教训：便利性与安全性往往需要权衡。一个功能强大、灵活性高的特性（如动态表达式解析），如果未在设计之初就考虑最坏情况下的输入，极易成为持续的安全痛点。它教育了后来的框架设计者，在处理用户输入时，必须采用“默认拒绝”而非“默认允许”的策略。

对于广大开发者而言，这段历史强调了“深度理解所用技术栈”的重要性。仅仅会使用Struts2开发功能是不够的，必须理解其内部工作机制，尤其是数据流和表达式引擎，才能预见风险，实施有效防护。漏洞的演变，本质上是攻击者对框架理解不断加深的过程，防御者只有以同等或更深的理解去应对，才能守住阵地。