别再死记硬背POC了！深入理解Struts2漏洞家族史与OGNL表达式攻防演进
从OGNL表达式到漏洞家族史：Struts2安全攻防演进全景剖析
在Java Web安全领域，Struts2框架的漏洞史堪称一部活教材。许多安全工程师能够熟练使用工具复现S2-045、S2-057等著名漏洞，却对漏洞背后的技术原理和演进逻辑一知半解。这种知其然而不知其所以然的状态，往往导致面对新型变种攻击时束手无策。本文将带您穿越Struts2漏洞的时间长廊，揭示OGNL表达式如何成为贯穿十余年安全攻防的核心战场。
1. OGNL表达式：Struts2漏洞的"罪魁祸首"
OGNL（Object-Graph Navigation Language）作为Struts2框架的核心表达式语言，原本是为了简化数据访问和操作而设计。其强大的动态特性允许开发者通过简洁的语法实现复杂操作：
// 典型OGNL表达式示例 user.address.city这种灵活性却埋下了安全隐患。OGNL支持以下危险特性：
- 静态/动态方法调用（
@java.lang.Runtime@getRuntime()） - 构造函数调用（
new java.util.ArrayList()） - 多重表达式嵌套
早期Struts2版本的关键失误在于：将用户输入直接作为OGNL表达式解析，且未实施任何沙箱防护。2007年的S2-001漏洞正是这一设计缺陷的首次爆发——攻击者只需在表单字段中输入OGNL表达式，服务端就会执行：
%{#a=new java.lang.ProcessBuilder("calc").start()}漏洞修复启示：Struts2团队在后续版本中增加了
OgnlContext的安全检查，但治标不治本
2. 漏洞演化史：攻防博弈的技术轮回
2.1 第一代漏洞：直接表达式注入（S2-001至S2-012）
这一阶段的漏洞特征是利用框架对用户输入的原始处理缺陷：
| 漏洞编号 | 触发点 | 利用方式示例 | 修复方案 |
|---|---|---|---|
| S2-001 | 表单提交参数 | %{#a=@getRuntime().exec(...)} | 增加基础OGNL过滤 |
| S2-003 | 参数名解析 | ('\u0023')(...)=1 | 加强Unicode转义处理 |
| S2-005 | Cookie值处理 | (#_memberAccess=@DEFAULT_MEMBER_ACCESS) | 限制静态方法调用 |
典型绕过技巧：
- Unicode编码绕过（
\u0023代替#） - 参数名注入（
user?('age')=123） - 多层表达式嵌套（
${#a=${#b}}）
2.2 第二代漏洞：上下文污染攻击（S2-013至S2-032）
当直接表达式注入被严格限制后，攻击者转向污染框架执行上下文：
// S2-016的典型利用：通过redirectAction污染值栈 http://target/struts2-showcase/employee/save.action?redirect:${#a=new java.lang.ProcessBuilder("calc").start()}这一阶段的关键突破点包括：
- REST插件漏洞（S2-020）：通过XStream处理器实现反序列化
- 动态方法调用（S2-032）：
method:前缀绕过 - 多重解析漏洞（S2-029）：二次URL解码导致防护失效
实战经验：在测试S2-037时，我们发现
%{(#_='multipart/form-data')}这样的Content-Type污染可以绕过沙箱限制
2.3 第三代漏洞：架构级缺陷爆发（S2-045至S2-061）
2017年的S2-045标志着Struts2漏洞进入新阶段——攻击面从业务逻辑转向框架底层架构：
- 文件上传漏洞（S2-046）：通过精心构造的Content-Type头触发OGNL解析
- 命名空间混淆（S2-057）：URL解析逻辑缺陷导致的安全边界突破
- 标签属性滥用（S2-059）：强制OGNL评估非预期属性
POST /struts2-showcase/fileupload/doUpload.action HTTP/1.1 Content-Type: %{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS)}3. 防御体系构建：从补丁到架构安全
3.1 官方修复方案演进分析
Struts2团队的防护策略经历了三个阶段：
黑名单过滤阶段（2.0.x-2.3.x）：
- 禁用特定关键字（
#,@等） - 问题：容易被编码绕过
- 禁用特定关键字（
沙箱模式阶段（2.5.x）：
// 典型沙箱配置 OgnlContext context = (OgnlContext)Ognl.createDefaultContext(root); context.setMemberAccess(new SecurityMemberAccess());白名单控制阶段（2.5.26+）：
- 严格限制可访问的类和方法
- 默认关闭动态方法调用
3.2 企业级防护方案建议
多层次防御矩阵：
| 防护层级 | 具体措施 | 实施示例 |
|---|---|---|
| 代码层 | 升级至最新安全版本 | Struts 2.5.30+ |
| 配置层 | 禁用动态方法调用 | struts.enable.DynamicMethodInvocation=false |
| 架构层 | WAF规则定制 | 拦截包含#_memberAccess的请求 |
| 运行时 | RASP防护 | 检测OGNL表达式执行行为 |
关键配置检查项：
# struts.xml安全配置示例 <constant name="struts.excludedClasses" value="java.lang.Object,java.lang.Runtime" /> <constant name="struts.ognl.allowStaticMethodAccess" value="false" />4. 现代攻击手法与检测对抗
4.1 新型攻击向量
2020年后出现的攻击技术演进：
- 表达式碎片注入：将恶意载荷拆分到多个参数
- 上下文属性污染：利用
#parameters等隐含对象 - EL表达式混合攻击：结合JSP EL的特性绕过检测
GET /user.action?name=${#a=#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse']} HTTP/1.14.2 检测与防御实践
攻击特征指纹库：
# 检测S2-061的YARA规则 rule struts2_ognl_injection { strings: $s1 = "#_memberAccess" $s2 = "@java.lang.Runtime@" condition: any of them }防御层纵深部署建议：
- 网络层：WAF规则更新（重点关注
Content-Type、User-Agent等头部） - 主机层：文件完整性监控（检查
struts.xml配置） - 应用层：定期依赖扫描（使用OWASP Dependency-Check）
在一次红队评估中，我们发现即使最新版本的Struts2应用，如果错误配置了alwaysSelectFullNamespace参数，仍然可能受到命名空间混淆攻击。这提醒我们：框架安全不仅是版本问题，更是配置管理问题。