CN108540513B - 请求重放攻击的判定方法和装置 - Google Patents

Abstract

本发明公开了一种请求重放攻击的判定方法和装置。其中，请求重放攻击的判定方法包括：接收业务数据请求；基于业务数据请求，生成请求流水号；将所生成的请求流水号存储至分布式的内存型数据库；查询内存型数据库中请求流水号的当前统计次数；当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求。本实施例通过分布式查询、判定的处理方式，可以将现有技术中串行处理方式变为并行处理方式，从而提高网络请求速度，并减少对系统开销。基于内存型数据库可以与外部数据快速交互的特性，进一步提升了网络请求的速度。基于内存型数据库原子操作的特点，能够保证数据的准确性和完整性。

Description

请求重放攻击的判定方法和装置

技术领域

本发明涉及数据安全技术领域，尤其涉及一种请求重放攻击的判定方法和装置。

背景技术

随着通信技术的快速发展，移动业务支撑系统越来越复杂，对用户核心信息更改的请求来源也越来越多。例如：来自界面发起的受理请求，来自电子渠道发起的订单请求，以及来自后台服务发起的批量业务处理请求等。一旦出现网络请求重放攻击问题，很难在短时间内定位发生的攻击的请求，攻击会对哪个模块产生影响。

目前，针对上述问题主要解决的方式有：为请求数据包设置包序号，每次序号同向加1。当收到重复序号时，认为是重放攻击。然而，申请人经研究发现：每次网络请求的数据包序号同向加1，若要保证请求不被重放攻击，意味着数据请求需要串行处理。在大并发的业务状态下，现有方式会对系统造成很大的负担、准确性也会受到影响，而且会限制网络请求的处理速度。

有鉴于此，如何提高网络请求速度，提升数据处理准确性，并减少对系统开销成为业界亟待解决的问题。

发明内容

本发明实施例提供了一种请求重放攻击的判定方法和装置，解决了处理网络请求速度慢，系统开销大等问题。

第一方面，提供了一种请求重放攻击的判定方法。该方法包括以下步骤：

接收业务数据请求；

基于业务数据请求，生成请求流水号；

将所生成的请求流水号存储至分布式的内存型数据库；

查询内存型数据库中请求流水号的当前统计次数；

当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求。

第二方面，提供了一种请求重放攻击的判定装置。该装置包括：

请求接收模块，用于接收业务数据请求；

号码生成模块，用于基于业务数据请求，生成请求流水号；

内部存储模块，用于将所生成的请求流水号存储至分布式的内存型数据库；

次数统计模块，用于查询内存型数据库中请求流水号的当前统计次数；

请求判定模块，用于当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求。

一方面，本实施例通过分布式并行查询、判定的处理方式，可以将现有技术中串行处理方式变为并行处理方式，从而提高网络请求速度，并减少对系统开销。

另一方面，基于内存型数据库可以与外部数据快速交互的特性，进一步提升了网络请求的速度。

又一方面，基于内存型数据库原子操作(不会被线程调度机制打断的操作)的特点，能够保证数据的准确性和完整性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例的请求重放攻击的判定系统的架构示意图。

图2是本发明一实施例的请求重放攻击的判定方法的流程示意图。

图3是本发明另一实施例的请求重放攻击的判定方法的流程示意图。

图4是本发明一实施例的请求处理方法的流程示意图。

图5是本发明一实施例的请求重放攻击的判定装置的功能结构图。

图6是本发明一实施例的请求处理装置的功能结构图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1是本发明一实施例的请求重放攻击的判定系统的架构示意图。

如图1所示，该架构包括：客户端100、服务端200。其中，服务端200可以包括：后台业务系统210、核心业务系统220和存储在内部存储模块中的Redis集群230。其中，后台业务系统210可以与公网连接，其可以包括：请求信息预校验模块211和数据校验模块212。核心业务系统220可以与内网连接，其可以包括：次数统计模块221和号码清理模块222。

在本实施例中，防止请求重放攻击的工具可以主要包括：数据校验模块212、次数统计模块221和号码清理模块222。其中，数据校验模块212可以用于对客户端请求数据进行相应的算法加密，客户端请求数据带有加密串和请求流水序列号的明文。客户端将请求数据发送给数据校验模块，获得相应的加密签名，在请求后台业务系统时，带上签名。后台业务系统根据秘钥管理工具提供的加密算法对客户端请求数据和签名进行校验。次数统计模块221(例如，请求流水统计模块)可以利用Redis内存型数据库的高速性，使系统能够承受大并发下的流水统计；利用Redis数据库的原子性操作，对Redis数据库中存储的请求流水进行自增和读取操作，保证数据的准确性和完整性。号码清理模块222(例如，流水清理模块)可以用于对Redis数据库中的请求流水进行定期清理，防止数据占用过多系统磁盘空间和内存空间。

可以理解，上述各功能模块的数量和Redis集群中的Redis数据库的数量是示意性的，具体数量可以根据实际需要进行灵活调整。另外，个功能模块也可以根据实际需要进行个性化配置，例如，删除请求信息预校验模块211，直接将来自客户端100的请求经过数据校验模块212进行校验，然后在通过次数统计模块221统计请求流水号的次数。

下面各实施例均可以应用于本实施例的系统架构判断请求重放攻击。本实施例的系统可以作为下面各个实施例的实施主体执行具体的判断请求重放攻击的操作。为了描述简洁，各个实施例可以相互参考应用。

图2是本发明一实施例的请求重放攻击的判定方法的流程示意图。

如图2所示，该方法包括以下步骤：S210，接收业务数据请求；S220，基于业务数据请求，生成请求流水号；S230，将所生成的请求流水号存储至分布式的内存型数据库；S240，查询内存型数据库中请求流水号的当前统计次数；S250，当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求。

在步骤S210中，业务数据请求可以是对用户核心信息更改的请求。例如：来自界面发起的受理请求，来自电子渠道发起的订单请求，以及来自后台服务发起的批量业务处理请求等。

在步骤S220中，请求流水号可以是多个数字与字母的组合，也可以是多个数字的组合，具体可以实际需要进行灵活设置。每个业务数据请求可以对应唯一的请求流水号。例如：LS20170213001的请求流水号对应用户发起的订单请求。由此，可以通过判断请求流水号是否相同来确定业务数据请求是否相同。

在步骤S230中，分布式的内存型数据库可以是存储在内存中的数据库集群。如数据库1、数据库2...数据库n。

在步骤S240中，通常，当业务数据请求只发生了1次，查询到的内存型数据库中请求流水号的当前统计次数1次，但是，当发生重放攻击请求时，当前统计次数就会大于1次。

在步骤S250中，预设次数通常为1次，当请求流水号重复时，就可以判定业务数据请求是重放攻击请求。在一些实例中，预设次数也可以根据实际需求进行灵活设置，例如将预设次数设置为2次、3次等次数。

本发明实施例通过基于业务数据请求，生成请求流水号，将所生成的请求流水号存储至分布式的内存型数据库，可以实现分布式并行查询内存型数据库中请求流水号的当前统计次数，当所查询的当前统计次数大于预设次数时，确定业务数据请求是重放攻击请求。本实施例可以解决现有的利用时间戳的方法无法并行处理数据的问题。

一方面，本实施例通过分布式并行查询、判定的处理方式，可以将现有技术中串行处理方式变为并行处理方式，从而提高网络请求速度，并减少对系统开销。

另一方面，基于内存型数据库可以与外部数据快速交互的特性，进一步提升了网络请求的速度。

又一方面，基于内存型数据库原子操作(不会被线程调度机制打断的操作)的特点，能够保证数据的准确性和完整性。

在一些实施例中，内存型数据库是基于分布式数据存储的Redis数据库。Redis数据库是基于分布式文件存储的数据库，由Go语言编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案。Redis数据库是一个内存数据库产品，是一种提供高速存储方案的数据库。Redis内存数据库由于其单线程的特性：即对数据的操作全部以线性的方式进行，保证了操作的原子性。因此在进行大规模集中式自增操作的时候，能够准确的保证数据的完整性和正确性。

本发明可以利用Redis数据库的单线程的特性，建立HTTP流水统计表，采用的数据存储格式可以为：请求流水的次数统计格式。根据HTTP客户端每次请求发送的流水，将流水号记录至HTTP流水统计表中。在面对大并发环境下的数据操作请求时，利用Redis数据库操作的原子性，可以对请求流水进行自增/查询操作并保证数据的正确性和完整性。通过此方式，能够准确的统计每个请求流水的请求次数。达到次数限制的请求则视为重放攻击，从而达到识别重放攻击并防范重放攻击的目的。

一方面，本实施例中可以利用Redis数据库，解决了传统的关系型数据库在做数据更新时，会造成数据泄露或者破坏数据的一致性的问题。另一方面解决了传统关系型数据库使用锁的机制，大大降低系统的性能的问题。由此，本实施例可以利用Redis数据库的高效、分布式和原子操作的存储特性，构建了一种可防止重放攻击的方法，为后台服务的安全性和稳定性提供了支撑。

在一些实施例中，在查询内存型数据库中请求流水号的当前统计次数之后，方法还包括：由Redis数据库中的请求流水号的当前统计次数以预设数量进行自增。通常，预设数量为1。例如，每查询一次，统计的流水号次数会增加1。然而，预设数量也可以是2、3等，其可以根据实际情况进行灵活设置。例如，当预设数量为1、初始流水号的统计次数为1时，Redis数据库进行第一次自增后，流水号的统计次数为2；第二次自增后，流水号的统计次数为3；第三次自增后，流水号的统计次数为4……当预设数量为2、初始流水号为1时，Redis数据库进行第一次自增后，流水号的统计次数为3；第二次自增后，流水号的统计次数为5；第三次自增后，流水号的统计次数为7……

下面以预设数量为1的设置方式来说明判断业务数据请求是否是重放攻击请求的实现方式。

例如，一开始，将所生成的请求流水号LS20170213001存储至Redis数据库中，请求流水号LS20170213001的记录次数为1次。在查询Redis数据库中的请求流水号LS20170213001的次数之后，对请求流水号LS20170213001的次数进行自增，例如，自增1，请求流水号LS20170213001的次数可以是2(1+1)次。如果对该数据业务请求进行重放攻击，此时，查询到的Redis数据库中的请求流水号LS20170213001的次数则为2次。因判断2次大于预设的1次，所以认为此次业务请求是重放攻击请求。

由此，本实施例可以通过在查询内存型数据库中请求流水号的当前统计次数之后对请求流水号进行自增，来判断请求流水号是否重复查询，并判断是否重放攻击，具有操作简单，设计灵活(可以随意设计增加的具体数值，以防止操作失误)等特点。

在一些实施例中，在生成请求流水号之后，还包括以下步骤：

S1，接收第一签名，第一签名是由业务数据请求、请求流水号加密生成。

其中，第一签名可以由客户端根据业务数据请求的明文、请求流水号的明文加密生成。服务端接收第一签名的密文。

S2，对业务数据请求、请求流水号进行加密，生成第二签名。

其中，服务端可以根据图2实施例所接收的业务数据请求的明文、请求流水号的明文进行加密。

S3，比较第一签名和第二签名。

客户端获得第一签名的加密方法与服务端获得第二签名的加密方法相同。

S4，当比较结果相等时，通过数据校验。

利用相同的数据和相同的加密方法所获得的加密结果相等。由此，本实施例在提供网络服务时，利加密方法，而不是利用解密方法对数据进行校验，可以对重放攻击进行有效防范。例如，使用了内存型数据库的原子性操作和流水号和业务数据统一加密，使用明文和签名混合传输的方法，为业务系统从网络层面上防止重放攻击提供一种可行的方法，解决了现有技术中由于加密，接收方如果无法解密时，也无法看到明文内容的问题。

另外，本实施例兼顾了目前的移动业务支撑系统的局限性，有效的解决了移动业务网络请求重放攻击的的问题，同时实现数据加密的功能。

在一些实施例中，在生成请求流水号之后，还包括以下步骤：清理内存型数据库中请求流水号的记录。由此，通过对Redis数据库中的请求流水进行定期清理，可以防止数据占用过多系统磁盘空间和内存空间。

图3是本发明另一实施例的请求重放攻击的判定方法的流程示意图。

如图3所示，该方法包括以下步骤：

在S310中，请求重放攻击的判定流程开始。

在S320中，应用程序对请求数据和生成的唯一的请求流水号进行加密，将加密后的签名和请求流水的明文发给服务端。

在S330中，服务端对请求数据进行重新加密，比对加密签名，得到请求流水。将请求流水传给防重放攻击工具。

在S340中，判断请求流水是否重复，例如，防重放攻击工具查询Redis请求流水的统计次数，返回该请求流水的统计次数，如果超过1，则认为请求流水重复。

在S350中，当请求流水重复时，则认为是重放攻击。

在S360中，自增Redis请求流水的统计次数，以供下一个判断流程做参考。

在S370中，将请求转发给后端，由后端根据是否是重放攻击来确定是否提供所请求的业务。

可以理解，可以利用防重放攻击工具查询并自增Redis请求流水的统计次数，返回该请求流水的统计次数，如果超过1，则认为是重放攻击。

本实施例的目的在于提供防止网络请求重放攻击的方法，以解决目前针对网络重放攻击而产生的问题。同时提供一个防止重放攻击的工具，支持记录各个请求的序列号，利用基于分布式数据存储的Redis数据库实现各个请求序列号的统计。Redis的自增操作是原子性操作，很好的保护的数据安全性和完整性。渠道接入后将请求流水号与业务数据一同作为关键字进行加密，并将流水号明文与密文一起传送，服务端确认流水号的正确性后，查询Redis中该流水号的请求次数，并将Redis中的流水号次数进行自增。

图4是本发明另一实施例的请求处理方法的流程示意图。

如图4所示，该方法包括以下步骤：

S410，接收业务数据请求；

S420，基于业务数据请求，生成请求流水号；

S430，将所生成的请求流水号存储至内存型数据库；

S440，查询内存型数据库中请求流水号的当前统计次数；

S450，当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求，拒绝提供请求的业务数据；当所查询的当前统计次数小于等于预设次数时，业务数据请求不是重放攻击请求，提供请求的业务数据。

需要说明的是，在不冲突的情况下，本领域的技术人员可以按实际需要将上述的操作步骤的顺序进行灵活调整，或者将上述步骤进行灵活组合等操作。为了简明，不再赘述各种实现方式。另外，各实施例的内容可以相互参考引用。

综上所述，本发明上述实施例与现有相比，具有如下优点：

实现了明文密文同时传输，保证了系统的安全性，减小了后台系统解密时的性能开销，保证了系统的稳定性。

使用Redis分布式数据库作为请求流水存储数据库，减少业务支撑系统的oracle数据库的使用，支持低成本的PC Server，有效的降低了投资成本。

使用Redis数据库作为请求流水的统计存储。Redis数据库具有传统关系型数据库不具有的单线程操作特性。例如Oracle数据库，在大量网络请求时，不可能保证流水次数统计的数据安全性。如果使用锁的机制对资源进行占用，则极大地降低系统性能，因此不具有可行性。

使用Redis数据库高速，单线程特性，对请求流水高速，准确的数据库操作，是系统在大并发环境下依然可以稳定的运行。

图5是本发明一实施例的请求重放攻击的判定装置的结构示意图。

如图5所示，请求重放攻击的判定装置500可以包括：请求接收模块510、号码生成模块520、内部存储模块530、次数统计模块540和请求判定模块550。其中，请求接收模块510可以用于接收业务数据请求；号码生成模块520可以用于基于业务数据请求，生成请求流水号；内部存储模块530可以用于将所生成的请求流水号存储至内存型数据库；次数统计模块540可以用于查询内存型数据库中请求流水号的当前统计次数；请求判定模块550可以用于当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求。

在一些实施例中，请求重放攻击的判定装置500在图5实施例的基础上，还可以增加：与次数统计模块连接的次数更新模块，次数更新模块用于：由Redis数据库中的请求流水号以预设数量进行自增。

在一些实施例中，内存型数据库是基于分布式数据存储的Redis数据库。

在一些实施例中，请求重放攻击的判定装置500在图5实施例的基础上，还可以增加：接收第一签名，第一签名是由业务数据请求、请求流水号加密生成；对业务数据请求、请求流水号进行加密，生成第二签名；比较第一签名和第二签名；当比较结果相等时，通过数据校验。

在一些实施例中，请求重放攻击的判定装置500在图5实施例的基础上，还可以增加：与次数统计模块连接的号码清理模块，号码清理模块用于：清理内存型数据库中关于请求流水号的记录。

图6是本发明一实施例的请求处理装置的结构示意图。

如图6所示，请求重放攻击的判定装置600可以包括：请求接收模块610、号码生成模块620、内部存储模块630、次数统计模块640和请求处理模块650。其中。请求接收模块610可以用于接收业务数据请求；号码生成模块620可以用于基于业务数据请求，生成请求流水号；内部存储模块630可以用于将所生成的请求流水号存储至分布式的内存型数据库；次数统计模块640可以用于查询内存型数据库中请求流水号的当前统计次数；请求处理模块650可以用于当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求当所查询的当前统计次数大于预设次数时，业务数据请求是重放攻击请求，拒绝提供请求的业务数据；当所查询的当前统计次数小于等于预设次数时，业务数据请求不是重放攻击请求，提供请求的业务数据。

需要说明的是，上述各个实施例中所示的功能模块的实现方式可以为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (6)

1.一种请求重放攻击的判定方法，其特征在于，包括以下步骤：

接收业务数据请求；

基于所述业务数据请求，生成请求流水号；

将所生成的请求流水号存储至分布式的内存型数据库；

查询所述内存型数据库中所述请求流水号的当前统计次数；

当所查询的当前统计次数大于预设次数时，所述业务数据请求是重放攻击请求；

所述内存型数据库是基于分布式数据存储的Redis数据库；

在所述查询内存型数据库中所述请求流水号的当前统计次数之后，所述方法还包括：

由所述Redis数据库中的请求流水号的当前统计次数以预设数量进行自增。

2.根据权利要求1所述的请求重放攻击的判定方法，其特征在于，所述预设数量为1。

3.根据权利要求1-2中任一项所述的请求重放攻击的判定方法，其特征在于，在所述生成请求流水号之后，还包括以下步骤：

接收第一签名，所述第一签名是由所述业务数据请求、所述请求流水号加密生成；

对所述业务数据请求、所述请求流水号进行加密，生成第二签名；

比较所述第一签名和所述第二签名；

当比较结果相等时，通过数据校验。

4.一种请求重放攻击的判定装置，其特征在于，包括：

请求接收模块，用于接收业务数据请求；

号码生成模块，用于基于所述业务数据请求，生成请求流水号；

内部存储模块，用于将所生成的请求流水号存储至分布式的内存型数据库；

次数统计模块，用于查询所述内存型数据库中所述请求流水号的当前统计次数；

请求判定模块，用于当所查询的当前统计次数大于预设次数时，所述业务数据请求是重放攻击请求；

所述内存型数据库是基于分布式数据存储的Redis数据库；

与所述次数统计模块连接的次数更新模块，所述次数更新模块用于：在所述次数统计模块查询内存型数据库中所述请求流水号的当前统计次数之后，由所述Redis数据库中的请求流水号以预设数量进行自增。

5.根据权利要求4所述的请求重放攻击的判定装置，其特征在于，所述预设数量为1。

6.根据权利要求4-5中任一项所述的请求重放攻击的判定装置，其特征在于，还包括：

与所述次数统计模块连接的数据校验模块，所述数据校验模块用于：

接收第一签名，所述第一签名是由所述业务数据请求、所述请求流水号加密生成；

对所述业务数据请求、所述请求流水号进行加密，生成第二签名；

比较所述第一签名和所述第二签名；

当比较结果相等时，通过数据校验。

Images