在OGNL表达式中执行加法运算看似简单，但其行为细节和潜在风险常被开发者忽视。正确理解其类型处理机制和边界情况，对于编写安全、稳定的表达式至关重要。特别是在模板渲染或配置注入场景下，一个不经意的加法操作可能导致意料之外的类型转换或代码执行漏洞。
OGNL加法运算如何处理不同类型的数据
OGNL在遇到加法运算符时，会尝试进行自动类型转换。如果操作数都是数字，则进行数学加法。但如果其中一方是字符串，OGNL会将其视为字符串连接。更需警惕的是，当操作数是其他对象时，OGNL可能会调用该对象的toString方法，甚至可能触发某些属性的Getter方法。例如，表达式"id:" + user.id在实际解析时，会先获取user对象的id属性值，再与字符串拼接。
为什么OGNL加法可能导致安全漏洞
问题的核心在于OGNL的动态特性和强大的反射能力。加法操作并不“安全”，它可能是复杂表达式求值链的起点。在某些框架的旧版本中，攻击者可以构造如'${}' + (#_memberAccess['allowStaticMethodAccess']=true)这类表达式，通过加法串联恶意代码，绕过安全沙箱，最终实现静态方法调用和命令执行。加法在这里成了绕过语法限制或黑名单检测的跳板。
在实际开发中如何安全地使用OGNL加法
应严格避免将不受信任的用户输入直接作为OGNL表达式的一部分进行解析。其次，如果业务必须使用，应确保在沙箱环境或严格受限的安全上下文中进行，明确禁用危险的上下文变量和标志位。最后，考虑使用更简单的表达式语言或模板引擎替代OGNL，从根本上降低风险。对于仅需数字计算或字符串拼接的场景，应优先在Java代码层完成，再将结果传递给表达式。
你在项目中有没有遇到过因OGNL表达式处理不当而引发的实际问题？你是如何发现和解决的？欢迎在评论区分享你的经验，如果觉得本文有警示作用，请点赞支持。
