1. 从一次线上故障说起一个看似无害的字符串引发的血案去年我们团队负责的一个核心业务系统在深夜突然报警CPU使用率瞬间飙到100%紧接着大量请求超时用户反馈页面卡死。紧急排查日志发现一个奇怪的现象大量请求都指向同一个用户个人资料查询接口但查询的用户ID看起来都极其相似像是一串精心构造的字符串其中包含了类似#this.getClass().forName(java.lang.Runtime).getRuntime().exec(calc)这样的片段。看到这个我心里咯噔一下这不是典型的表达式注入攻击吗而且从语法上看极有可能是针对OGNLObject-Graph Navigation Language的。我们立刻对该接口进行了熔断系统才逐渐恢复。事后复盘问题出在一个“动态权限校验”的功能上开发同学为了灵活允许前端传入一个表达式字符串后端用OGNL引擎去解析执行以此判断用户是否有权查看目标数据。初衷是好的但直接拼接用户输入到OGNL表达式里无异于敞开大门请黑客进来。这次事故让我深刻意识到表达式注入尤其是OGNL表达式注入绝不仅仅是安全团队扫描报告里的一个抽象名词而是悬在每一个Java开发者头上的达摩克利斯之剑。它可能隐藏在任何一个允许用户输入动态影响程序逻辑的角落自定义查询过滤器、动态模板渲染、规则引擎配置甚至是某些框架的“高级”特性里。很多人觉得自己的项目用了Spring Boot、MyBatis这些主流框架就安全了殊不知危险往往源于对底层机制的不了解和滥用。今天我就结合这次踩坑经历和多年的安全开发实践彻底拆解Java表达式注入特别是OGNL注入的原理、危害、挖掘和修复让你不仅能看懂漏洞报告更能从代码层面主动防御。2. OGNL表达式注入的本质当字符串不再是数据而是代码要理解OGNL注入首先得明白OGNL是什么以及它为什么会被滥用。2.1 OGNL是什么它为何强大又危险OGNL最初是作为Struts2框架的默认表达式语言被广泛认知的。它的全称是Object-Graph Navigation Language即对象图导航语言。顾名思义它的核心能力是通过一种简洁的语法来访问和操作Java对象图中的任意属性、调用其方法。举个例子假设我们有一个User对象它有一个Address属性Address里又有city属性。在Java代码里我们可能需要写user.getAddress().getCity()。而在OGNL里只需要写成user.address.city。这种简洁性在视图层如JSP标签、模板和配置中非常有用。但OGNL的能力远不止属性访问。它是一个功能完整的表达式语言支持方法调用object.method(args)静态方法调用java.lang.Systemexit(1)构造对象new java.util.ArrayList()赋值操作name ‘hacker’复杂的Lambda表达式和投影操作正是这种强大的动态执行能力让它变得危险。当开发者将用户可控的输入未经任何处理就直接拼接进一个待执行的OGNL表达式字符串中时攻击者输入的就不再是普通数据而是一段可以被OGNL引擎执行的代码。程序的本意可能是让用户输入一个“属性名”来动态获取值但攻击者输入的是一个“方法调用”来执行系统命令。2.2 漏洞产生的典型模式错误的“动态”实现漏洞代码通常长什么样我们来看几个高危场景场景一Struts2的历史之殇Struts2早期版本将用户输入的参数名和值直接用于OGNL表达式求值造成了轰动一时的系列漏洞如S2-045, S2-046等。虽然新版本已大幅修复但遗留在互联网上的老旧系统仍是重灾区。// 一个非常简化的、存在问题的Struts2 Action示例概念模型 public class VulnerableAction extends ActionSupport { private String input; // 假设框架底层会这样处理伪代码 // String ognlExpr “‘” userInput “‘ ‘admin”; // 拼接用户输入 // Object result Ognl.getValue(ognlExpr, context, root); // 如果userInput是: ‘) || (#_memberAccess[‘allowStaticMethodAccess’]true) || (‘ // 整个表达式逻辑就被篡改了。 }场景二自定义的动态规则引擎这是目前更常见的场景。比如实现一个动态查询过滤器// 危险代码拼接用户输入构建OGNL表达式 public ListUser filterUsers(String filterExpr) { String ognlExpression “users.?[” filterExpr “]”; // 用户输入被直接拼接 // 假设有一个工具方法执行OGNL ListUser result (ListUser) OgnlUtil.getValue(ognlExpression, context, users); return result; }攻击者可以传入age 18 username.startsWith(‘admin’)这样的正常表达式也可以传入恶意表达式true (#rtjava.lang.RuntimegetRuntime(), #rt.exec(‘rm -rf /’))。场景三灵活的模板渲染有些系统为了支持动态页面会允许管理员配置一些包含OGNL表达式的模板片段。String template “欢迎用户${” userControlledVariable “}”; // 如果userControlledVariable是”username}您的密码是{java.lang.SystemgetProperty(‘user.dir’)} ${dummy” // 渲染时就会执行系统命令。场景四滥用反射和表达式求值工具类有些开发者为了“炫技”或追求极致的灵活性会自己写一个通用的“表达式求值”工具。public Object evaluate(String expression, MapString, Object context) { // 直接使用OGNL或类似引擎如SpEL但此处讨论OGNL解析执行 return Ognl.getValue(expression, context); } // 前端传来”java.lang.RuntimegetRuntime().exec(‘calc.exe’)”这种工具一旦暴露给用户输入就是最直接的命令执行漏洞。核心教训OGNL注入的本质是**“代码注入”**的一种。它与SQL注入、命令注入Command Injection属于同一类问题程序错误地将用户输入的数据当作了代码的一部分来执行。区别在于SQL注入的“代码”是SQL语句命令注入的“代码”是系统Shell命令而OGNL注入的“代码”是OGNL表达式。3. 深入攻击链一次完整的OGNL注入攻击是如何发生的理解了原理我们来看看攻击者具体是如何利用的。一次成功的攻击通常包含以下几个环节。3.1 信息收集寻找表达式注入点攻击者不会盲目测试。他们会先寻找可能使用表达式语言的功能点参数名探测在HTTP请求中尝试修改参数名为可疑的表达式格式如?user.nametest或?(‘test’)123观察响应是否不同。功能点推测关注“高级搜索”、“动态列显示”、“自定义视图”、“规则配置”、“报表生成”等需要灵活配置的功能。错误信息利用故意输入畸形的表达式如{11}或#观察后端返回的错误信息。如果错误信息中包含了“OGNL”、“Expression”、“parse”等关键字几乎可以确认目标。框架特征识别如果应用基于Struts2、某些旧版本的Spring WebFlow或使用特定模板引擎如某些版本的SiteMesh则会成为重点攻击目标。3.2 构造Payload从简单探测到致命攻击攻击Payload的构造是一个循序渐进的过程第一阶段基础探测与上下文确认算术运算11。如果返回2或页面有对应变化证明表达式被执行。字符串拼接’a’’b’。确认字符串操作可用。对象访问#root、#this、#parameters。尝试访问OGNL上下文中的默认对象了解可用的变量。第二阶段尝试突破安全限制沙箱逃逸OGNL引擎通常会有安全沙箱限制危险类的访问和静态方法调用。攻击者需要找到沙箱的弱点。尝试调用静态方法java.lang.Systemexit(1)。如果服务重启或连接断开说明静态方法调用可能被允许这是极度危险的信号。利用黑名单绕过如果直接调用Runtime被禁尝试通过反射链来获取。// 一个经典的Payload构造思路伪OGNL语法 // 1. 获取Class对象 #clazzjava.lang.ClassforName(‘java.lang.Runtime’) // 2. 获取getRuntime方法 #method#clazz.getMethod(‘getRuntime’) // 3. 调用静态方法获取Runtime实例 #rt#method.invoke(null) // 4. 获取exec方法并执行命令 #execMethod#clazz.getMethod(‘exec’, java.lang.ClassforName(‘java.lang.String’)) #execMethod.invoke(#rt, ‘calc.exe’)修改上下文变量在某些框架如旧版Struts2的上下文中存在控制安全的标志位变量如#_memberAccess[‘allowStaticMethodAccess’]。攻击者可能尝试将其设置为true来开启静态方法访问。第三阶段实现远程命令执行RCE这是攻击的最终目的。一旦绕过沙箱攻击者会执行系统命令实现执行系统命令如whoami、ifconfig、ls来探测服务器信息。写入WebShell利用echo或下载命令向Web目录写入一个JSP木马文件获取持久化控制权。内网渗透以被攻陷的服务器为跳板扫描和攻击内网其他机器。数据窃取直接执行数据库导出命令或读取敏感配置文件。3.3 攻击的隐蔽性与危害OGNL注入攻击可以非常隐蔽不出网攻击攻击Payload可以只执行cat /etc/passwd并将结果回显在HTTP响应中例如通过修改某个页面显示的变量值无需反向连接绕过网络层监控。内存马注入高级攻击者可以通过OGNL执行Java代码在JVM内存中动态注册一个Filter或Servlet即“内存马”即使修复了漏洞文件后门依然存在除非重启应用。业务逻辑滥用不一定非要执行命令。攻击者可能利用表达式注入进行越权操作例如将表达式改为#user.id 12345来非法获取他人数据。其危害是最高级别的远程代码执行RCE意味着攻击者可以获得与应用进程相同的权限通常是Tomcat或root用户直接控制服务器。4. 实战防御从代码层面根除OGNL注入风险知道了攻击原理防御就有了方向。核心原则是严格区分代码和数据永远不要将用户输入作为代码的一部分。4.1 第一道防线避免使用动态表达式求值这是最根本、最有效的解决方案。在99%的业务场景下我们都不需要动态执行OGNL表达式。使用类型安全的方式如果需要动态查询使用Criteria APIJPA、Example对象MyBatis Generator或QueryDSL它们都是通过Java代码构建类型安全的查询。使用受限的表达式语言如果场景必须如简单的动态规则使用功能更简单、安全性设计更好的表达式语言如Spring Expression Language (SpEL)并务必将其配置在SimpleEvaluationContext模式下该模式只支持基本的属性访问和方法调用禁止了类型构造、Bean引用等危险操作。// 安全的SpEL使用示例 ExpressionParser parser new SpelExpressionParser(); EvaluationContext context SimpleEvaluationContext.forReadOnlyDataBinding().build(); // 用户输入只能是属性路径如 ‘name’ String userInput “name”; Expression exp parser.parseExpression(userInput); String value exp.getValue(context, userObject, String.class);白名单控制如果业务上确实无法避免使用OGNL必须建立严格的白名单机制。只允许用户从预定义的、安全的操作符和属性中选择。// 一个简单的白名单示例实际需要更复杂 private static final SetString ALLOWED_PROPERTIES Set.of(“name”, “age”, “dept.name”); private static final SetString ALLOWED_OPERATORS Set.of(“”, “”, ““, “and”, “or”); public boolean isSafeExpression(String userExpr) { // 1. 解析表达式语法树 // 2. 遍历语法树节点检查所有涉及的属性名、方法名是否在白名单内 // 3. 拒绝任何不在白名单内的节点 // 这是一个复杂的过程建议使用成熟的库或直接避免。 }4.2 第二道防线如果必须用安全地使用OGNL如果因为历史遗留代码或特殊框架如维护Struts2应用必须使用OGNL请采取以下加固措施升级到最新安全版本无论是Struts2还是独立的OGNL库务必使用官方发布的最新版本旧版本中已知的安全限制绕过漏洞可能已被修复。配置OGNL的安全防护OGNL提供了OgnlContext和SecurityMemberAccess类来配置安全策略。import ognl.*; public class SecureOgnlUtil { private static final OgnlContext SECURE_CONTEXT; static { SECURE_CONTEXT (OgnlContext) Ognl.createDefaultContext(null); // 关键设置MemberAccess禁止访问危险类和成员 MemberAccess memberAccess new DefaultMemberAccess(false); // false表示禁止访问private/protected/package-private成员 // 或者使用更严格的SecurityMemberAccess如果OGNL版本支持 // 可以设置黑名单/白名单类 SECURE_CONTEXT.setMemberAccess(memberAccess); // 禁用静态方法访问至关重要 SECURE_CONTEXT.put(OgnlContext.ALLOW_STATIC_METHOD_ACCESS, false); } public static Object getValueSafely(String expr, Object root) throws OgnlException { // 仍然需要对expr本身进行白名单校验因为即使限制了MemberAccess // 像 #context[‘com.opensymphony.xwork2.ActionContext.container’] 这样的上下文访问可能依然存在风险。 return Ognl.getValue(expr, SECURE_CONTEXT, root); } }注意仅靠配置OGNL上下文并不绝对安全历史上Struts2的很多漏洞正是由于这些安全开关如allowStaticMethodAccess被攻击者通过精心构造的表达式重新打开。因此必须与输入白名单结合使用。严格的输入验证与过滤对用户输入的表达式字符串进行严格的校验。语法检查使用OGNL的Ognl.parseExpression()先进行解析如果解析失败则拒绝。关键词黑名单过滤掉静态方法调用、new构造对象、#上下文变量访问、(、)方法调用等高危字符。但黑名单容易被绕过如使用Unicode编码、双写等。语义白名单推荐如前所述构建允许的属性名和操作符白名单。这是最安全但实现最复杂的方式。4.3 第三道防线架构与运维层面的加固最小权限原则运行Java应用的服务器账户如tomcat用户应遵循最小权限原则禁止其执行高危系统命令、写入关键目录。部署WAF在应用前端部署Web应用防火墙WAF可以配置规则拦截常见的OGNL注入攻击特征如#_memberAccess、java.lang等。定期安全扫描与代码审计将表达式注入CWE-917作为代码安全扫描和人工审计的重点项。使用SAST静态应用安全测试工具扫描源代码使用DAST动态应用安全测试工具对线上应用进行漏洞扫描。依赖库安全管理使用Maven或Gradle的依赖检查工具如 OWASP Dependency-Check确保项目使用的Struts2、OGNL等库没有已知的高危漏洞版本。5. 排查与应急当怀疑存在表达式注入时该怎么办如果你在日志中发现了可疑的请求或者安全扫描给出了告警可以按照以下步骤进行排查和应急。5.1 第一步紧急止血隔离攻击入口立即通过WAF、网关或负载均衡器对疑似存在漏洞的URL路径或参数特征添加临时拦截规则。下线或熔断有风险的功能如果可能直接在应用层面暂时关闭涉及动态表达式求值的功能模块。排查后门检查服务器上是否有新增的陌生文件特别是Web目录下的.jsp,.jspx文件检查是否有可疑的进程或网络连接。可以使用rpm -VaLinux检查系统文件是否被篡改。5.2 第二步漏洞定位与分析日志分析集中分析应用日志、访问日志找到攻击请求的原始Payload。重点关注请求参数中包含#,,new,Runtime,ProcessBuilder,getClass,forName等关键词的请求。代码回溯根据攻击请求的URL和参数定位到后端处理的Controller、Service或工具类。全局搜索代码中以下关键词Ognl.getValueOgnl.parseExpressionExpressionParser(可能是SpEL但也需检查)eval(避免使用ScriptEngine执行用户输入)execute(某些规则引擎)拼接字符串并使用某种Evaluation方法的代码模式。动态调试在测试环境复现攻击请求通过调试器跟踪用户输入是如何被拼接和执行的确认漏洞点。5.3 第三步修复与验证制定修复方案根据第4部分的防御策略选择最适合的修复方式。优先选择“避免使用”改为静态实现。如果不行则实施“白名单安全配置”。在测试环境充分验证功能验证确保修复后的功能正常。安全验证构造大量的恶意Payload包括各种绕过技巧进行测试确保都被有效拦截。回归测试确保修复没有影响其他相关功能。修复上线与监控将修复后的代码上线并密切监控相关接口的日志和系统指标确认攻击已停止。5.4 第四步复盘与加固根本原因分析为什么会出现这段漏洞代码是开发人员安全意识不足还是框架使用不当是否有设计缺陷完善开发规范将“禁止将用户输入直接用于表达式求值”写入团队安全开发规范。加强安全培训对团队成员进行专项培训讲解表达式注入的原理和危害。引入安全工具在CI/CD流水线中集成SAST工具将此类漏洞在代码提交阶段就拦截下来。6. 举一反三其他Java表达式语言的潜在风险OGNL并非孤例Java生态中其他表达式语言也存在类似风险原理相通防御策略也类似。Spring Expression Language (SpEL)Spring框架广泛使用的表达式语言。默认的StandardEvaluationContext功能强大且危险等同于OGNL。必须使用SimpleEvaluationContext来限制功能。漏洞代码示例SpelExpressionParser().parseExpression(userInput).getValue()其中userInput可控。MVEL (MVFLEX Expression Language)另一个功能强大的表达式语言常用于Drools规则引擎等。同样直接执行用户输入的MVEL表达式会导致RCE。JEXL (Java Expression Language)Apache Commons JEXL设计初衷是比OGNL更轻量安全但不当使用如允许访问ClassLoader同样存在风险。EL (Unified Expression Language)JSP和JSF使用的表达式语言。在旧版本如JSP 2.1之前或错误配置下也可能存在方法调用风险。现代版本默认限制较强。通用防御心法对待任何允许执行字符串形式代码的引擎包括数据库的存储过程、操作系统的Shell、模板引擎的宏都要秉持“不信任任何用户输入”的第一原则。要么完全避免动态生成要么在沙箱中执行并施加最严格的限制。7. 写在最后安全是一种习惯回顾开头的线上故障根本原因不是OGNL这个工具本身而是开发者对“灵活性”的过度追求牺牲了安全性。在当今的软件开发中我们享受着各种强大框架和语言特性带来的便利但能力越大责任也越大。我个人的体会是处理用户输入时心里必须绷紧一根弦它永远是数据不是代码。任何试图将数据“活化”为代码的操作无论是拼接SQL、拼接命令、拼接OGNL/SpEL还是反序列化都需要经过最严格的安全审查。在代码评审时看到操作符拼接字符串并传入某个eval()方法就应该立刻亮起红灯。对于Java开发者而言了解OGNL注入这类漏洞不仅仅是应付面试八股文更是构建健壮、可靠应用的基本功。下次当你想要实现一个“酷炫”的动态功能时不妨先停下来想一想是否有更安全、更简单的静态实现方式如果非动态不可我的安全边界划在哪里白名单是否足够严格多问自己这几个问题或许就能避免一次深夜的紧急故障。安全没有银弹它体现在每一个设计决策和每一行代码的细节之中。