基于RASP技术的Java Web框架漏洞通用检测与定位方案

A General Detection and Location Scheme for Java Web Framework Vulnerability Based on RASP Technology

摘要

针对当前工业界主流的Web应用保护方案难以检测未知漏洞且无法定位漏洞攻击细节的问题，分析主流Web框架和组件上的4类典型漏洞攻击流程，总结4类漏洞通用利用模式，进而利用运行时应用自我保护（runtime application self-protection，RASP）技术，在Web程序内部获取运行时信息并进行漏洞攻击行为检测和多层次的信息记录，提出了基于RASP技术的Java Web框架漏洞通用检测与定位方案。实验结果表明，该检测方案可检测出全部攻击测试样本，并可定位漏洞攻击细节在Web应用程序中的位置，定位准确率达88.2%，且该方案性能消耗小。

Abstract

Aiming to solve the problem that it is hard for the mainstream Web application protection schemes in the industry to detect unknown vulnerabilities and locate the details of vulnerability attacks, we firstly analyze four types of typical vulnerability attacking processes on the mainstream Web frameworks and components, then extract four types of vulnerability general exploitation patterns. Next, by RASP (runtime application self-protection) technology, we obtain the runtime information inside the Web application and perform the vulnerability attack behavior detection as well as the multi-level information recording. Finally, we propose a general detection and location scheme for Java Web framework vulnerability based on RASP technology. The experimental results show that the detection scheme can detect all attack test samples, locate the details of the vulnerability attack inside the Web application with accuracy rate of 88.2% and has low performance consumption.

Graphical abstract

关键词

运行时应用自我保护 / 漏洞定位 / 攻击检测 / Java Web

Key words

runtime application self-protection （RASP） / vulnerability location / attack detection / Java Web

0　 引 言

成熟的Web开源框架（如Struts2、SpringMVC等）被广泛应用于Java Web程序中，但同时频繁被爆出存在RCE（remote code execution，远程代码执行）、Java反序列化类漏洞等各类安全漏洞^[1]。工业界广泛采用Web应用防火墙（Web application firewall，WAF）进行检测，通过判断网络流量中是否携带攻击特征来识别和拦截可疑请求^[2]，但其不足之处在于：1） WAF无法获取程序内部状态信息，检测特征在网络流量层面，误报率较高；2） 依赖安全人员特征提取水平，难以应对多种绕过方式；3） 需事先提取攻击流量特征，难以实现未知漏洞的预先防护。

针对上述不足，本文基于运行时应用自我保护技术（runtime application self-protection，RASP）^[3]，提出一种Java Web框架漏洞通用检测与定位方案。该方案可实现对应用程序代码的非侵入式保护，获取程序内部的运行时信息，并对Web程序内部的攻击操作进行精准识别和拦截，能有效检测漏洞攻击并快速定位攻击细节。其特点在于：1）基于RASP技术，在应用程序4个层次上部署检测点，实现程序内部上下文信息的实时获取，可有效解码真实Payload，减少由于WAF规则的不完善导致的漏报和误报；2）构建4类漏洞的通用利用模式集合，基于此实现漏洞识别与攻击细节定位。由于漏洞通用利用模式集合是在对一定数量的同类样本的分析基础上形成，抽象程度高，并且特征来源于程序内部，检测效果较好，因此可在一定程度上降低人工提取的不稳定性对特征的检测效果的影响，确保检测的有效性；3）由于同类漏洞攻击在利用模式上存在相似性，有相似或相同的攻击特征，因此理论上使用漏洞通用利用模式集合进行攻击检测，对同类别的未知漏洞有一定程度的防御效果。

1　 相关研究

在学术界，许多研究者通过对框架及系统源码进行静态分析，检测和挖掘Java Web程序中潜在的漏洞。例如Kong 等^[4]将静态分析中的Java Web应用程序逻辑漏洞检测问题转化为从一组相似切片中挖掘具有异常路径条件的切片任务，实现了一个轻量级逻辑漏洞原型检测工具LVD。Livshits等^[5]通过自定义漏洞识别规则，配合Java字节码级别的静态分析，提出了基于可扩展和精确点对点分析的漏洞检测方法。

在动态分析及运行时解决方案方面，Čisar 等^[6]从多方面对比评估了传统WAF防护方案与RASP技术，证明RASP技术与现有防护方法的结合在安全防护方面具有极大优势。Livshits等^[7]提出了漏洞攻击检测的运行时解决方案SecuriFly，证实使用静态分析辅助的方式优化运行时监控点，可以大幅降低运行时检测程序所造成的性能消耗。Steiner等^[8]使用形式概念分析（formal concept analysis，FCA）方法对10种SQL（structured query language，结构化查询语言）注入的运行时漏洞缓解方案进行了评估分析，但未发现有方案能成功过渡到企业使用。Huang 等^[9]使用黑盒测试、行为监控等软件工程测试技术，构建了Web应用程序的安全评估工具WAVES。Pieczul等^[10]使用类似RASP技术的运行时检测技术挖掘0Day漏洞， 但该检测定义监控范围和抽象等级时涉及的数据量大，部署操作复杂。Parameshwaran等^[11]实现了一个名为DexterJS的DOM-XSS漏洞检测平台，通过对源码重写实现字节级的动态污点跟踪，获取和验证Web页面漏洞的潜在数据流。Wang等^[12]提出了一个DOM-XSS的动态检测框架TT-XSS，修改所有JavaScript特性和相关API（application programming interface，应用程序接口）实现客户端污染。通过在客户端解析页面进行污点跟踪，推导攻击向量，实现自动化漏洞检测。但文献[11]和[12]所述的2种方法均为侵入式的检测方式，需对目标程序进行一定程度的重写，在实现上不够轻量级，并且对目标程序代码的理解程度有较高要求。

自RASP技术的概念^[3]，即“对应用服务的保护，不应该依赖于外部系统，应用应该具备自我保护的能力”被提出后，国内外出现了许多应用RASP技术的产品，其中百度开源的OpenRASP是使用较为广泛的商业化产品之一。百度公司在2017年7月份发布了OpenRASP，将该安全技术产品化，目前支持 Java 和 PHP 两种开发语言。OpenRASP底层使用Java Premain方式对Java应用程序进行Hook操作，通过漏洞识别规则进行攻击判定。它使用了Java结合JavaScript的编码方法，在保证用户可自定义配置规则的同时，降低了RASP技术的消耗性能。

2017年，彭国军团队^[13]通过分析Struts2框架的内部架构及历史RCE类漏洞机理，设计并实现了对Struts2应用源码层、OGNL语言层及 Java虚拟机系统层的三层监测机制，进而构建了一种针对Struts2框架RCE类漏洞的通用检测与漏洞细节快速回溯方案，可从一定程度上缓解Struts2框架的RCE类未知漏洞攻击难以检测和漏洞细节难以快速定位的问题。但该方案尚存在一些缺陷：1） 检测适用范围窄，仅针对Struts2框架的RCE类漏洞进行检测；2） 实现方式复杂且后期修改成本高，为了实现或调整检测方案，安全人员需要熟悉Struts2框架以及OpenJDK的内部架构，进而对二者的源码进行修改和重新编译，因此该方案的可拓展性较差。

本文方案基于RASP技术实现Java Web框架漏洞通用检测与定位，并使用Java的Instrumentation类^[14]和AOP（aspect oriented programming，面向切面编程）技术^[15]实现了方案原型。

2　 本文方案

本节将介绍基于RASP技术的Java Web框架漏洞检测与定位方案的设计思路，包括方案设计前期如何进行样本分析、分析结果如何指导框架中模块的具体设计、如何在方案中应用RASP技术思想，以及方案中各个模块的功能。

2.1　Java Web框架漏洞通用利用模式分析

Web漏洞攻击过程中，攻击者通过HTTP协议向Web应用程序发送Payload，虽然每次发送的Payload具体的执行路径存在差异，但最终达到的攻击操作相似，如：执行系统命令、读写文件和访问数据库等^[16]。进一步分析各个典型的漏洞攻击流程，可发现在受害应用程序内部，同类别的漏洞攻击流程存在相似的执行路径，这也是我们设计漏洞通用检测与定位方案的基础。

本文选取Spring^[17]、Struts2^[18]和Tomcat^[19]等Java Web框架的历史RCE类漏洞、反序列化类漏洞、SQL注入类漏洞、服务器配置不当类漏洞等4类常见漏洞，分别总结了每类漏洞的通用利用模式，作为设计本文漏洞检测和细节定位方案的基础。出于篇幅限制，本节仅以RCE类漏洞和反序列化类漏洞为例，描述、分析漏洞攻击流程并总结通用利用模式。

1） RCE类漏洞分析及通用利用模式总结

本文主要对Spring和Struts2框架进行RCE类漏洞攻击检测。用于分析和总结利用模式的样本共7个，分别是Struts2框架的3个历史RCE类漏洞（S2-016、S2-020、S2-045）和Spring框架的4个历史RCE类漏洞（CVE-2018-1260、CVE-2018-1270、CVE-2017-8046、CVE-2016-4977）。

下文以CVE-2016-4977为例，说明如何进行样本分析并总结利用模式。

CVE-2016-4977是2016年Spring Security OAuth （即Spring安全开放授权）模块爆出的一个RCE类漏洞。该漏洞通过Spring Boot组件启动，利用Spring底层模块的SpEL语言达到命令执行的效果。对漏洞相关的框架源码进行分析，总结得到该漏洞的攻击流程如图1所示。图1中，用户向Web应用程序中输入URL（uniform resource locator，统一资源定位符），该URL中包含的ResponseType参数是用户可控的。随后Web应用程序将通过Spring框架的DispatcherServlet模块判断ResponseType参数是否合法。如果合法，则程序将执行后续正常处理URL的逻辑；如果该参数中包含恶意Payload，则DispatcherServlet模块将判定其非法，并抛出包含该URL的异常信息。Spring框架中相应的业务逻辑函数接收异常信息，并在Spring框架底层使用SpEL语言对传入的ResponseType参数进行解析。由于SpEL语言功能强大，且Web应用程序运行在Java虚拟机之上，因此解析过程将最终导致攻击者能够通过SpEL语言间接调用Java API，完成非法命令执行和文件读写等操作。该漏洞的实质在于应用程序使用SpEL语言对缺少过滤的错误信息进行解析执行。

结合对Spring框架其他RCE类漏洞攻击流程的分析，对该类RCE类漏洞的特征总结如下：

① 执行流程最终都会到达SpEL语言执行处；

② 通过SpEL语言调用Java API 完成非法命令执行、文件读写等操作；

③ 从URL输入到攻击者成功执行命令的整个路径中，受害应用程序均未对漏洞（如Spring框架上的3个RCE类漏洞：CVE-2018-1270、CVE-2017-8046、CVE-2016-4977）设置有效的参数值过滤机制。

本文总结的Spring系列框架RCE类漏洞通用利用模式如图2所示。由图2可知，首先,攻击者精心构造含有攻击数据的URL及其参数作为输入请求数据;然后，Spring框架的DispatcherServlet模块接收请求，并将其传递给Controller模块；接着，Controller模块将处理业务逻辑，发现输入数据存在业务逻辑错误；最后，Spring框架对发现的错误进行处理，使用SpEL表达式语言解析错误信息。由于被解析的信息中包含攻击者可控的输入数据，因此解析过程将导致攻击者能够调用SpEL语言，成功完成执行系统命令等操作。

与Spring系列框架上的RCE类漏洞相似，Struts2系列框架上的RCE类漏洞实质也在于对用户输入的错误信息缺乏有效的过滤机制，并在框架底层使用了功能强大的OGNL表达式语言对错误信息进行解析，导致攻击者可间接调用Java API完成攻击。

2） 反序列化类漏洞分析及通用利用模式总结

反序列化机制被广泛应用在HTTP Requests、RMI、JMX等Java Web应用程序中，存在严重安全隐患^[20,21]。反序列化漏洞利用攻击需要2个要素：① 被攻击的Java应用中使用了有反序列化操作的HTTP接口；② 存在可构造命令执行利用调用链的类文件。

通过对Shiro^[22]、Jenkins^[23]等流行框架上的多个反序列化类漏洞利用过程进行分析和提炼，本文总结了反序列化类漏洞的通用利用模式（如图3）。反序列化机制常见于HTTP和Socket通信，如图3所示，攻击者一旦根据标识头等信息发现反序列化数据所在位置，将立即尝试寻找第三方危险库，随后使用ysoserial等工具构建攻击载荷，产生恶意的序列化数据，最终调用JDK底层API实现执行系统命令和读写文件等操作。

现有防御反序列化类漏洞的方案主要有2种：一种方案是在使用readObject函数反序列化数据时，利用黑白名单检查和拦截被调用的类，但此种方案存在被绕过的可能性^[20,21]；另一种方案是及时更新存在风险的库，但该方案难以应对层出不穷的新风险库^[20,21]。采用RASP技术结合已有的漏洞规则，对目标程序中多个层次的信息进行监控，可在危险类和库名称列表之外，补充对漏洞利用过程中网络通信、序列化数据传输、执行系统命令等环节的检测。即使类和风险库的检测环节被绕过，其他利用环节上的信息也可在一定程度上提示反序列化类漏洞利用可能存在，以便及时拦截和防御攻击。因此本文方案可在一定程度上弥补现有的两种反序列化类漏洞防御方式的不足。

2.2　方案设计

本文在总结Java Web主流框架4类漏洞的通用利用模式的基础上，设计了方案的整体框架（如图4）。如图4所示，该框架共有3个功能模块，分别是RASP上下文信息搜集模块、漏洞判定模块和漏洞告警模块。

其中，RASP上下文信息搜集模块将RASP探针植入到应用程序的4个关键层次（Java Web应用服务器层、应用程序框架源码层、表达式语言层、JDK底层行为监控层），获取敏感函数参数信息。通过Web访问所依赖的线程副本（ThreadLocal），可完整记录访问线程经过的函数流程。上下文信息被收集后，漏洞判定模块基于漏洞通用利用模式，对收集到的信息进行综合识别，判定是否出现漏洞攻击，随后将判定结果发送给漏洞告警模块。若判定出现漏洞攻击，漏洞告警模块将存储对应线程的上下文信息，返回自定义安全警告视图，并将相关信息报告给安全工程师。漏洞告警模块存储和返回给安全工程师的信息包含漏洞利用涉及的关键函数名、参数以及函数调用栈等漏洞细节，可帮助分析人员迅速定位漏洞利用在程序内部的具体位置。

本文方案原型采用AOP技术^[15]和Java的Instrumentation类^[14]进行实现。利用AOP技术，通过预编译方式和运行期动态代理的编程方式，能够在不修改程序源代码的情况下为目标程序的各个模块统一添加功能;使用Java的Instrumentation类，可实现对目标程序的运行期动态代理功能。

3　 框架模块分析

本节将详细介绍本文方案框架中的各个模块。

3.1　RASP上下文信息搜集模块

RASP上下文信息搜集模块以一种非侵入式的方式拦截目标程序内部运行时信息，其拦截行为主要在目标程序的以下4个层次进行：

1） Java Web应用服务器层：拦截解析完HTTP协议请求的Request对象，其中包含URL、参数及上传数据等信息；

2） 应用程序框架源码层：在Struts2、Spring-Web和Mybatis等框架源码中，拦截与漏洞利用相关的运行时函数信息，如函数参数、函数返回值、函数调用栈等；

3） 表达式语言层： 在OGNL、SpEL等表达式语言层，拦截与漏洞利用相关的运行时函数信息；

4） JDK底层行为监控层：拦截与读写文件、执行命令和查询数据库等行为相关的运行时函数信息。

RASP上下文信息搜集模块根据漏洞通用利用模式确定应用程序内部需要拦截相关信息的函数并使用阿里公司开源的JVM-Sandbox项目^[24]在这些函数中设置RASP探针，提取各个层次的关键上下文信息。

目前在Java平台可通过JVM重构和使用Java Instrumentation类两种方式实现RASP技术^[25]。RASP上下文信息搜集模块使用的JVM-Sandbox项目属于JVM重构，下文的漏洞判定模块和漏洞告警模块使用Java Instrumentation类。Java Instrumentation类可动态替换和修改类的功能，能够修改Java任意函数的字节码，因此便于在漏洞判定模块和漏洞告警模块中实现日志记录攻击细节、实时拦截程序内部的攻击行为等功能。

3.2　漏洞判定模块

通过2.1节对漏洞样本攻击流程进行分析，总结得到该类漏洞的通用利用模式。该模式符合相应类别的大多数漏洞的攻击原理，并且可用于该类漏洞攻击的识别，这是漏洞判定模块进行漏洞检测的前提。该模块接收RASP上下文信息搜集模块传递的目标程序内部状态信息，在检测算法中根据利用模式对接收的各层次信息进行特征识别匹配。假如部分关键特征或全部特征吻合，则判断程序内部出现漏洞攻击。假如依靠部分关键特征的检测结果识别出了漏洞攻击，但该攻击的其余特征不在2.1节分析得到的漏洞利用模式中，比如漏洞攻击的入口点不在历史漏洞列表中，则在历史漏洞信息列表较为完备的前提下，可推测该攻击为0Day漏洞。

漏洞判定模块能够实时判定漏洞攻击行为，识别4类具体漏洞攻击类型并给出判定理由。根据前文4种漏洞类型在系统多个层次中的特征，本文方案设计了4类对应的漏洞匹配识别算法，分别是：

1） 框架RCE类漏洞检测算法；

2） 反序列化类漏洞检测算法；

3） SQL注入类漏洞检测算法；

4） 服务器配置不当类漏洞检测算法。

为方便表述，下文分别用A、B、C、D表示Java Web应用服务器层、应用程序框架源码层、表达式语言层和JDK底层行为监控层。

3.2.1　框架RCE类漏洞检测算法

Web框架的RCE类漏洞大都依附于表达式语言存在，在B、C、D层中均有特征体现，因此检测算法结合B、C、D层上的拦截信息判断攻击行为是否存在。结合D层相关远程代码执行行为的拦截信息，可判断出漏洞是否已被成功利用；结合B层拦截信息，可比对历史漏洞的入口点，判断其是否为已知攻击方法，攻击入口点未被记录则可判定为疑似0Day级别漏洞攻击；结合C层的表达式语言拦截信息也可判定是否出现漏洞攻击，例如：表达式语言中出现“java.lang.Runtime”、“java.io.File”等敏感字符串时，可判定出现漏洞攻击。具体的框架RCE类漏洞检测算法描述如算法1所示。

3.2.2　反序列化类漏洞检测算法

反序列化类漏洞的攻击特征在A层和D层较为显著。A层特征为数据中存在“Magic Bytes”标识头“ACED0005”，D层特征表现为命令执行操作。此外，还存在2个特征：1）使用了ObjectInputStream类的resolveClass函数反序列化相关类；2）使用第三方库进行漏洞利用。

基于A层和D层的反序列化类漏洞检测算法描述如算法2所示。

该检测算法使用Java调用堆栈信息，根据D层的信息能判定漏洞是否已经被攻击者成功利用，根据其他层次的上下文信息可快速定位漏洞细节。另外，不同反序列化类漏洞入口点不一样，但机理和利用模式相同，因此该检测算法可以检测出0Day级别的反序列化类漏洞的攻击。

3.2.3　SQL注入类漏洞检测算法

针对SQL注入类漏洞的检测，本文使用百度安全团队在OpenRASP中采用的开源算法Dtect⁃ SQLInjection^[26]，该算法描述如算法3所示。

该算法利用了SQL注入攻击的实质进行检测，即将未经过滤的用户输入直接拼接形成新的语句，改变了原始SQL语句的正常逻辑。当用户输入的字符串提供了超过1个词法单元（token）时，说明其改变了正常逻辑，判定为SQL注入攻击。

3.2.4　服务器配置不当类漏洞检测算法

服务器配置不当引起的漏洞主要表现在A层。传统检测方案是基线扫描，在线上机器上部署Agent，对相关关键配置文件进行扫描，若发现不符合安全要求的配置则进行报告。本文使用RASP技术在Tomcat应用服务器启动等时刻检查配置文件信息，若有不符合规范的配置，可实时告警并禁止应用服务器启动。例如：CVE-2017-12615漏洞的实质是Tomcat应用服务器的配置文件conf/web.xml中存在语句readonly=false。Tomcat应用服务器启动时，本文方案将对该配置文件进行扫描解析，一旦发现语句readonly=false则立即禁止Tomcat启动。服务器配置不当类漏洞检测算法的具体描述如算法4所示。

3.3　漏洞告警模块

漏洞告警模块具备以下关键功能：

1） 用户可以配置某种类型漏洞攻击的报告策略。例如：拦截并记录重要漏洞攻击，并发邮件或短信通知安全工程师，对可疑攻击行为只记录日志而不报告等策略；

2） 阻止漏洞攻击行为；

3） 详细保存漏洞攻击类型、URL、危害等级和各层次上下文信息，可读性强。

该模块接收漏洞判定模块输出的判定结果，若判定结果为出现漏洞攻击，则将RASP上下文信息搜集模块在各个层次拦截的线程上下文信息和函数调用堆栈等信息形成告警信息，记录到文件中，并通过RASP技术Hook服务器的HttpServletResponse函数，返回自定义错误页面。告警信息将作为安全事件进行存储并通知管理员，同时保证事件的唯一性。其中，Java的函数调用栈信息和上下文信息是快速定位漏洞细节的关键，可供安全工程师分析漏洞以及开发人员修补漏洞。

在整个方案中，漏洞攻击的上下文信息和Java的函数调用栈信息由RASP上下文信息搜集模块从被保护的Web程序内部收集，被传递给漏洞判定模块作为漏洞检测算法的输入数据和实施检测的依据。在识别出漏洞的情况下，这些信息又将成为检测算法输出信息的一部分，最终被漏洞告警模块存储到文件中，作为告警信息的一部分。因此本文方案可指出在被保护程序内部发生漏洞攻击时涉及的具体函数和相关参数，可实现漏洞细节定位功能。

4　 实验结果与分析

4.1　实验环境和测试样本集

本文方案框架使用Java语言编写，运行环境为Linux，测试环境如表1所示。实验选取了包含Web框架的RCE类漏洞、反序列化类漏洞、SQL注入类漏洞和服务器配置不当类漏洞这4种类型漏洞的共17个样本进行测试。具体样本包括Struts2框架的9个历史RCE类漏洞（序号1~9），Vulhub开源漏洞环境搜集的7个Java框架相关漏洞（序号10~16）以及1个SQL注入类漏洞（序号17），如表2所示。针对Struts2框架的漏洞攻击，本文选取了Struts2 2.3.20版本进行测试，运行在Tomcat 8.0.36应用服务器上；针对Spring系列框架应用，使用maven将Web应用程序打包为JAR包运行并测试；Shiro和Jenkins应用程序分别运行于Tomcat环境和JAR包环境；选取Tomcat 8.5.19测试CVE-2017-12615漏洞攻击；选取SQLMAP工具对使用JDBC编写的程序进行攻击，测试本文方案对SQL注入类漏洞的防护能力。

4.2　漏洞检测及细节定位测试

首先针对17个框架漏洞样本分别配置漏洞环境，编写利用程序，并确保在无防护程序阻拦的情况下能够分别成功实施攻击。其中，Struts2框架的9个漏洞和Shiro反序列化类漏洞部署于Tomcat应用服务器；Spring系列框架环境使用Spring Boot启动（内置Tomcat应用服务器）；Jenkins反序列化类漏洞环境使用内置Jetty应用服务器启动；服务器配置不当类漏洞存在于Tomcat应用服务器的配置文件中；使用JDBC编写带有SQL注入漏洞的Java程序，并在操作系统中启动。

攻击成功并记录性能数据后启动本文防护方案程序并重复攻击行为，记录漏洞检测效果和性能相关数据。

本文方案的漏洞检测及细节定位测试实验样本及结果如表2所示。由表2可知，对于所有的漏洞攻击，本文方案均能检测出攻击行为和攻击类型。表2中“漏洞利用结果”代表在本文方案的漏洞检测代码不阻止漏洞利用过程的情况下，漏洞利用过程是否能够成功进行。通过分析各层次拦截的上下文数据可知，对于17个漏洞中的15个漏洞，本文方案均可以快速定位漏洞利用细节，定位成功率达88.2%。

部分层次未能拦截到相关数据，多是因为攻击过程在该层次上确无相关数据，比如S2-031漏洞使用了XSLT模板注入技术直接调用JDK底层API进行攻击，未使用OGNL语言，因此在C层未能拦截到相关信息。

4.3　与现有方案对比

4.3.1　与本团队之前工作对比

相较于本团队之前的研究^[13]，本文方案的改进之处在于：

1） 部署更便捷，方案的实现方式改为采用Java Instrumentation技术动态修改应用程序字节码。本团队以往研究的方案实现方式为向Struts2和OpenJDK源码中插入拦截和检测代码后，对二者重新编译。相较而言，本文方案的实现方式更轻量化，便于修改，可扩展性高，对应用程序的性能影响小。同时对比文献[13]的实验结果可知，实现方式的改变不影响原有检测效果，甚至达到了更佳的效果；

2） 框架设计从三层监控拓展到四层监控，漏洞细节记录更丰富。本文检测框架添加了Java Web应用服务器层的检测，拓展到四层监控，日志记录内容更丰富（增加了URL、参数及上传数据等网络请求及传输信息），有助于安全分析人员定位漏洞细节。

3） 本文框架的检测覆盖范围更广。文献[13]仅检测Struts2框架的RCE类漏洞，本文框架可检测出主流Web框架和组件上的RCE类漏洞、反序列化类漏洞、服务器配置不当类漏洞、SQL注入类漏洞等4类漏洞，并可通过拓展利用模式集合便捷地拓展框架检测范围。

4.3.2　与OpenRASP对比

选取百度开源的同类型产品OpenRASP V1.0 Java^[27]与本文方案进行对比，从漏洞检测率、运行方式、漏洞类型识别准确率等方面进行分析。实验同样使用上文所述17个漏洞样本对安装有OpenRASP V1.0 Java的漏洞环境进行攻击，得到的对比检测结果如表3所示。其中，漏洞检测率和漏洞类型识别准确率分别为成功检测出的漏洞攻击样本数量和被成功识别类型的漏洞攻击样本数量在总样本中所占的百分比。

由表3可知，就所使用的实验样本集合而言，本文方案和OpenRASP产品均能检测出全部漏洞，而本文方案的漏洞类型识别准确率更高，原因在于OpenRASP可识别的漏洞类型范围暂未覆盖实验使用的全部样本。百度在2019年4月发布了OpenRASP V1.0 Java版本，并给出了其针对部分CVE漏洞的检测结果。目前OpenRASP针对Struts框架可检测的RCE类漏洞为2个：2013年的S2-016以及2017年的S2-045^[27]。而实验样本集合中，本文方案可检测的Struts平台RCE类漏洞为9个，数量多于目前OpenRASP官方公布的漏洞数量。

另外，从设计和实现的角度对比可知，本文框架是从4个层次实时收集信息，综合多个层次的信息进行上下文分析和攻击检测，而OpenRASP多采取单一层次规则匹配攻击特征。例如，针对Struts2框架RCE类漏洞，OpenRASP产品只是在OGNL语言层面进行了规则匹配，而本文方案则是在3个层次上联合检测，并记录Java Web应用服务器层上的网络访问信息，达到识别攻击细节和类型、判断攻击是否成功以及是否为0Day攻击的效果。具体而言，本文方案基于JDK底层行为监控层中相关远程代码执行行为（如命令执行、读写文件、网络通信等）进行信息拦截，可判断出当前是否为成功利用漏洞的攻击行为；通过应用程序框架源码层中的拦截信息，可根据历史漏洞的入口点，判断当前为已知攻击方法还是疑似0Day级别漏洞攻击；根据表达式语言层的OGNL表达式语言拦截信息，可进一步判定当前是否为漏洞攻击；本文方案记录了Java Web应用服务器层的URL、参数及上传数据等信息，而OpenRASP未记录这些信息，相较而言，本文方案记录的漏洞信息更为丰富，可为安全研究人员的漏洞分析过程提供更多帮助。

因此，相较于OpenRASP，本文框架的漏洞检测更难以绕过，反馈信息更全面，并可有效发现已知漏洞和未知漏洞攻击。同时，基于本文方案反馈的告警信息，本文方案还可以更有效地定位、更准确地还原漏洞攻击细节，而这是OpenRASP并不具备的功能。

4.4　性能测试

采用Apache公司的JMeter性能测试工具对Tomcat部署的Struts2应用程序进行访问测试，测试结果如表4所示，运行检测程序前后应用响应时间分布如图5所示。

实验中，首先，运行在Tomcat上部署的Struts2应用程序，将其作为运行检测程序前的性能测试对象，并对其进行访问测试，统计Struts2应用程序对访问的响应时间；然后，在同一操作系统环境中，启动本文方案的原型程序并配置相应参数，使其将已启动的Struts2应用程序作为目标保护对象，随后再对Struts2应用程序进行访问测试。实验设置JMeter活跃线程数为100，10 s随机启动完成，代表100个用户在10 s内同时访问系统，循环测试10次，因此访问样本总数为1 000。表4中，性能消耗由Struts2应用程序对访问的平均响应时间计算得到。假设平均响应时间在运行检测程序前、后的值分别为T₁、T₂，则

\mathrm{性}\mathrm{能}\mathrm{消}\mathrm{耗}=\frac{(T_{\mathrm{2}}-T_{\mathrm{1}})}{T_{\mathrm{1}}}\times \mathrm{100}\mathrm{\%}

同时JMeter性能测试工具的分析报告中也提供Apdex（application performance index）的计算结果。Apdex是由Apdex联盟开放的用于评估应用性能的工业标准，该标准从用户的角度出发，将对应用响应时间的表现转为用户对于应用性能的满意度评价（可量化为 0~1）。该值越接近1，则代表用户满意度越高。其计算公式为

\mathrm{A}\mathrm{p}\mathrm{d}\mathrm{e}\mathrm{x}=\frac{(\mathrm{S}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{s}\mathrm{f}\mathrm{i}\mathrm{e}\mathrm{d}\mathrm{C}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{t}+\mathrm{T}\mathrm{o}\mathrm{l}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{C}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{t}/\mathrm{2})}{\mathrm{T}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}\mathrm{S}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{e}\mathrm{s}}

其中， Satisfied Count 和Tolerating Count分别为指定采样时间内响应时间满足 “满意”要求或“可容忍” 要求的应用响应次数（两项要求对应的响应时间阈值均根据应用程序预设的最佳响应时间确定，实验中分别设为0.5 s和2.0 s）；Total Samples 为采样总次数。从该值的计算公式可知，应用的Apdex得分与采样持续时间无关，与目标程序的响应时间相关。

由表4可知，根据运行检测程序前后测试结果中平均响应时间，计算得到性能消耗约为6.1%。并且，在目标应用程序中运行检测程序仅造成Apdex降低0.006，表明检测框架并未造成用户满意度大幅降低。

由图5可知，90%的用户响应时间均在5 s以内，其中运行检测程序后的响应时间总体略长。运行检测程序前后分布曲线并未有较大改变，表明检测程序对目标应用程序的总体性能表现没有较大影响。

5　 结 语

本文通过分析现有的Java Web框架主流漏洞原理，总结了4类漏洞的通用利用模式集合，在其基础上，提出了基于RASP技术的Java Web框架漏洞通用检测与定位方案，并使用典型框架上的4类漏洞攻击样本，对本文方案分别进行了攻击检测和细节定位功能测试、与百度的OpenRASP产品的对比实验、方案性能测试，证明了本文方案的有效性。在后续的研究工作中，针对应用程序内部上下文信息数据，检测方案将进一步覆盖更多的漏洞类型，并尝试基于机器学习算法实现漏洞攻击的无规则检测。

参考文献

[1] ZHAO M, GROSSKLAGS J, LIU P. An empirical study of web vulnerability discovery ecosystems [C]//Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. New York: ACM Press, 2015: 1105-1117. DOI:10.1145/2810103.2813704 .

[2] KRUEGER T, GEHL C, RIECK K, et al. TokDoc: A self-healing web application firewall [C] //Proceedings of the 2010 ACM Symposium on Applied Computing. New York: ACM Press, 2010: 1846-1853. DOI:10.1145/1774088.1774480 .

[3] FEIMAN J. Maverick Research: Stop Protecting Your Apps; It’s Time for Apps to Protect Themselves [EB/OL]. [2014-11-10].

[4] ⁃research⁃stop⁃protecting⁃apps.

[5] KONG Y, ZHANG Y Q, FANG Z J, et al. Static detection of logic vulnerabilities in Java Web applications[C]//2012 IEEE 11th International Conference on Trust, Security and Privacy in Computing and Communications. New York: IEEE Press, 2012: 1083-1088. DOI: 10.1109/TrustCom.2012.266 .

[6] LIVSHITS B, LAM M S. Finding Security Vulnerabilities in Java Applications with Static Analysis [EB/OL]. [2019-02-03].

[7] ČISAR P, ČISAR S M. The framework of runtime application self-protection technology [C]// 2016 IEEE 17th International Symposium on Computational Intelligence and Informatics. New York: IEEE Press, 2016: 000081-000086. DOI:10.1109/CINTI.2016.7846383 .

[8] LIVSHITS B, MARTIN M, LAM M S. SecuriFly: Runtime Protection and Recovery from Web Application Vulnerabilities [R]. San Francisco: Stanford University, 2006.

[9] STEINER S, DE LEON D C, ALVES-FOSS J. A structured analysis of SQL injection runtime mitigation techniques [C]//Proceedings of the 50th Hawaii International Conference on System Sciences. Hawaii: University of Hawaii, 2017:2887-2895. DOI: 10.24251/HICSS.2017.349 .

[10] HUANG Y W, HUANG S K, LIN T P, et al. Web application security assessment by fault injection and behavior monitoring [C]//Proceedings of the 12th International Conference on World Wide Web. New York: ACM Press, 2003: 148-159. DOI:10.1145/775152.775174 .

[11] PIECZUL O, FOLEY S N. Runtime detection of zero-day vulnerability exploits in contemporary software systems [C]//IFIP Annual Conference on Data and Applications Security and Privacy. Heidelberg: Springer, 2016: 347-363. DOI:10.1007/978-3-319-41483-6_24 .

[12] PARAMESHWARAN I, BUDIANTO E, SHINDE S, et al. DexterJS: Robust testing platform for DOM-based XSS vulnerabilities [C]//ESEC/FSE Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. New York: ACM Press, 2015:946-949. DOI:10.1145/2786805.2803191 .

[13] WANG R, XU G Q, ZENG X J, et al. TT-XSS: A novel taint tracking based dynamic detection framework for DOM cross-site scripting [J]. Journal of Parallel and Distributed Computing, 2018, 118:100-106. DOI:10.1016/j.jpdc.2017.07.006 .

[14] HU A Q, PENG G J, CHEN Z H, et al. A Struts2 unknown vulnerability attack detection and backtracking scheme based on multilayer monitoring [C]//Chinese Conference on Trusted Computing and Information Security. Heidelberg: Springer⁃Verlag， 2017: 383-396. DOI:10.1007/978-981-10-7080-8_26 .

[15] 周志明. 深入理解Java虚拟机: JVM 高级特性与最佳实践[M]. 第2版.北京：机械工业出版社，2010.

[16] ZHOU Z M. Understanding the JVM Advanced Features and Best Practices [M]. 2nd Ed. Beijing: Mechanical Industry Press, 2010(Ch).

[17] 李骁. JVM 逃逸技术与 JRE 漏洞挖掘研究[D]. 上海：上海交通大学, 2014.

[18] LI X. Research of JVM Escape and JRE Vulnerability Discovery [D]. Shanghai: Shanghai Jiao Tong University, 2014(Ch).

[19] ASHRAF Z. Analysis of recent struts vulnerabilities in parameters and cookie interceptors, their impact and exploitation [EB/OL]. [2018-09-10].

[20] ⁃vulnerabilities⁃analysis⁃parameters⁃cookie⁃interceptors⁃impact⁃exploitation/.

[21] NAVEEN B. Spring框架简介[EB/OL]. [2018-10-10]. spri⁃ ng1/index.html.

[22] NAVEEN B. Introduction to the Spring Framework [EB/OL]. [2018-10-10]. spring1/index.html (Ch).

[23] LAZY S. Struts2框架简介[EB/OL]. [2018-09-10].

[24] LAZY S. Introduction to the Struts2 Framework[EB/OL]. [2018-09-10].

[25] 杨晓. Tomcat简介及原理解说[EB/OL]. [2019-01-01]. 2014/p/5578505.html.

[26] YANG X. Introduction and Original Understanding of Tomcat [EB/OL]. [2019-01-01]. 2014/p/5578505.html(Ch).

[27] KAISER M. Pwning Your Java Messaging with Deseria⁃lization Vulnerabilities [EB/OL]. [2019-01-01]. your⁃java⁃messaging⁃with⁃deserialization⁃vulnerabilities⁃3018.

[28] PELES O, HAY R. One Class to Rule Them All: 0Day Deserialization Vulnerabilities in Android [EB/OL]. [2019-03-04].

[29] ⁃program/presentation/peles.

[30] 龙轩. Shiro权限框架简介[EB/OL]. [2018-10-30].

[31] LONG X. Introduction to Shiro Permissions Framework [EB/OL]. [2018-10-30].

[32] 刘华婷.基于Jenkins快速搭建持续集成环境[EB/OL]. [2018-11-01]. ⁃lo⁃jenkins/index.html.

[33] LIU H T. Quickly Build Continuous Integration Environment Based on Jenkins [EB/OL]. [2018-11-01]. ⁃lo⁃jenkins/index.html(Ch).

[34] 陆晨. JVM SandBox的技术原理与应用分析[EB/OL]. [2019-06-01].

[35] *Gp.

[36] LU C. Technical Principles and Application Analysis of JVM SandBox [EB/OL]. [2019-06-01].

[37] *Gp(Ch).

[38] XBEAR. RASP 技术介绍与实现[EB/OL]. [2017-06-22].

[39] XBEAR. RASP Technology Introduction and Implementation [EB/OL]. [2017-06-22].

[40] BAIDU. OpenRASP Official Website [EB/OL]. [2019-02-02].

[41] BAIDU. OpenRASP: CVE Vulnerability Coverage Instructions[EB/OL]. [2019-02-02].

基金资助

NSFC-通用技术基础研究联合基金(U1636107)

国家自然科学基金(61972297)