CN113158197A - 一种基于主动iast的sql注入漏洞检测方法、系统 - Google Patents

Abstract

本申请提供一种基于主动IAST的SQL注入漏洞检测方法、系统，并涉及计算机软件安全测试技术领域。该方法包括：通过在服务端，对目标程序中的调用SQL语句对象的函数插桩探针，和使预先插桩的探针在模拟攻击时准确采集相应SQL执行语句，以及采集模拟攻击的Payload；根据采集的Payload和SQL执行语句，判断判断目标程序中潜藏了与之相应的SQL注入漏洞。较之现有技术，该方案，能够通过对目标程序插桩探针以感知目标程序的内部逻辑结构，作出更为准确的判断，以降低SQL注入漏洞检测的误报可能，且能够准确地定位检出漏洞的位置。

Description

一种基于主动IAST的SQL注入漏洞检测方法、系统

技术领域

本公开的实施例主要涉及计算机软件安全测试领域，并且更具体地，涉及一种基于主动IAST的SQL注入漏洞检测方法、系统。

背景技术

结构化查询语言(Structured Query Language)，简称SQL，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。在软件设计开发过程中，SQL通常被用来作为网页的应用数据和后台数据库中的数据进行交互时所采用的语言。然而，SQL注入攻击，也是攻击者对数据库进行攻击的常用手段之一。攻击者通过在HTTP请求中输入含有恶意构造且语法合法的SQL语句进行SQL攻击，一旦应用程序中没有对外部输入做严格的处理，那么就存在触发SQL注入漏洞危险。目前，主流的网络后端技术和主流数据库相结合的Web应用程序都发现有SQL注入漏洞。

SQL注入漏洞，不仅可能广泛存在Web应用程序中，注入点隐蔽在HTTP请求中；而且攻击者一旦得逞，往往会对数据库信息安全造成严重威胁，甚至对整个系统安全造成影响；更遭的是，SQL注入攻击简单易学，攻击过程简单，极容易被不同层次的攻击者作为破坏计算机软件安全的武器。因此，在Web应用程序交付前，必须进行应用安全检测，检出潜藏的SQL注入漏洞并修复。

现有的SQL注入漏洞检测技术，无论是动态检测，还是静态检测，都存在其缺陷：动态检测通过响应报文判断往往使得SQL注入漏洞检测误报率、漏报率都居高不下；而静态检测则依赖对源代码的特征扫描，工作量大且效率低。

发明内容

根据本公开的示例实施例，提供一种基于主动IAST的SQL注入漏洞检测的方案。

在本公开的第一方面中，提供一种基于主动IAST的SQL注入漏洞检测的方法。该方法包括：在服务端，对目标程序中的调用SQL语句对象的函数插桩探针；在扫描端，使携带有攻击SQL注入漏洞的Payload的HTTP请求攻击服务端的目标程序；以及在服务端，接收所述HTTP请求，从所述HTTP请求的数据报文中提取所述Payload的原始输入，并在处理所述HTTP请求的数据流执行到预先插桩的探针时，使所述探针获取所述探针插桩函数的SQL执行语句；根据提取的所述Payload的原始输入和所述SQL执行语句，判断是否有所述Payload或与所述Payload构造相似的有害数据进入所述SQL执行语句；如是，则判断目标程序中潜藏了与所述Payload相应的SQL注入漏洞。

在本公开的第二方面中，提供一种基于主动IAST的SQL注入漏洞检测的系统。该系统包括：插桩单元、采集单元、分析单元、扫描单元；其中，插桩单元，被部署在服务端；插桩单元，被配置得能够执行用于对目标程序中的调用SQL语句对象的函数插桩探针的操作；采集单元，被部署在服务端，包括上述的被插桩的探针；采集单元，被配置得能够执行用于从模拟攻击的HTTP请求的数据报文中提取其携带的攻击SQL注入漏洞的Payload的原始输入的操作，和用于使所述探针在处理所述HTTP请求的数据流执行到该探针时获取该探针插桩的函数的SQL执行语句的操作；分析单元，被配置得能够执行用于根据提取的所述Payload和所述SQL执行语句判断目标程序中是否潜藏了与所述Payload相应的SQL注入漏洞的操作；具体地，分析单元，被配置得能够根据提取的所述Payload的原始输入和所述SQL执行语句，判断是否有所述Payload或与所述Payload构造相似的有害数据进入所述SQL执行语句；如是，判断目标程序中潜藏了相应的SQL注入漏洞；

扫描单元，被分离于服务端部署在扫描端；扫描单元，被配置得能够执行用于以携带有攻击SQL注入漏洞的Payload的HTTP请求攻击服务端的目标程序的操作。

在本公开的第三方面中，提供了一种计算机可读存储介质。该介质上存储有用于漏洞检测相关的计算机指令，该计算机指令在被计算机处理器执行时能够实现第一方面述及的方法或所述方法中的部分操作。

在本公开的第四方面中，提供了一种计算机程序产品。该程序产品包括计算机程序，该计算机程序在被计算机处理器执行时能够实现第一方面述及的方法或所述方法中的部分操作。

应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标注表示相同或相似的元素，其中：

图1示出了现有技术中的基于DAST扫描的SQL注入漏洞检测的具体过程的示例示意图。

图2示出了根据本公开的多个实施例能够在其中实现的示例环境的示意图；

图3示出了根据本公开的一些实施例的基于主动IAST的SQL注入漏洞检测的过程的示意图；

图4示出了根据本公开的一些实施例的基于主动IAST的SQL注入漏洞检测的系统的框图；其中，图4(a)和图4(b)分别示出了上述实施例在示例环境200上的两种不同实现方式下的基于主动IAST的SQL注入漏洞检测的系统的框图；

图5示出了采用上述实施例的基于主动IAST的SQL注入漏洞检测方案的(涉及用户登录的注入点的)SQL注入漏洞检测的具体过程的示例示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

在本公开的实施例的描述中术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。

在本公开的实施例的描述中技术术语“目标程序”，是指作为SQL注入漏洞检测对象的Web应用程序或基于Web技术开发的App等计算机应用程序。对于计算机程序来说，安全漏洞是不可避免的。程序是由人来编程的，兼顾代码质量和开发效率，是不可能存在开发阶段一蹴而就、完全符合编程规范、没有漏洞和缺陷的大型应用程序的；尤其是那些满足诸多功能需求、有着复杂业务逻辑的基于B/S的Web应用程序，是不可避免地存在着漏洞和缺陷的。

在本公开的实施例的描述中技术术语“探针”，是指“插桩”的“探针”，其本质上是进行信息采集的代码片段，可以是赋值语句或采集覆盖信息的函数调用。在本公开的实施例的描述中技术术语“插桩”，又称“程序插桩”，是指在保证被测程序原有逻辑完整性的基础上在程序中插入“探针”，通过对“探针”抛出的程序运行特征数据(即运行时数据)的分析，获得程序的控制流和数据流，进而得到逻辑覆盖等动态信息，从而实现测试目的的方法。其中的“探针”，根据插桩点、捕获数据需求等的不同，可以设计具有相应捕获功能的“探针”，获取所需的数据。在同一个被测程序中，根据不同的测试需要，可以包括仅插桩一个“探针”，也可以在其中多个不同的插桩点分别插入“探针”。

在本公开的实施例的描述中技术术语“调用SQL语句对象的函数”，是指“目标程序”中对数据库的直接操作的“函数”。严格来说，这些“调用SQL语句对象的函数”，都是通过将相应的“SQL执行语句”发送给数据库系统/软件进行执行，来实现对数据库的相应的、例如增删改查等的操作，而并不能直接执行。一般来说，这些“调用SQL语句对象的函数”，在基于不同语言编程的目标程序中，可以是对数据库系统/软件进行直接操作的函数，也可以是在那些数据库访问类和接口中的那些涉及数据库SQL语句执行的方法，例如，JAVA中的executeQuery等。

在本公开的实施例的描述中技术术语“SQL执行语句”，是指“目标程序”下达给数据库系统/软件的指令，用于实现对数据库的直接操作。“SQL执行语句”不能直接执行，需要发送给数据库系统/软件进行执行，以实现对数据库的例如增删改查等的操作。一般来说，攻击者利用SQL注入漏洞时，最终也是通过含有恶意构造的SQL执行语句进行SQL攻击，实现攻击目的的。

在本公开的实施例的描述中技术术语“Payload”，即“有效载荷”，是指数据传输中被承载运输的实际信息，通常也称作实际数据或数据体。在传输数据时为使数据传输更可靠，通常需要在每一批数据套加一些辅助信息而每一批数据与其辅助“外套”，就构成了传输通道的基本传输单元，即数据帧或数据包；这些“外套”通常被用于辅助数据传输，也称为开销数据；而其中的原始数据通常被视为有效载荷。在SQL注入漏洞检测过程中，“Payload”是指能够攻击各种不同SQL注入漏洞的“有效载荷”。用于SQL注入漏洞检测的“Payload”，是根据需要被构造的。对于不同注入点、注入参数内容等的不同SQL注入漏洞，结合不同的注入点、检测目的等，需要针对性地构造不同的“Payload”。在SQL注入漏洞检测实践中，可以根据需要自行构造“Payload”，也可以选择漏扫工具中比较成熟的相关库中的Payload及其攻击报文，进行SQL注入漏洞的检测。

作为一种发生于应用程序与数据库层的安全漏洞，严格来说，SQL注入漏洞可能出现在任何基于SQL语言执行数据库操作的应用程序中，任何的一种基于SQL语言的数据库都可能被攻击。攻击者在HTTP请求中输入含有恶意构造且语法合法的SQL语句，只要开发者在编程时未对接收的输入数据进行规范性验证、检测或处理(例如校验、预拼接或过滤等等)，那么就会出现SQL注入漏洞，且极有可能被利用，甚至造成安全事故。目前以Java、PHP、Perl等开发的Web后端技术与Oracl、SQLServer、Sybase、DB2、MySQL等数据库相结合的Web应用程序都发现有SQL注入漏洞。对应地，SQL注入攻击有极具隐蔽性，有害的SQL注入语句嵌入在普通的HTTP请求中，很难被区分和预警。而事实SQL注入攻击的成本又很低，有大量的SQL注入工具可以被攻击者用于实施SQL注入攻击，攻击过程简单易学，不需要专业知识。然而，SQL注入攻击一旦成功，攻击者往往获得对服务器操作的全部或部分权限，造成包括但不限于：数据资料外协、数据库服务器被攻击、系统管理账户被篡改、篡改网站主页、添加恶意代码、攻陷或瘫痪系统等。因此，IT业者会从软件设计开发测试到运行维护的多个方面采取措施，防范SQL注入攻击；其中，被认为最有效的措施就是：基于以SQL注入漏洞扫描为代表的各种漏洞检测技术，在攻击者发现SQL注入漏洞前，发现并修复它。然而，现有的静态检测依赖对源代码的特征扫描，工作量大且效率低；而是动态检测虽然不需要源代码，仅通过响应报文判断就能够检测运行态的目标程序的SQL注入漏洞，然而存在误报率高、无法具体定位漏洞位置而难以快速修复等问题。

图1即示出了现有技术中的基于DAST扫描的SQL注入漏洞检测的具体过程的示例示意图。如图1所示，基于DAST扫描的SQL注入漏洞检测在扫描检测例如涉及用户登录相关的注入点等的SQL注入漏洞检测的具体过程100，包括：通过在扫描端120发送经过篡改的、包含相应的Payload(例如构造的如图1中的用户登录相关的Payload)的请求报文，攻击服务端110，进而根据响应报文以及特征库进行分析，发现和验证SQL注入漏洞。显然，DAST扫描过程无法了解应用程序的内部逻辑结构，仅通过响应报文判断就能够检测运行态的目标程序的SQL注入漏洞，然而存在误报可能，更是只能定位到扫描攻击的url，无法定位漏洞的具体位置。

根据本公开的实施例，提出一种基于主动IAST的SQL注入漏洞检测的方案，通过在服务端，对目标程序中的调用SQL语句对象的函数插桩探针，和使预先插桩的探针在模拟攻击时准确采集相应SQL执行语句，以及采集模拟攻击的Payload；根据采集的Payload和SQL执行语句，判断是否有所述Payload或与所述Payload构造相似的有害数据进入所述SQL执行语句，进而判断目标程序中潜藏了与之相应的SQL注入漏洞。

本公开的方案，较之现有技术，能够通过对目标程序插桩探针以感知目标程序的内部逻辑结构，特别是对目标程序中进行数据库操作的位点插桩探针以准确获取模拟攻击时的具体SQL执行语句，并据此作出更为准确的判断，以降低SQL注入漏洞检测的误报可能和更为准确地定位检出漏洞的位置。

以下将参照附图来具体描述本公开的实施例。图2示出了本公开的多个实施例能够在其中实现的示例环境的示意图。如图2所示，示例环境200，包括：服务端210和扫描端220；服务端210、扫描端220可以是实体的服务器设备，也可以是由硬件设备节点/虚拟节点组成的服务器/云服务器集群。在服务端210上，部署目标程序，根据SQL注入漏洞检测的需要，在主动IAST过程中，在服务端还包括插桩探针230，与目标程序耦合(例如寄生于目标程序中)。

根据本公开的一些实施例，提出一种基于主动IAST的SQL注入漏洞检测的方法。该方法主要基于Agent技术、应用于服务端，其中包括在示例环境200中实现的示例。图3示出了上述示例的基于主动IAST的SQL注入漏洞检测的过程的示意图。如图3所示，示例中的基于主动IAST的SQL注入漏洞检测的方法可以在示例环境200中实现，其中的基于主动IAST的SQL注入漏洞检测的过程300，包括：在服务端210，对目标程序中的调用SQL语句对象的函数插桩探针230(参考框301)；进而在扫描端220，以携带有攻击SQL注入漏洞的Payload的HTTP请求模拟攻击服务端的目标程序(参考框302)；在服务端210，接收扫描端220发出的模拟攻击HTTP请求，从上述HTTP请求的数据报文中提取其中Payload的原始输入，并在处理该HTTP请求的数据流执行到预先插桩的探针时，使该探针获取该探针插桩函数的SQL执行语句(参考框303)；根据提取的Payload的原始输入和获取的SQL执行语句，判断是否有Payload的原始输入或与该Payload构造相似的有害数据(例如Payload未经有效过滤的残余部分，仍对数据库有安全威胁的情形)进入该SQL执行语句；如是，则判断目标程序中潜藏了与所述Payload相应的SQL注入漏洞(参考框304)。

在一些实施例中，在框301中，还可以对目标程序插桩相应的辅助探针；上述的辅助探针，主要被用于从上述HTTP请求的数据报文中提取其中Payload的原始输入，或被于获取目标程序返回给测试端的响应报文。具体地，在框301中，在对目标程序中的调用SQL语句对象的函数插桩探针230的同时，还可以包括：对目标程序插桩相应的辅助探针；对目标程序中相应的位点插桩若干个相应功能的辅助探针；其中，这些辅助探针或全部或者部分，可以是被用于从上述HTTP请求的数据报文中提取其中Payload的原始输入，也可以是被用于获取目标程序返回给测试端的响应报文；其中，获取的响应报文，用于识别相应的HTTP请求，确定其中url，分析检出的所述SQL注入漏洞的注入点。

在一些实施例中，在框301中，还可以采用运行时插桩的方式，对目标程序插桩相应的各种探针，以便基于最小侵入原则获取验证分析所述的各种数据信息。具体地，可以是通过相应的配置设置，在目标程序启动过程中，对相关关键函数等位点插桩探针。以Java编程的目标程序为例，对其执行运行时插桩，可以在被检测Java程序的类加载过程中，采用字节码插桩工具等方式，在相应的位点插桩相应的探针。

在一些实施例中，在框303中，使在调用SQL语句对象的函数的插桩探针，在获取所述SQL执行语句的同时，还获取相应的函数调用栈信息；所述的函数调用栈信息，包括能够确定SQL注入漏洞触发的代码行信息；所述函数调用栈信息，用于准确定位SQL注入漏洞的位置。

根据本公开的一些实施例，提出一种基于主动IAST的SQL注入漏洞检测的系统。该系统主要包括扫描端和服务端的相关功能单元，其中包括在示例环境200中实现的示例。图4示出了根据本公开的一些实施例的基于主动IAST的SQL注入漏洞检测的系统的框图；其中，图4(a)和图4(b)分别示出了上述实施例在示例环境200上的两种不同实现方式下的基于主动IAST的SQL注入漏洞检测的系统的框图。如图4所示，基于主动IAST的SQL注入漏洞检测的系统400，包括：插桩单元410、采集单元420、分析单元440、扫描单元430；其中，插桩单元410，被部署在服务端210；插桩单元410，被配置得能够执行用于对目标程序中的调用SQL语句对象的函数插桩探针的操作；采集单元420，也被部署在服务端210，其主要包括采集模拟攻击的HTTP请求的payload的部分和插桩单元410对目标程序插桩的探针；采集单元420，被配置得能够执行用于从模拟攻击的HTTP请求的数据报文中提取其携带的攻击SQL注入漏洞的Payload的原始输入的操作，以及用于使所述探针在处理所述HTTP请求的数据流执行到该探针时获取该探针插桩的函数的SQL执行语句的操作；分析单元440，被配置得能够执行用于根据提取的所述Payload和所述SQL执行语句判断目标程序中是否潜藏了与所述Payload相应的SQL注入漏洞的操作；具体地，分析单元，被配置得能够根据提取的所述Payload的原始输入和所述SQL执行语句，判断是否有所述Payload或与所述Payload构造相似的有害数据进入所述SQL执行语句；如是，判断目标程序中潜藏了相应的SQL注入漏洞；

扫描单元430，则被分离于服务端210部署在扫描端220；扫描单元430，被配置得能够执行用于以携带有攻击SQL注入漏洞的Payload的HTTP请求攻击服务端210的目标程序的操作。

在一些实施例中，插桩单元410还可以对目标程序插桩相应的辅助探针；上述的辅助探针，主要被用于从上述HTTP请求的数据报文中提取其中Payload的原始输入，或被于获取目标程序返回给测试端的响应报文。具体地，在框301中，在对目标程序中的调用SQL语句对象的函数插桩探针230的同时，还可以包括：对目标程序插桩相应的辅助探针；对目标程序中相应的位点插桩若干个相应功能的辅助探针；其中，这些辅助探针或全部或者部分，可以是被用于从上述HTTP请求的数据报文中提取其中Payload的原始输入，也可以是被用于获取目标程序返回给测试端的响应报文；其中，获取的响应报文，用于识别相应的HTTP请求，确定其中url，分析检出的所述SQL注入漏洞的注入点。

在一些实施例中，插桩单元410还可以采用运行时插桩的方式，对目标程序插桩相应的各种探针，以便基于最小侵入原则获取验证分析所述的各种数据信息。具体地，可以是通过相应的配置设置，在目标程序启动过程中，对相关关键函数等位点插桩探针。以Java编程的目标程序为例，对其执行运行时插桩，可以在被检测Java程序的类加载过程中，采用字节码插桩工具等方式，在相应的位点插桩相应的探针。

在一些实施例中，采集单元420中的在调用SQL语句对象的函数的插桩探针，在获取所述SQL执行语句的同时，还获取相应的函数调用栈信息；所述的函数调用栈信息，包括能够确定SQL注入漏洞触发的代码行信息；所述函数调用栈信息，用于准确定位SQL注入漏洞的位置。

在一些实施例中，分析单元440，被部署在服务端210(参考图4(b))；分析单元440部署在服务端210，可以减少与外部设备的数据通信传输，能够减少不必要的通信开销，同时还能规避目标程序内部运行数据外泄的风险等。对于所述系统在服务端的部署，有着多种实现方式，其中一种实现方式包括：配置得使所述的在调用SQL语句对象的函数的插桩探针，还能够执行分析单元430的操作，直接检测目标程序中是否潜藏了与所述Payload相应的SQL注入漏洞的操作。

根据本公开的一些实施例，提出一种计算机可读存储介质，所述的计算机可读存储介质存储有用于实现漏洞检测相关的例如以程序代码等形式存在的计算机指令；所述计算机指令在被处理器执行时，被配置得用于实现上述实施例中的基于主动IAST的SQL注入漏洞检测的方法或所述方法中的部分操作。所述的计算机可读存储介质，可以与存储诸如计算机程序代码等之类的计算机实现指令的任何典型存储设备相对应。当所述的计算机可读存储介质，可以包括非易失性存储器、易失性存储器、和/或一个或多个存储设备中的一个或多个。

为了进一步地描述上述实施例中的方案，以下结合基于主动IAST的SQL注入漏洞检测方案进行SQL注入漏洞检测过程的具体示例进行描述。图5示出了采用上述实施例的基于主动IAST的SQL注入漏洞检测方案进行用户登录相关的注入点的SQL注入漏洞检测的具体过程的示例示意图。如图5所示，基于主动IAST的SQL注入漏洞检测方案进行用户登录相关的注入点的SQL注入漏洞检测的过程500，包括：

在模拟攻击前，在服务端210通过设置相关配置方式使目标程序运行加载时(这里具体是在类加载时)对服务端目标程序中的executeQuery()函数插桩探针230(其中包括检测采集逻辑的代码)；

构造针对用户登录注入点的SQL注入漏洞检测的Payload，以期在相应的注入点注入：

payload：username＝a′″--&password＝123

通过扫描端220以HTTP请求的形式模拟攻击目标程序；所述HTTP请求的数据报文中包含以上的Payload内容；

在服务端210，接收所述HTTP请求后，通过例如预先插桩辅助探针等方式解析并从所述HTTP请求

GET/sqli.jsp？username＝a′″--&password＝123HTTP/1.1

Host：192.168.172.103：8080

Upgrade-Insecure-Requests：1

User-Agent：Mozilla/5.0(Windows NT 10.0；Win64；x64)

AppleWebKit/537.36(KHTML，like Gecko)Chrome/77.0.3865.90

Safar/537.36

Accept：

text/html，application/×html+xml，application/xml；q＝0.9，image/webp，ima

ge/apng，＊/＊；q＝0.8，application/signed-exchange；v＝b3

Accept-Encoding：gzip，deflate

Accept-Language：zh-CN，zh；q＝0.9，en；q＝0.8

Cookie：JSESSIONID＝59A62F3D84719574E7226CF2EDC791B1；

JSESSIONID＝79A4A8A819CF588FAC2ECF1C1FFF30BD

Conrection：close

中提取其中Payload的原始输入；

然后在处理该HTTP请求的数据流执行到executeQuery()函数时，预先插桩探针230获取executeQuery()函数的sql执行语句：

stmtexecuteQuery(select＊from users where username＝″a′″--″and

password＝123)

根据上述的Payload的原始输入和sql执行语句，具体可以通过在设计插桩探针230时加入检测逻辑的代码以及预设检测规则、或取出上述数据进行检测等方式，判断是否有上述Payload或与上述Payload构造相似的有害数据(例如经不完全的过滤处理仍然有害的残余Payload内容等)进入上述的executeQuery()函数的SQL执行语句，例如图中显示情形，显然是有有害的Payload进入当前sql语句，属异常执行，故可判断该注入点有sql注入漏洞；同时还可使插桩探针230获取函数调用栈信息，确定和返回函数调用栈、代码行数、所述的HTTP请求的响应报文，以辅助定位漏洞，进而及时修复。经如此漏洞修复后，还可以此方法进行低成本且及时验证，提高漏洞收敛效率。

本文中以上描述的功能都可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以独立地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (10)

1.一种基于主动IAST的SQL注入漏洞检测的方法，其特征在于，该方法包括：

在服务端，对目标程序中的调用SQL语句对象的函数插桩探针；

在扫描端，使携带有攻击SQL注入漏洞的Payload的HTTP请求攻击服务端的目标程序；

在服务端，接收所述HTTP请求，从所述HTTP请求的数据报文中提取所述Payload的原始输入，并在处理所述HTTP请求的数据流执行到预先插桩的探针时，使所述探针获取所述探针插桩函数的SQL执行语句；

根据提取的所述Payload的原始输入和所述SQL执行语句，判断是否有所述Payload或与所述Payload构造相似的有害数据进入所述SQL执行语句；如是，则判断目标程序中潜藏了与所述Payload相应的SQL注入漏洞。

2.根据权利要求1所述的方法，其特征在于，

在服务端，对目标程序插桩相应的辅助探针；其中的辅助探针，被用于从所述HTTP请求的数据报文中提取所述Payload的原始输入，和/或，获取目标程序返回给测试端的响应报文；

其中，所述的响应报文，用于分析检出的所述SQL注入漏洞的注入点。

3.根据权利要求1或2任一所述的方法，其特征在于，

采用运行时插桩的方式，对目标程序插桩相应的探针。

4.根据权利要求1所述的方法，其特征在于，

使所述的在调用SQL语句对象的函数的插桩探针，在获取所述SQL执行语句的同时，获取相应的函数调用栈信息；所述的函数调用栈信息，包括能够确定SQL注入漏洞触发的代码行信息；所述函数调用栈信息，用于准确定位所述SQL注入漏洞的位置。

5.一种基于主动IAST的SQL注入漏洞检测的系统，其特征在于，该系统包括：插桩单元、采集单元、分析单元、扫描单元；

插桩单元，被部署在服务端；插桩单元，被配置得能够执行用于对目标程序中的调用SQL语句对象的函数插桩探针的操作；

采集单元，被部署在服务端，包括所述的被插桩的探针；采集单元，被配置得能够执行用于从模拟攻击的HTTP请求的数据报文中提取其携带的攻击SQL注入漏洞的Payload的原始输入的操作，和用于使所述探针在处理所述HTTP请求的数据流执行到该探针时获取该探针插桩的函数的SQL执行语句的操作；

分析单元，被配置得能够执行用于根据提取的所述Payload和所述SQL执行语句判断目标程序中是否潜藏了与所述Payload相应的SQL注入漏洞的操作；其中，包括：分析单元，被配置得能够根据提取的所述Payload的原始输入和所述SQL执行语句，判断是否有所述Payload或与所述Payload构造相似的有害数据进入所述SQL执行语句；如是，判断目标程序中潜藏了相应的SQL注入漏洞；

扫描单元，被部署在扫描端；扫描单元，被配置得能够执行用于以携带有攻击SQL注入漏洞的Payload的HTTP请求攻击服务端的目标程序的操作。

6.根据权利要求5所述的系统，其特征在于，

所述的插桩单元，还被配置得能够执行用于对目标程序插桩相应的辅助探针；其中的辅助探针，用于从所述HTTP请求的数据报文中提取所述Payload的原始输入，和/或，获取目标程序返回给测试端的响应报文；

其中，所述的响应报文，用于分析检出的所述SQL注入漏洞的注入点。

7.根据权利要求5或6任一所述的系统，其特征在于，

所述的插桩单元，被配置得通过运行时插桩的方式，对目标程序插桩相应的探针。

8.根据权利要求5所述的系统，其特征在于，

所述的在调用SQL语句对象的函数的插桩探针，在获取所述SQL执行语句的同时，获取相应的函数调用栈信息；所述的函数调用栈信息，包括能够确定SQL注入漏洞触发的代码行信息；所述函数调用栈信息，用于准确定位所述SQL注入漏洞的位置。

9.根据权利要求5所述的系统，其特征在于，

所述分析单元，被部署在服务端；其中包括：

配置得使所述的在调用SQL语句对象的函数的插桩探针，还能够执行所述分析单元的操作，检测目标程序中是否潜藏了与所述Payload相应的SQL注入漏洞。

10.一种计算机可读存储介质，其特征在于，

该介质上存储有用于SQL注入漏洞检测相关的计算机指令，

该计算机指令在被计算机处理器执行时能够实现权利要求1-4任一所述的基于主动IAST的SQL注入漏洞检测的方法或所述方法中的部分操作。

Images