CN115623485B - 一种短信轰炸检测方法、系统、服务器及存储介质 - Google Patents

Abstract

本申请提供一种短信轰炸检测方法、系统、服务器及存储介质，方法包括：获取用户的请求信息，判断请求信息是否产生流量，若是，基于请求信息获得请求信息触发的http请求和请求信息所对应的原始流量包，其中，原始流量包包括原始请求包和原始响应包；判断http请求中的请求头部是否指向设定API，若否，请求信息不是短信信息，不存在短信轰炸漏洞；否则，将原始流量包发送给扫描器，通过扫描器验证是否存在短信轰炸漏洞。本申请先通过被动检测到发送短信的流量包，然后再通过扫描器主动扫描检测漏洞是否存在，在不影响原本工作的前提下，获取到发送短信的数据包，实现对短信轰炸漏洞的检测。

Description

一种短信轰炸检测方法、系统、服务器及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种短信轰炸检测方法、系统、服务器及存储介质。

背景技术

移动通信业务的发展和移动设备的普及，使得移动设备逐渐成为人们生活中不可获取的通讯工具，该移动设备会接收到不同类型的请求，比如短信请求、视频请求、通话请求以及社交请求等等。使得移动设备也会接收到不同类型的流量包。

随着短信业务的发展，越来越多的商家利用短信来传播广告，内容为广告的短信开始越来越多，各种广告短信开始困扰广大手机用户，同时，带有欺骗性质的短信及其它非法内容的短信开始越来越多。目前可以采用增加人工验证的方式来防御短信轰炸，如增加图形验证码，防止轰炸人机自动化调用发送验证码短信；也可以采用在移动端打造一键验证方案替换短信验证码方式。然而移动设备可接收若干种不同类型的请求，仅通过上述方法无法在移动设备接收到的若干种类型的流量包中有效识别出发送短信的流量包，即无法有效防御短信轰炸。

发明内容

本申请先通过被动检测到发送短信的流量包，然后再通过扫描器主动扫描检测漏洞是否存在，在不影响原本工作的前提下，获取到发送短信的数据包，有效实现对短信轰炸漏洞的检测。

第一方面，本实施例提供了一种短信轰炸检测方法，所述方法包括：

获取基于用户请求信息所对应的原始流量包以及与所述原始流量包相对应的http请求，其中，所述原始流量包包括原始请求包和原始响应包；

判断所述http请求中的请求头部是否指向设定API，若否，生成表征不存在短信轰炸漏洞的无漏洞指令；否则，基于所述原始流量包获得服务器根据所述原始流量包所作出反应的验证响应包，判断所述验证响应包和所述原始响应包是否都一致，若都一致，生成表征存在短信轰炸漏洞的有漏洞指令；若不都一致，判断所述验证响应包中是否都存在发送成功的关键字，若存在，生成表征存在短信轰炸漏洞的有漏洞指令。

在其中的一些实施例中，所述判断所述http请求中的请求头部是否指向设定API包括：

基于所述设定API获取与所述设定API相对应的请求头部，判断所述http请求中的请求头部与所述设定API相对应的请求头部是否相同，若相同，所述http请求中的请求头部指向设定API；否则，所述http请求中的请求头部不指向设定API。

在其中的一些实施例中，基于所述原始流量包获得服务器根据所述原始流量包所作出反应的验证响应包包括：

将所述原始流量包发送给扫描器，所述扫描器接收所述原始流量包，并对所述原始流量包进行存储；

所述扫描器多次向服务器发送所述原始请求包，并存储所述服务器根据所述原始请求包所作出反应的验证响应包。

在其中的一些实施例中，所述判断所述验证响应包中是否都存在发送成功的关键字之后还包括：

所述验证响应包中不是都存在发送成功的关键字时，修改所述原始请求包来获得最新请求包，基于所述最新请求包来验证是否存在短信轰炸漏洞。

在其中的一些实施例中，所述基于所述最新请求包来验证是否存在短信轰炸漏洞包括：

所述扫描器向所述服务器多次发送所述最新请求包，并存储所述服务器根据所述最新请求包所作出反应的最新响应包；

判断多个所述最新响应包和所述原始响应包是否都一致，若所述最新响应包和所述原始响应包都一致，生成表征存在短信轰炸漏洞的有漏洞指令；若所述最新响应包和所述原始响应包不一致，判断多个所述最新响应包中是否都存在发送成功的关键字，若是，生成表征存在短信轰炸漏洞的有漏洞指令；否则，生成表征不存在短信轰炸漏洞的无漏洞指令。

在其中的一些实施例中，所述修改所述原始请求包来获得最新请求包包括对所述原始请求包中的字符串进行修改获得最新请求包来绕过手机号和IP的检测。

第二方面，本实施例提供了一种短信轰炸检测系统，所述系统检测模块，所述检测模块包括接收单元、判断单元、生成单元以及处理单元；其中，

所述接收单元，用来获取基于用户请求信息所对应的原始流量包以及与所述原始流量包相对应的http请求，其中，所述原始流量包包括原始请求包和原始响应包；

所述判断单元，用来判断所述http请求中的请求头部是否指向设定API；

所述生成单元，用来若所述http请求中的请求头部不指向设定API，生成表征不存在短信轰炸漏洞的无漏洞指令；

所述处理单元，用来基于所述原始流量包获得服务器根据所述原始流量包所作出反应的验证响应包；

所述判断单元，还用来判断所述验证响应包和所述原始响应包是否都一致；

所述生成单元，还用来若所述验证响应包和所述原始响应包一致，生成表征存在短信轰炸漏洞的有漏洞指令；

所述判断单元，还用来若所述验证响应包和所述原始响应包不一致，判断所述验证响应包中是否都存在发送成功的关键字；

所述生成单元，还用来若所述验证响应包中都存在发送成功的关键字，生成表征存在短信轰炸漏洞的有漏洞指令。

在其中一些实施例中，所述系统还包括验证单元，用来所述验证响应包中不是都存在发送成功的关键字时，修改所述原始请求包来获得最新请求包，基于所述最新请求包来验证是否存在短信轰炸漏洞。

第三方面，本申请实施例提供了一种服务器，所述服务器包括：处理器和存储器，所述存储器上存储有能在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的短信轰炸检测方法。

第四方面，本申请实施例提供了一种存储介质，其上存储有能在处理器上运行的计算机程序，其特征在于，所述计算机程序被所述处理器执行时实现如第一方面所述的短信轰炸检测方法。

通过采用上述方案，获取用户的正常请求，该请求会产生流量，然后在产生流量之后，该请求后端会涉及到http请求，也会获得流量包，该流量包中包括请求包和响应包。另外，我们将市面上的短信接口进行收集，并确定为设定API。然后，通过判断http请求中的请求头部是否和设定API所对应的请求头部相同，若不相同，http请求中的请求头部不指向设定API，此时的请求信息不是短信信息，也就不会存在短信轰炸漏洞；若相同，http请求中的请求头部指向设定API，此时的请求信息是短信信息，需要将原始流量包发送给扫描器，通过扫描器主动验证是否存在短信轰炸漏洞，通过对比是否是设定API对发送短信的接口进行获取，从而解决完全无法自动识别发送短信接口的问题。其中，在主动验证过程中，通过先后验证响应包和关键字来确定是否存在短信轰炸漏洞，另外，还通过修改请求包进行绕过，来减少漏报的可能性，进一步提升漏洞识别率。

附图说明

图1是本实施例提供的一种短信轰炸的原理示意图。

图2是本实施例提供的一种短信轰炸检测方法框图。

图3是本实施例提供的一种短信轰炸检测系统框图。

图4是本实施例提供的服务器的结构框图。

具体实施方式

为更清楚地理解本申请的目的、技术方案和优点，下面结合附图和实施例，对本申请进行了描述和说明。然而，本领域的普通技术人员应该明白，可以在没有这些细节的情况下实施本申请。对于本领域的普通技术人员来说，显然可以对本申请所公开的实施例作出各种改变，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请不限于所示的实施例，而是符合与本申请所要求保护的范围一致的最广泛范围。

下面结合说明书附图对本申请实施例作进一步详细描述。

短信轰炸是指短时间内向受害者手机发送大量短信，影响手机正常使用的一种违法行为。图1是本实施例提供的一种短信轰炸的原理示意图。如图1所示，恶意攻击者在前端页面输入被攻击者的手机号，短信轰炸后台服务器将该手机号与互联网收集的可不需要经过验证即可发送动态短信的URL进行组合，形成可发送动态短信的URL请求。然后通过后台请求页面，伪造用户的请求发送给不同的业务服务器，这样业务服务器接收到该请求后，就会发送动态短信到被攻击用户的手机上，导致手机用户被骚扰。

图2是本实施例提供的一种短信轰炸检测方法流程图。如图2所示，该方法包括以下步骤：

步骤S100，获取基于用户请求信息所对应的原始流量包，以及与所述原始流量包相对应的http请求，其中，原始流量包包括原始请求包和原始响应包。

上述用户请求信息是根据用户的实际需要来进行获取的，该请求信息不仅仅只限于是短信信息，还可以是视频信息，社交信息、推送信息以及邀请信息等等。用户通过网络将该请求信息发送给指定接收人。因此，在将该请求信息发送给指定接收人时必定会产生一定的流量。

其中，在获取基于用户请求信息所对应的原始流量包之前还需要核验流量的大小是否在预设范围内。具体的，判断流量的大小是否在预设范围内，若在预设范围内，表征服务器可以正常响应其请求，则获取基于用户请求信息所对应的原始流量包，以及用户请求信息触发的http请求；若不在预设范围内，表征该请求需要占用大量的服务器资源，在没有特殊要求的情况下则舍弃该请求信息，不获取基于用户请求信息所对应的原始流量包，以及用户请求信息触发的http请求。其中，流量大小的识别方法包括但不限于使用代理服务器进行流量大小的统计，由于代理服务器具有记录流量的日志功能，因此可以通过读取代理服务器的日志文件来完成网络流量数据的采集；也可以直接使用路由器进行流量大小的统计，通过路由器内部功能来实现流量数据的采集。

基于流量，IAST能够看到http请求和响应。因此，在指定接收人在接收到该请求信息的过程中，请求信息的后端会涉及到http请求，同时也会触发hook，该hook点主要为各种涉及http请求的函数，该hook就是插桩修改代码的字节码，在程序源码之外添加额外的执行逻辑，这些添加的逻辑包括但不限于，对方法的参数、返回值以及当前对象等进行保存。而且也会基于该请求信息生成相应的原始流量包，该原始流量包中包括原始请求包和原始响应包，该原始请求包与当前的请求信息相对应，该原始响应包表征对该原始请求包的内容作出反应。

一般的接口都会被请求调用，比如阿里云的接口，其后台有一个调用的函数，会有http请求，首先判断是否有带有请求信息的流量经过了这个函数，若是的话，就需要判断该流量包中的host头是否指向设定的API。

步骤S200，判断http请求中的请求头部是否指向设定API，若否，生成表征不存在短信轰炸漏洞的无漏洞指令。

在一个实施例中，判断http请求中的请求头部是否指向设定API包括基于设定API获取与设定API相对应的请求头部，判断http请求中的请求头部与设定API相对应的请求头部是否相同，若相同，http请求中的请求头部指向设定API；否则，http请求中的请求头部不指向设定API。

上述的设定API是指市面上第三方发送短信的API。由于市面上大多都是通过调用三方API进行发送短信，只要设定API收集足够完善，就能够抓取到市面上绝大部分的短信接口。该设定API包含有市面上存在的若干种短信接口。

设定API中的每一个短信接口都有一个相对应的请求头部，当服务器接收到来自http请求时，会根据http请求中的请求头部的host字段访问相应的端口。比如，一台服务器的IP地址为120.79.92.223，有三个分别为百度、谷歌和搜狐的域名解析到了这三个网站上，当我们通过百度这个网址去访问时，DNS解析出的IP为120.79.92.223，这时候服务器就是根据请求头中的host字段选择使用百度这个域名的网址程序对请求做响应，而不是使用其它域名的网址程序对请求做响应，这是因为host请求头起着决定性的作用。因此当http请求中的请求头部和若干个设定API中的任意一个相对应的请求头部相同，就可以确定http请求中的请求头部指向设定API；若http请求中的请求头部和若干个设定API中的所有相对应的请求头部都不相同，那么http请求中的请求头部不指向设定API，此时表明当前请求信息并不是短信信息，不存在短信轰炸漏洞，生成表征不存在短信轰炸漏洞的无漏洞指令。

在上述实施例中，通过对比是否是三方发送的API对发送短信的接口进行获取，即被动识别到三方API来获取到短信接口，从而解决完全无法自动识别发送短信接口的问题。

步骤S300，若请求头部指向设定API，基于所述原始流量包获得服务器根据所述原始流量包所作出反应的验证响应包，判断所述验证响应包和所述原始响应包是否都一致，若都一致，生成表征存在短信轰炸漏洞的有漏洞指令；若不都一致，判断所述验证响应包中是否都存在发送成功的关键字，若存在，生成表征存在短信轰炸漏洞的有漏洞指令。

在http请求中的请求头部指定设定API时，需要将该原始流量包发送给扫描器，通过扫描器验证是否存在短信轰炸漏洞，这是一个主动检测短信轰炸漏洞的过程。

在一个实施例中，基于原始流量包获得服务器根据原始流量包所作出反应的验证响应包包括：将原始流量包发送给扫描器，扫描器接收原始流量包，并对原始流量包进行存储；扫描器多次向服务器发送原始请求包，并存储服务器根据原始请求包所作出反应的验证响应包。

在主动检测短息轰炸漏洞的过程中，首先将当前请求信息所对应的流量包发送给扫描器，扫描器并对该流量包进行存储。然后扫描器就通过多次重复向服务器发送相同的原始请求包，同时服务器将该原始请求包所对应的验证响应包返回给扫描器，扫描器并将该验证响应包也进行存储。比如，在将短信进行发送之后，会接收到一个关于发送成功或者发送失败的信息，此时请求包中包含有短信信息，响应包中包含有发送成功或者发送失败的信息。重复向服务器发送相同的原始请求包是为了验证漏洞是否存在，次数越多验证的准确性就会越高，但是相应的成本也会增加，为了平衡准确性和成本，该次数可优选五次，既可以控制成本也可以达到验证漏洞的作用。

在将原始请求包频繁地发送给服务器时，若不存在短信轰炸漏洞时，服务器需要对该频繁发送的行为进行一定程度的制止或者标记。因此通过将原始响应包和验证响应包进行对比就可以初步确定是否存在短信轰炸漏洞，可以把原始响应包和验证响应包进行hex对比，通过查看内容是否一致来确定原始响应包和验证响应包是否一致，其中，验证响应包有若干个，其数量和将原始请求包重复发送给服务器的数量是一致的，若每一个验证响应包都和原始响应包一致，那么可以确定存在短信轰炸漏洞，生成表征存在短信轰炸漏洞的有漏洞指令；若不一致，可以进一步通过查看验证响应包中的关键字来确定是否存在短信轰炸漏洞。

在原始请求包发送成功后，与其相对应的验证响应包中会有表明发送成功的关键字，通过查看每一个验证响应包中是否含有该关键字即可。只有每一个验证响应包中都含有该关键字才可以表明存在短信轰炸漏洞，只要有一个验证响应包中不含有该关键字，则表明与该验证响应包相对应的那一次发送原始请求包的操作被服务器进行了拦截，没有成功发送给服务器，无法判断一定存在短信轰炸漏洞。通过查看验证响应包中的关键字可以减少漏报，提高精准性。

在一个实施例中，验证响应包中不是都存在发送成功的关键字时，修改原始请求包来获得最新请求包，基于最新请求包来验证是否存在短信轰炸漏洞。

其中，修改原始请求包来获得最新请求包包括对原始请求包中的字符串进行修改获得最新请求包来绕过手机号和IP的检测。原始流量包就是一个文本，里面存有字符串，通过bypass手段来进行绕过，具体有手机号后面添加空格、%20、逗号以及分号等分隔字符进行绕过手机号检测，通过XFF头绕过IP检测，从而介绍漏报的可能性，进一步提升漏洞识别率，其中，XFF头为X-Forwarded-For的缩写。比如，在绕过手机号检测过程中，先通过正则匹配来获得的手机号的位置，然后对手机号后面添加一个空格或者逗号等操作，绕过后台来进行操作，这是对于逻辑的一个绕过。

在使用修改之后的最新请求包来验证是否存在短信轰炸漏洞时，扫描器向服务器多次发送最新请求包，并存储服务器根据最新请求包所作出反应的最新响应包；判断多个最新响应包和原始响应包是否都一致，若最新响应包和原始响应包都一致，生成表征存在短信轰炸漏洞的有漏洞指令；若最新响应包和原始响应包不一致，判断多个最新响应包中是否都存在发送成功的关键字，若是，生成表征存在短信轰炸漏洞的有漏洞指令；否则，生成表征不存在短信轰炸漏洞的无漏洞指令。

扫描器在向服务器每次发送的最新请求包都不同，若此时得到的多个最新响应包还是和原始响应包一致，则表明对原始请求包所做的修改绕过手机号和IP的检测后还是得到相同的响应，此时存在短信轰炸的漏洞，生成表征存在短信轰炸漏洞的有漏洞指令。若此时得到的多个最新响应包和原始响应包不一致，且若干个最新响应包中至少有一个不存在发送成功的关键字，则表明可以对不存在发送成功关键字所对应的请求包修改的操作进行拦截，可以确定不存在短信轰炸漏洞，生成表征不存在短信轰炸漏洞的无漏洞指令；若所有的最新响应包中都存在发送成功的关键字，则表明不会对最新请求包进行拦截，可以确定存在短信轰炸漏洞，生成表征存在短信轰炸漏洞的有漏洞指令。

在本实施例中，首先获取用户的正常请求，该请求会产生流量；然后在产生流量之后，该请求后端会涉及到http请求，也会获得流量包，同时也会触发hook点，该hook点主要为各种涉及http请求的函数，该hook就是插桩修改代码的字节码，在程序源码之外添加额外的执行逻辑，这些添加的逻辑包括但不限于，对方法的参数、返回值以及当前对象等进行保存。另外，通过将市面上的短信接口进行收集，并确定为设定API。通过判断http请求中的请求头部host是否和设定API所对应的请求头部相同，若不相同，http请求中的请求头部不指向设定API，此时的请求信息不是短信信息，不存在短信轰炸漏洞；若相同，http请求中的请求头部指向设定API，此时的请求信息是短信信息。通过对比是否是三方发送的api对发送短信的接口进行获取，从而解决完全无法自动识别发送短信接口的问题，由于市面上大多都是通过调用三方api进行发送短信，理论上只要api收集足够完善，就能抓取到市面上9成以上的短信接口。

在http请求中的请求头部指向设定API时，需要将原始流量包发送给扫描器，通过重发多次流量包来得到所有请求包所对应的关于响应包的列表，比较原始响应包和验证响应包是否一致，在一致的情况下，确定存在短信轰炸漏洞，生成表征存在短信轰炸漏洞的有漏洞指令，不一致的情况下，继续查看所有验证响应包是否存在发送成功的关键字，若有，则确定存在短信轰炸漏洞，生成表征存在短信轰炸漏洞的有漏洞指令，否则需要对原始请求包进行修改来绕过限制手段，来绕过手机号和/或IP检测的检测。即在简单的重发包对比之后，还对关键字进行了对比，并且在关键字对比之后，通过bypass手段进行修改来绕过检测，具体bypass手段有如下操作：手机号后面添加空格、%20、逗号以及分号等分隔字符进行绕过手机号检测；通过XFF等头绕过IP检测。从而减少程序漏报的可能，进一步提升漏洞识别率。

继续对比最新响应包和原始响应包是否一致，若修改原始请求包后还一致，可以确定存在短信轰炸漏洞，生成表征存在短信轰炸漏洞的有漏洞指令，若存在最新响应包与原始响应包不一致，再看是否都存在发送成功的关键字，若是的话，可以确定存在短信轰炸漏洞，生成表征存在短信轰炸漏洞的有漏洞指令，若不是的话，可以确定不存在短信轰炸漏洞，生成表征不存在短信轰炸漏洞的无漏洞指令。本实施例通过被动识别到三方api，获取到短信接口，再通过扫描器重发多次发送数据包来验证短信轰炸漏洞，从而达到识别短信轰炸漏洞。

图3是本实施例提供的一种短信轰炸检测系统框图。如图3所示，一种短信轰炸检测系统包括检测模块，所述检测模块包括接收单元、判断单元、生成单元以及处理单元；其中，接收单元，用来获取基于用户请求信息所对应的原始流量包以及与所述原始流量包相对应的http请求，其中，原始流量包包括原始请求包和原始响应包。判断单元，用来判断http请求中的请求头部是否指向设定API。生成单元，用来若http请求中的请求头部不指向设定API，生成表征不存在短信轰炸漏洞的无漏洞指令。处理单元，用来基于原始流量包获得服务器根据原始流量包所作出反应的验证响应包。判断单元，还用来判断验证响应包和所述原始响应包是否都一致。生成单元，还用来若验证响应包和原始响应包一致，生成表征存在短信轰炸漏洞的有漏洞指令。判断单元，还用来若验证响应包和原始响应包不一致，判断验证响应包中是否都存在发送成功的关键字。生成单元，还用来若验证响应包中都存在发送成功的关键字，生成表征存在短信轰炸漏洞的有漏洞指令。

一种短信轰炸检测系统还包括验证单元，用来所述验证响应包中不是都存在发送成功的关键字时，修改原始请求包来获得最新请求包，基于最新请求包来验证是否存在短信轰炸漏洞。

该系统通过被动识别到三方API，获取到短信接口，解决了无法识别发送短信的接口的流量包的问题；接着通过对比是否是第三方发送的API对发送短信的接口进行获取，从而解决自动获取到发送短信的接口；最后通过扫描器多次重发流量包来验证短信轰炸漏洞，从而在众多流量包中识别出发送短信的流量包，进一步对短信轰炸漏洞进行识别。

图4是本实施例提供的服务器的结构框图。如图4所示，该服务器包括处理器41和存储器42，其中，存储器42上存储有能在处理器41上运行的计算机程序43，该计算机程序43被处理器41执行时实现本申请实施例提供的一种短信轰炸检测方法。

存储器42可以是ROM或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器，或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器、只读光盘或其他光盘存储、光碟存储（包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等）、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器42在一些实施例中可以是内部存储单元。

处理器41可以是中央处理器，通用处理器，数据信号处理器，专用集成电路，现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。用于运行存储器42中存储的程序代码或处理数据。

处理器41和存储器42通过总线连接。总线可包括一通路，在上述组件之间传送信息。总线可以是外设部件互连标准总线或扩展工业标准结构总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

图4仅示出了具有存储器42、处理器41、总线的服务器，本领域可以理解的是，图4所示的结构并不构成对服务器的限定，既可以是总线型结构，也可以是星形结构，服务器还可以包括比图示更多或者更少的部件，或者组合某些部件，或者不同的部件部署。其它现有的或今后可能出现的电子设备如何使用，也应包含在保护范围内，并以引用方式包含于此。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相关内容。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确地说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种短信轰炸检测方法，其特征在于，所述方法包括：

获取基于用户请求信息所对应的原始流量包，以及与所述原始流量包相对应的http请求，其中，所述原始流量包包括原始请求包和原始响应包；

判断所述http请求中的请求头部是否指向设定API，其中，所述设定API指第三方发送短信的API，若否，生成表征不存在短信轰炸漏洞的无漏洞指令；否则，基于所述原始流量包获得服务器根据所述原始流量包所作出反应的验证响应包，判断所述验证响应包和所述原始响应包是否都一致，若都一致，生成表征存在短信轰炸漏洞的有漏洞指令；若不都一致，判断所述验证响应包中是否都存在发送成功的关键字，若存在，生成表征存在短信轰炸漏洞的有漏洞指令。

2.根据权利要求1所述的方法，其特征在于，所述判断所述http请求中的请求头部是否指向设定API包括：

基于所述设定API获取与所述设定API相对应的请求头部，判断所述http请求中的请求头部与所述设定API相对应的请求头部是否相同，若相同，所述http请求中的请求头部指向设定API；否则，所述http请求中的请求头部不指向设定API。

3.根据权利要求1所述的方法，其特征在于，基于所述原始流量包获得服务器根据所述原始流量包所作出反应的验证响应包包括：

将所述原始流量包发送给扫描器，所述扫描器接收所述原始流量包，并对所述原始流量包进行存储；

所述扫描器多次向服务器发送所述原始请求包，并存储所述服务器根据所述原始请求包所作出反应的验证响应包。

4.根据权利要求3所述的方法，其特征在于，所述判断所述验证响应包中是否都存在发送成功的关键字之后还包括：

所述验证响应包中不是都存在发送成功的关键字时，修改所述原始请求包来获得最新请求包，基于所述最新请求包来验证是否存在短信轰炸漏洞。

5.根据权利要求4所述的方法，其特征在于，所述基于所述最新请求包来验证是否存在短信轰炸漏洞包括：

所述扫描器向所述服务器多次发送所述最新请求包，并存储所述服务器根据所述最新请求包所作出反应的最新响应包；

判断多个所述最新响应包和所述原始响应包是否都一致，若所述最新响应包和所述原始响应包都一致，生成表征存在短信轰炸漏洞的有漏洞指令；若所述最新响应包和所述原始响应包不一致，判断多个所述最新响应包中是否都存在发送成功的关键字，若是，生成表征存在短信轰炸漏洞的有漏洞指令；否则，生成表征不存在短信轰炸漏洞的无漏洞指令。

6.根据权利要求4所述的方法，其特征在于，所述修改所述原始请求包来获得最新请求包包括对所述原始请求包中的字符串进行修改获得最新请求包来绕过手机号和IP的检测。

7.一种短信轰炸检测系统，其特征在于，所述系统包括检测模块，所述检测模块包括接收单元、判断单元、生成单元以及处理单元；其中，

所述接收单元，用来获取基于用户请求信息所对应的原始流量包以及与所述原始流量包相对应的http请求，其中，所述原始流量包包括原始请求包和原始响应包；

所述判断单元，用来判断所述http请求中的请求头部是否指向设定API，其中，所述设定API指第三方发送短信的API；

所述生成单元，用来若所述http请求中的请求头部不指向设定API，生成表征不存在短信轰炸漏洞的无漏洞指令；

所述处理单元，用来若所述http请求中的请求头部指向设定API，基于所述原始流量包获得服务器根据所述原始流量包所作出反应的验证响应包；

所述判断单元，还用来判断所述验证响应包和所述原始响应包是否都一致；

所述生成单元，还用来若所述验证响应包和所述原始响应包都一致，生成表征存在短信轰炸漏洞的有漏洞指令；

所述判断单元，还用来若所述验证响应包和所述原始响应包不都一致，判断所述验证响应包中是否都存在发送成功的关键字；

所述生成单元，还用来若所述验证响应包中都存在发送成功的关键字，生成表征存在短信轰炸漏洞的有漏洞指令。

8.根据权利要求7所述的系统，其特征在于，所述系统还包括验证单元，用来所述验证响应包中不是都存在发送成功的关键字时，修改所述原始请求包来获得最新请求包，基于所述最新请求包来验证是否存在短信轰炸漏洞。

9.一种服务器，其特征在于，所述服务器包括：处理器和存储器，所述存储器上存储有能在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至6中任意一项所述的一种短信轰炸检测方法。

10.一种存储介质，其上存储有能在处理器上运行的计算机程序，其特征在于，所述计算机程序被所述处理器执行时实现如权利要求1至6中任意一项所述的一种短信轰炸检测方法。

Images