一种防止恶意请求的方法及装置与流程

文档序号:16900314发布日期:2019-02-19 17:55阅读:559来源:国知局
一种防止恶意请求的方法及装置与流程

本发明涉及到网络安全技术,特别是涉及到服务器端相关的主动安全防护技术。



背景技术:

随着互联网的高速发展,网络恶意攻击已经成为业界不可忽视的问题。网络恶意攻击可以是为达到一定目的而采取的非正常手段,如,网络攻击、恶意请求等。在网络环境中,网络恶意行为可以在极短的时间内致使网站不能正常为用户提供服务,这严重影响了互联网的正常运作。

恶意请求,可以是通过应用程序,在一段时间内,不断的向服务器发送的、并影响服务器正常运作的超文本传输协议网络请求。例如,通过这种方式干扰正常用户的网络行为或者以此攻击一个web网站。由于这些请求非常密集,给服务器造成了巨大的压力。

在现有技术中,web网站为了应对恶意请求给服务器和/或用户带来的问题,可以通过web服务器或应用服务器对恶意请求进行拦截。

例如通过调用签名技术来进行恶意请求的防止技术,所谓调用签名技术是指调用接口需要验证额外信息,一般由服务提供者给使用者提供一组调用密钥和配套的加密算法,调用方在正常的请求参数上附加调用密钥经算法运算的值,服务提供者在收到请求时先验证签名是否有效,签名无效的请求直接响应错误值。

还例如通过限制接口必须在某些固定的场景才有效,比如限制发送短信验证码的接口调用必须在发送验证码同域的网站甚至页面上,或者满足一些前提条件,比如用户需要先登录,录入了某些信息等。

或者是限制单一服务消费者使用服务的频率,通常为一小段时间内请求数量限制和一天内请求数量限制二种衡量方式同时应用,避免服务器短时间内单一消费者大量请求导致服务中断或影响整体服务体验。

更加严格的防止恶意请求技术例如自定义通信协议技术,通常指发布rpc服务,自己定义数据的组织方式,因为数据是二进制传输,数据报文不易被第三方所获取,从而避免非认证使用。

另一种严格的防止恶意请求技术例如网络限制服务,将服务范围限制在某一网络范围内,不对外提供,从而避免接口滥用。

但是,现有技术中这些防止恶意请求的技术往往存在各种缺陷,例如调用签名技术掌握了签名规则的用户可以恶造请求访问接口,或者接口正常消费者逻辑设计不健全或缺陷导致接口大量访问或者恶意消费,比如a提供服务给b使用,但是b使用a接口的接口被其它用户恶意使用,导致系统流量井喷,服务水平下降。在web上的应用,即使攻击者没有掌握签名算法和密钥,但是通过模拟点击等操作也能按照正常调用方式进行攻击,此时调用签名如同虚设。

又例如对于限制来源技术中,通过返回模糊的错误说明能在一定程度上能减少攻击难度,杜绝其它环境直接调用接口,但是不能阻止模拟请求造成的大量恶意请求。

即使是限流技术,主要应用于后端接口访问,虽然能够阻止一些恶意访问请求,但是可能造成正常请求也受到影响,比如活动时业务激增导致访问问题,或者不同消费者的需求不一样,有些消费者在某些时间段内需要较高的频次,比如打卡,有些业务需求调用量大,导致限流规则不统一,复杂。

对于所述的自定义通信协议技术,其缺陷在于该技术一般仅限制于内部服务通讯,并且也会发生和调用签名一样的问题。

而对于所述的网络限制服务技术,其也具有仅支持内网访问或特定ip访问接口,无法给其它用户提供服务,它的消费者同样可能面临漏洞而被利用的缺陷。

至于一些更为常见的主动防止恶意请求技术,例如采用应用服务器拦截恶意请求,对于web服务器转发的网络请求,可以在处理业务数据之前对发送网络请求的用户进行身份验证,例如,进行黑名单检查,查看该用户是否有发送恶意请求的不良记录,若存在不良记录则可以限制正常的业务流程,对用户的网络请求进行拦截。该黑名单检查可以通过预先对大量的用户数据进行分析,找出发送恶意请求的用户,并列入黑名单中。该方法可以通过黑名单检查的方式减少误判。但是,该方法所生成的黑名单不能实时的对恶意请求进行拦截。因为,黑名单是通过对一段时间内的用户数据进行分析而得出,并更新之前的黑名单。对于新增的发送恶意请求的用户,即,尚未加入黑名单的用户,会造成大量的漏判,影响服务器的正常工作以及其他用户正常使用。

由以上分析可以看出,目前的恶意请求拦截或者防范措施中,存在各种问题,对于需要向公众开放,提供大量、各种类型服务的服务器而言,这些技术都存在例如难以阻止模拟请求造成的大量恶意请求、业务需求调用量大,导致限流规则不统一,复杂等技术问题,很难做到真正的恶意请求防范。



技术实现要素:

本发明的目的在于克服现有技术的恶意请求拦截或者防范措施中,对于需要向公众开放,提供大量、各种类型服务的服务器而言,这些拦截或者防范措施都存在例如难以阻止模拟请求造成的大量恶意请求、业务需求调用量大,导致限流规则不统一,复杂等技术问题,很难做到真正的恶意请求防范的技术问题,提出一种防止恶意请求的方法及装置。

为解决上述技术问题,本发明采用如下技术方案。

一种防止恶意请求的方法,所述方法包括步骤:

a、当用户终端向服务器发送业务请求时,服务器前端应用请求后端服务是否需要验证码;

b、如果后端服务需要验证码,则服务器前端应用向终端要求输入验证码,终端向服务器发送验证码请求后,后端服务向终端发送验证码,待终端向前端应用返回验证码信息后,后端服务拦截终端的一个以上指标;

c、根据后端服务拦截终端的一个以上指标,分析恶意请求可能性,当恶意请求可能性高于预定阈值时,后端服务通过前端应用要求终端输入额外验证码。

其中,所述后端服务记录终端的一个以上指标包括终端的网络地址、终端所使用浏览器及版本、终端操作系统、用户名称、手机号码中的一个或以上,所述后端服务拦截终端的一个以上指标包括后端服务产生一个以上拦截器,所述一个以上拦截器分别拦截终端向前端程序返回的所述一个以上指标。

另外,所述根据后端服务拦截终端的一个以上指标,分析恶意请求可能性包括,服务器统计一定时间内所述一个以上指标分别与恶意请求产生关联的概率,以各项指标与恶意请求产生关联的概率的加权和为总的恶意请求可能性。

特别地,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d1、服务器限定接口调用的参考字段,通过模糊或者错误的错误提示混淆可能的恶意请求终端,使其不能确定调用失败的原因,增加调用难度,避免通过其它脚本对接口的调用。

或者,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d2、由终端脚本在接口调用前通过特定方式产生调用令牌,并关联后端服务,当下一次请求携带的令牌在服务器中找不到相应资源时,则提示超时,终端必须重新发起业务请求流程。

又或者,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d3、对于短时间内发送大量业务请求的终端可在预定一段时间内对其拒绝访问,所述确定终端需要同时考虑网络地址和用户设备编号、浏览器类型,浏览器版本,操作系统版本中的一个或多个。

另外,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d4、可以基于地址和接口授权策略对终端发出业务请求的频率进行限制,终端要发出业务请求时,必须取得一个具有时限和次数的令牌,每次发出业务请求前需要访问服务器的令牌接口获取一个令牌,如果后端服务验证它可以申请业务就授予令牌,从而接受其业务请求,否则不返回令牌。

一种防止恶意请求的装置,所述装置包括前端应用单元,后端服务单元,恶意请求分析单元,其中,

前端应用单元用于请求后端服务是否需要验证码,以及向终端要求输入验证码并接收终端输入的验证码;

后端服务单元用于拦截终端向前端程序返回的所述一个以上指标,将所述一个以上指标交给恶意请求分析单元;

所述恶意请求分析单元用于根据后端服务单元拦截终端向前端程序返回的所述一个以上指标,分析恶意请求可能性。

其中,所述装置还包括调用令牌生成单元,所述调用令牌生成单元用于由终端脚本在接口调用前通过特定方式产生调用令牌,并关联后端服务,当下一次请求携带的令牌在服务器中找不到相应资源时,则提示超时,终端必须重新发起业务请求流程。

另外,所述装置还包括访问屏蔽单元,所述访问屏蔽单元用于对于短时间内发送大量业务请求的终端可在预定一段时间内对其拒绝访问,所述确定终端需要同时考虑网络地址和用户设备编号、浏览器类型,浏览器版本,操作系统版本中的一个或多个。

首先,通过本发明的防止恶意请求的方法及装置,发送验证码请求降低,一方面节约了成本,另一方面,多个验证码同时到达时容易产生混淆,分辨不清楚正确的验证码,从而另一方面也缓解多次发送仍然输入不对的问题,短信轰炸,恶意请求消失。

其次,通过本发明的防止恶意请求的方法及装置,利用消息接口屏蔽了大量恶意请求,避免了服务器压力过大,产生错误,从而保障了其它用户的体验。

附图说明

图1是根据本发明一具体实施方式中防止恶意请求方法的具体流程示意图。

图2是根据本发明另一具体实施方式中防止恶意请求方法的具体流程示意图。

图3是根据本发明另一具体实施方式中防止恶意请求方法的具体流程示意图。

具体实施方式

下面结合附图,对本发明作详细说明。

以下公开详细的示范实施例。然而,此处公开的具体结构和功能细节仅仅是出于描述示范实施例的目的。

然而,应该理解,本发明不局限于公开的具体示范实施例,而是覆盖落入本公开范围内的所有修改、等同物和替换物。在对全部附图的描述中,相同的附图标记表示相同的元件。

参阅附图,本说明书所附图式所绘示的结构、比例、大小等,均仅用以配合说明书所揭示的内容,以供熟悉此技术的人士了解与阅读,并非用以限定本发明可实施的限定条件,故不具技术上的实质意义,任何结构的修饰、比例关系的改变或大小的调整,在不影响本发明所能产生的功效及所能达成的目的下,均应仍落在本发明所揭示的技术内容得能涵盖的范围内。同时,本说明书中所引用的位置限定用语,亦仅为便于叙述的明了,而非用以限定本发明可实施的范围,其相对关系的改变或调整,在无实质变更技术内容下,当亦视为本发明可实施的范畴。

同时应该理解,如在此所用的术语“和/或”包括一个或多个相关的列出项的任意和所有组合。另外应该理解,当部件或单元被称为“连接”或“耦接”到另一部件或单元时,它可以直接连接或耦接到其他部件或单元,或者也可以存在中间部件或单元。此外,用来描述部件或单元之间关系的其他词语应该按照相同的方式理解(例如,“之间”对“直接之间”、“相邻”对“直接相邻”等)。

图1是根据本发明一具体实施方式中防止恶意请求方法的具体流程示意图。如图1所示,本发明具体实施方式中包括一种防止恶意请求的方法,所述方法包括步骤:

a、当用户终端向服务器发送业务请求时,服务器前端应用请求后端服务是否需要验证码;

b、如果后端服务需要验证码,则服务器前端应用向终端要求输入验证码,终端向服务器发送验证码请求后,后端服务向终端发送验证码,待终端向前端应用返回验证码信息后,后端服务拦截终端的一个以上指标;

c、根据后端服务拦截终端的一个以上指标,分析恶意请求可能性,当恶意请求可能性高于预定阈值时,后端服务通过前端应用要求终端输入额外验证码。

因此,通过本发明具体实施方式中的防止恶意请求方法,能够主动识别可能的恶意请求,达到主动防治的效果。

所述的主动识别可能的恶意请求的方法,例如是机器学习的方法,可以是神经网络学习方法,或者其他优化方法。

在一个具体实施方式中,所述后端服务记录终端的一个以上指标包括终端的网络地址、终端所使用浏览器及版本、终端操作系统、用户名称、手机号码中的一个或以上,所述后端服务拦截终端的一个以上指标包括后端服务产生一个以上拦截器,所述一个以上拦截器分别拦截终端向前端程序返回的所述一个以上指标。

采用一个以上拦截器分别拦截终端向前端程序返回的所述一个以上指标,这样对于恶意侦听软件,或者恶意修改软件,即使能够破解一到两个拦截器,其余的拦截器也不会受到影响,因此保证了本发明的实施效果。

在一个具体实施方式中,,所述根据后端服务拦截终端的一个以上指标,分析恶意请求可能性包括,服务器统计一定时间内所述一个以上指标分别与恶意请求产生关联的概率,以各项指标与恶意请求产生关联的概率的加权和为总的恶意请求可能性。

特别地,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d1、服务器限定终端接口调用的参考字段,通过模糊或者错误的错误提示混淆可能的恶意请求终端,使其不能确定调用失败的原因,增加调用难度,避免通过其它脚本对接口的调用。

例如,限定终端接口调用的refer(是指业务请求header头中的refer字段,在终端浏览器正常发出的ajax请求,refer值是宿主页面地址,对于新打开窗口,重定向类的请求,refer是上一个页面的地址),通过模糊或者错误的错误提示混淆恶意请求发出者(如响应{“code”:20012,”error”:”非法调用”}),使恶意请求发出者不能确定调用失败的原因,增加调用接口难度,避免通过其它脚本对终端业务请求接口的调用。

或者,在另一具体实施方式中,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d2、由终端脚本在接口调用前通过特定方式产生调用令牌,并关联后端服务,当下一次请求携带的令牌在服务器中找不到相应资源时,则提示超时,终端必须重新发起业务请求流程。

例如,由终端脚本在接口调用前通过某种方式产生调用token(可在前端产生一个较长的无规则的机值,比如uuid等),并关联后端资源,当下一次业务请求携带的token在服务器中找不到相应资源,则提示超时,终端必须重新发起流程,当然,token对应后端资源是有时间属性的,可视正常操作耗用时间酌情确定,以避免token机制被破解(如cas授权成功时会给授权系统一个serviceticket,目标系统持有serviceticket需要在8秒内请求casserver去提取serviceticket对应的资源【用户信息】,超过8秒未去获取则serviceticket失效),在具体接口调用时传入token,将前端脚本通过一定的方式加密(如asm)或压缩后,很难猜测相关token的产生方式,配合服务端误导性的提示,增加恶意使用难度,如下图,通过请求间的某个token串联起业务流程,由于token无规则,每次打开页面产生的token不相同,攻击者不知道原理的情况下无法产生token,服务端可以接收一个token的同时回传给前端另一个token,作为执行下一步骤的“钥匙”。

又或者,在另一具体实施方式中,如图3所示,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d3、对于短时间内发送大量业务请求的终端可在预定一段时间内对其拒绝访问,所述确定终端需要同时考虑网络地址和用户设备编号、浏览器类型,浏览器版本,操作系统版本中的一个或多个。

正常情况下终端发送业务请求的周期一般在2秒以上,而恶意请求的脚本能刷到500+的qps,这样会导致大量消息被压入堆栈,但是推送是个缓慢的过程,因为走http协议,终端需要先连接上服务端服务端,服务端才能给终端推送消息,因而受到二个方面的压力,一是恶意请求发送者大量的发消息请求,二是收取者大量的连接请求,如果消息是对多的(群聊)那么这个规模就会放大几十倍甚至上千倍,从而导致内存耗尽,堆栈溢出,服务不可用,影响正常用户体验。目前通过消息频率限制(每个特征单独限制,各个用户调用互不影响)将发送消息频率限制在正常水平,从而避免了服务端压力过大,后期考虑增加统计分析等功能屏蔽恶意使用。

具体而言,本实施方式中采用频次和次数限制,短时间内最多业务请求多少次和长时间内最多业务请求次数控制,对于短时间内大量进行业务请求的消费者可在一段时间内对其拒绝访问,对于某一或某些ip大量访问的情况,可以针对单位时间内的访问量或者问题来进行限制,这对于大部分情况是适用的,有一个例外是企业或者小区等入口,大量的设备使用一个网络出口,因而对于这类用户,简单地通过ip限制可能会伤害一部分用户的体验,当然有些恶意用户可能隐藏其中,为了达到更好的体验,需要收集更多的指标来进行统计,比如用户的设备id,浏览器类型,浏览器版本,操作系统版本,通过分析这些指标,找到流量较大的请求的特征,再将符合这些特征的请求进行限制,可以达到效果。

另外,在本发明另一具体实施方式中,所述方法还进一步包括,当恶意请求可能性高于预定阈值时,执行步骤:

d4、可以基于地址和接口授权策略对终端发出业务请求的频率进行限制,终端要发出业务请求时,必须取得一个具有时限和次数的令牌,每次发出业务请求前需要访问服务器的令牌接口获取一个令牌,如果后端服务验证它可以申请业务就授予令牌,从而接受其业务请求,否则不返回令牌。

具体而言,本具体实施方式中基于调用令牌进行,可以基于ip,接口授权等策略对业务请求方调用频率进行限制,业务请求方要调用接口,必须取得一个具有时限和次数的令牌,每次业务请求前需要访问令牌接口获取一个令牌,如果后端策略验证它可以调用就授予令牌,从而调用接口,否则不返回令牌。这有些类似于挂号看病,号挂上了,约定了时间才能得到诊断,治疗,但本发明的系统并不是单一医生,而是多个医生(多核心,多线程),能同时处理多个病人(请求),从而保证其它公司,小区用户的体验,因为授予令牌的请求足够轻量化,并且能够方便的硬向扩展,再加上一些限制情况,从而保证系统稳定。比如本发明约定系统每秒处理一个请求(当然,这只是个比方,正常使用需要根据其它指标,如ip等为每类用户分配一个指标“桶”),当桶里还有指标时,本发明分配一个token,并削减桶中的一个指标,当指标桶里随着消耗,没有指标时本发明不返回token,让用户再去排队获取token,只有持有token才能进行下一步操作,就像就医时,先挂号,然后才能在医生那排队就医,没有挂上号也就就不了医(调用不了系统)。本发明开另一个线程去给桶里放指标,比如每秒放一个,就实现了每秒一个请求的目标。

需要说明的是,以上d1~d4中的方法,可以组合一个以上使用,通过组合运用几种各种策略发现,如果利用终端接口作为短信轰炸机的工具,通过更改手机号一天发送大约1.5万条短信,快速消耗服务器的短信费用,并且造成短信通道阻塞,正常收发超时,用户和潜在用户没有进行相关操作而收到多条短信,影响生活。而对服务器的系统安全感到不信任。目前正常用户走简便操作流程,疑似恶意请求的终端会通过频率,ip和验证码进行约束,恶意使用者在一个较长的时间内会自动禁用。

与本发明具体实施方式中的防止恶意请求方法相对应,本发明具体实施方式中还包括一种防止恶意请求的装置,所述装置包括前端应用单元,后端服务单元,恶意请求分析单元,其中,

前端应用单元用于请求后端服务是否需要验证码,以及向终端要求输入验证码并接收终端输入的验证码;

后端服务单元用于拦截终端向前端程序返回的所述一个以上指标,将所述一个以上指标交给恶意请求分析单元;

所述恶意请求分析单元用于根据后端服务单元拦截终端向前端程序返回的所述一个以上指标,分析恶意请求可能性。

其中,所述装置还包括调用令牌生成单元,所述调用令牌生成单元用于由终端脚本在接口调用前通过特定方式产生调用令牌,并关联后端服务,当下一次请求携带的令牌在服务器中找不到相应资源时,则提示超时,终端必须重新发起业务请求流程。

另外,所述装置还包括访问屏蔽单元,所述访问屏蔽单元用于对于短时间内发送大量业务请求的终端可在预定一段时间内对其拒绝访问,所述确定终端需要同时考虑网络地址和用户设备编号、浏览器类型,浏览器版本,操作系统版本中的一个或多个。

需要说明的是,上述实施方式仅为本发明较佳的实施方案,不能将其理解为对本发明保护范围的限制,在未脱离本发明构思前提下,对本发明所做的任何微小变化与修饰均属于本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1