Struts框架开发安全特性

  • A+
所属分类:lcx

此文是我前年研究struts框架相关安全特性做的总结,这里发上来,各位安全工作人员在查找Struts相关应用的漏洞有一定用处,但因为是去年的文档,因此可能有一些过时内容,大家在参考时需要注意。另外由于这篇文章主要是用来做总结,因此也没有多少例子,具体案例大家可以关注乌云主站一一对应。

Author: wofeiwo#80sec.com

Date: 2011-06-14

前言

Struts是目前J2ee Web开发中最常见使用的MVC框架。由于使用框架编写的应用程序与原生jsp编写的Web程序区别较大,因此有必要专门撰写一篇文档描述Struts框架的安全特性,及其检查方法。

Struts介绍

Struts是一套MVC框架,目前分为两个大版本号。1.x系列,已经放弃开发,是一个较为简单的框架,安全特性也较少。2.x系列则是直接与webwork这个框架合并之后基于webwork重新开发的一套全新框架。目前主流使用框架基本就是2.x系列。

Struts1

Struts框架开发安全特性

图 2.1 struts1架构图

如上图所示,struts 1.x系列的模型主要分为几个部分:最主要的Dispatcher、Controller是使用J2ee的servlet实现的,用户请求过来,通过用户自定义的一系列过滤器(filter)之后,servlet分析匹配其url结构,再转给各action类,最后进行form的填充控制、View层的调用展现。其主要代码是在action中实现的,可以根据struts-config.xml中的配置,根据url->action->view的对应关系一一查看其代码。Struts1中的统一控制一般做在filter中,或者由form的校验函数做数据有效性控制。

Struts2

Struts框架开发安全特性

图 2.2 struts2架构图

而struts2.x的架构就复杂很多,也细致的多。用户的请求过来,先经过一系列过滤器(Filter实现),最后一个过滤器通过actionProxy才是真正对不同的action派发调用,其中的派发规则由struts.xml定义。这几部分相加,才类似于之前Struts1中的ActionServlet的作用。在调用action之前,还有类似Hook的机制,在action执行前后、view执行前后分别有可以统一执行的用户自定义代码。在struts2的说法中,叫做拦截器(Interceptor)。通常struts2中的统一控制就在过滤器、拦截器、校验器这几个方面做控制,其中后两者最普遍。

如何区分Struts框架应用程序

URL中以.do结尾的,struts1框架;以.action结尾的,struts2框架。

Struts1由于是通过servlet进行的action控制,因此主要配置文件在WEB-INF/web.xml及struts-config.xml这两个文件中;Struts2的配置文件则主要就是WEB-INF/struts.xml。

目录组织结构中如果有Filter、Interceptor的定义实现,通常是Struts2的代码。

如果有专门的xxxForm.java代码,一般是Struts1的项目;Struts2通常只有一些简单的Java Bean定义作为模型。

Struts框架安全特性

Struts1的白盒安全测试方法

之前我们说过,Struts1中的统一控制一般做在filter中,或者由form的校验函数做数据有效性控制。因此,无论是哪一方面的统一控制,例如参数的统一过滤、验证是否登录、文件上传验证之类,通常是在Filter中进行的;而参数的有效性,例如email只允许[[email protected]]。

建议在读代码时,先通读web.xml和struts-config.xml两个文件,从web.xml中了解filter的设置,将所有filter通读一遍,了解总体上做了什么限制,再从struts-config.xml了解action与actionForm、View的对应关系,然后根据这些关系,检查form中的参数有效性验证方法(validate函数)是否做了足够的检查,以及view中是否有基本的html过滤。具体测试case这里不多言,只要找对地方,java的测试case和其他语言也基本都差不多。

Struts1安全特性

参数获取

通常使用J2ee中最常见的Request.getParamter()方法获取用户输入。此方法结合了GET/POST中提交的变量,如果两者有重名,则GET获取的优先,获取的内容非常原始,没有任何改变。不同于PHP中的$_REQUEST变量,Request.getParamter方法并没有包含cookie中获取的变量。

actionForm中获取的变量也是框架通过上述方法获取的,因此虽然看起来是直接使用没有通过函数获取,实际上也是一样。

文件操作

文件下载在struts中并没有做任何限制。在文件上传中,一般是使用Apache-Common-FileUpload的组件。其中也未替代用户做任何限制和检查,需要手工实现扩展名判断、验证等代码。因此如果action中的逻辑代码没有做任何检查,基本可以判断存在问题。

前端防范

一般Struts1使用jsp作为默认的前端引擎,常见的过滤方式与jsp相同,不做赘述。

CSRF防范

Struts1提供了一个生成并验证Token的api(isTokenVaild),在检查是否防范了CSRF的时候,可以查看应用程序是否使用了这个API(也可以查看提交的请求包中是否包含org.apache.struts.taglib.html.TOKEN这个变量)。如果未使用,就可以检查是否在Filter之类的地方做了统一的自己实现的CSRF token验证防范。

Struts1提供的Token值是存储在SESSION中的,因此这里就存在一个bug。由于Token在session中保存的变量名不变,因此如果一个用户打开了多个窗口,只有最后一个窗口设置的token值有效。这里需要多加注意。

其他

此外,Struts1有个特性:一个Action类在程序周期中只有一个实例,常驻内存。因此,在这个类中的属性和变量是共享的,不同用户访问的不同请求都是如此。因此如果程序中的逻辑依靠Action内部变量传送敏感信息,则其他用户也可能改写、读取。

Struts2的白盒安全测试方法

Struts2的安全测试主要方法论与S1一致,也多是通过查看struts.xml和web.xml中的配置,了解url->action->view的关系,以及不同url中涉及到的过滤器、拦截器、验证器(一般在validation.xml和className-validation.xml中配置)的关系。了解了这些,在头脑中有一个清晰的数据流脉络,然后再检查这些控制措施是否做到位,是否有疏漏即可。一般来说,S2的控制大都在拦截器和验证器中进行,常见的有是否登录、文件上传格式检查、参数有效性检查等。S2默认提供了很多拦截器,做了以上功能,这些在下面的安全特性中会提及。

Struts2的安全特性

参数获取

与S1不同,S2中的参数获取虽然也可以通过Request.getParamter()方法,但是很少使用。因为action类中定义过getter/setter方法的变量,如果用户在请求中提交了同名的变量,框架会自动将其值注入到action实例中的对应变量中去,并且会做响应的类型转换。这一切是通过defaultStack中默认的Param拦截器实现的,利用拦截器,在action执行前,将用户传入的数值使用Request.getParamter()获取后并经过解析自动注入。

这一点请一定注意。因为如果action中的内部成员变量之前有一个默认值,一旦用户提交了同名变量,就可以覆盖此值。这样就会直接导致后续依赖此默认值的逻辑发生重大变化。

文件操作

下载文件没有限制,需要自行编写代码控制。

上传文件,S2默认有一个FileUploadInterceptor的拦截器,提供了三种限制方法,都在struts.xml中配置:

allowedTypes(允许文件的mime-type值,可伪造)

maxmumSize(允许文件最大的字节数)

allowedExtensions(允许文件的扩展名)

由于早期S2框架文档的误导,提供的例子程序中只限制了allowedTypes,因此导致多数s2应用程序存在修改http包修改mime-type导致任意上传漏洞。因此在做安全测试的时候,一定要检查是否设置了allowedExtensions作为白名单,而不单单是allowedTypes。另外即使做了扩展名限制,请注意这个可能还存在多扩展名文件的问题。

如果上传没有使用默认的FileUploadInterceptor,请检查程序逻辑中是否对文件上传做了严格的限定。

CSRF防范

S2中也提供了防范重复提交的Token机制。与S1不同的是此次他是使用TokenInterceptor这个拦截器的方式,在action执行前统一进行验证。Token值也是保存在session中,因此同样存在S1框架中Token的bug。

此外,这个Token机制还有个可以被绕过的0day漏洞:由于TokenInterceptor在验证用户提交上来的请求时,先从用户请求中的struts.token.name值作为session中的key,然后比对用户请求中提交的token值是否与session中key对应的值相匹配,如匹配则通过。但是,如果攻击者预先知晓session中已保存的一个值,例如username=admin,则攻击者可以直接将csrf包中的struts.token.name设置为username,然后token值设置为admin,即可轻易绕过csrf token防范。

因此,如果经检查的应用中使用了默认的token拦截器,请提醒开发人员弥补以上不足。如自行实现防重复提交的代码,请仔细检查其逻辑的严密性。

动态方法调用

Struts2中存在一个特性,叫做动态方法调用。当你请求actionName!methodName.action这样的URL时,框架不会调用action中的默认入口execute(),而是会寻找action中名叫methodName的方法,并直接调用。通过这种方式,可能暴露action类中未经过验证的内部接口,也可能绕过一些权限验证。

因此,在测试过程中,如果程序本身没有使用到这个特性,请建议RD在struts.xml中设置一个constant将struts.enable.DynamicMethodInvocation属性设置为false,禁止此特性。

前端模板

S2自带的taglib中的变量输入都经过了自动html转义。一般无问题。但是请注意参数名前带感叹号,则表示没有转义。安全检测时请务必注意。

如果使用其他模板引擎,请根据其他引擎的过滤规则进行检查。

其他

与s1不同,s2中每一个请求对应一个不同的action实例,没有action实例中变量共享的问题。

S2的action中execute方法,根据方法返回的值来决定最后调用哪一个view模板。因此,结合动态方法调用和自动变量注入的特性,如请求actionName!getUsername.action?username=pass。而action中对应“pass”这个返回结果的view又是个包含敏感信息的模板,就可能产生问题。因此在安全测试的过程中需要特别注意。

摘自:http://zone.wooyun.org/content/2412

文章来源于lcx.cc:Struts框架开发安全特性

相关推荐: 日智能马桶用户或遭黑客恶作剧

据中国日报报道 日本推出了一款名叫“萨蒂斯”的智能马桶,用户可以通过安卓系统智能手机上的一款免费软件对其进行遥控,它的多样化功能给用户带来了便利。然而,IT安全公司Trustwave近日警告说,该智能马桶的用户面临着隐患,黑客可以利用其安全漏洞进行恶作剧。 据…

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: