CN106209748B - 互联网接口的防护方法及装置 - Google Patents

Abstract

本申请提供了一种互联网接口的防护方法及装置，其中的方法包括：获取基于客户端发送的第一请求生成的第一响应页面；在所述第一响应页面中插入用于产生签名信息的预定组件；将插入所述预定组件的第一响应页面发送给客户端；接收客户端发送的第二请求；对所述第二请求进行签名信息的验证。通过该方法能够实现对Web接口的防护，使得Web漏洞扫描无法及时获取到签名信息或其无法伪装正确的签名信息，从而无法通过验证.保证了Web接口的安全。

Description

互联网接口的防护方法及装置

技术领域

本申请涉及计算机领域，尤其涉及一种互联网接口的防护方法及装置。

背景技术

目前，互联网(Web)接口攻击一般通过Web漏洞扫描器(appscan)及一些半自动化的工具(burpsuite)刺探来获取目标网站的漏洞信息，并针对漏洞信息进行攻击。现有的Web漏洞扫描常用的是网络爬虫功能和漏洞扫描功能。网络漏洞扫描主要是基于字符特征串来识别。例如，正常访问请求中的URL比如为http：//www.taobao.com/test.php？Id＝1，而web扫描器进行SQL注入扫描，即漏洞扫描时，会发出类似http：//www.taobao.com/test.php？Id＝1+and+1＝1这样的请求。如果识别出请求中带有“and 1＝1”之类的字符串，可以判定该请求的发出者正在进行SQL注入攻击，即漏洞扫描。网络爬虫功能一般是通过识别HTTP请求头中用户-代理(user-agent)字段来识别非法攻击，另外也可通过收集分析来自同一客户端的访问频率来识别非法攻击。用户-代理字段识别本质上仍然是特征字符串方式。访问频率判断识别方式可通过增加或者变化请求间的间隔，甚至使用多IP代理访问机制绕过WAF的识别。

如上所述，无论是漏洞扫描功能还是网络爬虫功能，主要采取字符串识别方式，但Web漏洞扫描方只需构造出一个既能满足扫描要求又能躲避字符串识别的特殊字符串即可轻易的绕过这种字符串识别。例如：防护装置对于附加的请求字符串“and 1＝1”能识别出它是漏洞扫描者发出来的，但对“and 6＝(12/2)”就无法识别出它是漏洞扫描者发出来的，因此攻击者(Web漏洞扫描方)发出“and 6＝(12/2)”就可以达到漏洞扫描而又避免防护的目的。

发明内容

本申请解决的技术问题之一是使Web漏洞扫描者不容易穿透Web接口的防护，提高检测到Web漏洞扫描的精确性。

根据本申请的一个实施例，提供了一种互联网接口的防护方法，包括：获取基于客户端发送的第一请求生成的第一响应页面；在所述第一响应页面中插入用于产生签名信息的预定组件；将插入所述预定组件的第一响应页面发送给客户端；接收客户端发送的第二请求；对所述第二请求进行签名信息的验证。

根据本申请的一个实施例，提供了一种互联网接口的防护装置，包括：获取单元，被配置为获取基于客户端发送的第一请求生成的第一响应页面；插入单元，被配置为在所述第一响应页面中插入用于产生签名信息的预定组件；发送单元，被配置为将插入所述预定组件的第一响应页面发送给客户端；接收单元，被配置为接收客户端发送的第二请求；验证单元，被配置为对所述第二请求进行签名信息的验证。

由于本申请实施例通过在响应页面中插入预定组件，预定组件下载到客户端后在客户端侧产生签名信息，并加入到客户端发送的第二请求中，这样，通过对第二请求进行签名信息的验证，就验证了第二请求是来自一个正常访问网页的客户端，还是Web漏洞扫描者，从而使Web漏洞扫描者不容易穿透Web接口的防护，提高检测到Web漏洞扫描的精确性。

本领域普通技术人员将了解，虽然下面的详细说明将参考图示实施例、附图进行，但本申请并不仅限于这些实施例。而是，本申请的范围是广泛的，且意在仅通过后附的权利要求限定本申请的范围。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出了根据本申请一个实施例的互联网接口的防护方法的流程图。

图2示出了根据本申请一个具体实施例的互联网接口的防护方法的流程图。

图3示出了根据本申请另一个具体实施例的互联网接口的防护方法的流程图。

图4示出了根据本申请一个实施例的互联网接口的防护装置的框图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

在上下文中所称“计算机设备”，也称为“电脑”，是指可以通过运行预定程序或指令来执行数值计算和/或逻辑计算等预定处理过程的智能电子设备，其可以包括处理器与存储器，由处理器执行在存储器中预存的存续指令来执行预定处理过程，或是由ASIC、FPGA、DSP等硬件执行预定处理过程，或是由上述二者组合来实现。计算机设备包括但不限于服务器、个人电脑、笔记本电脑、平板电脑、智能手机等。

所述计算机设备包括用户设备与网络设备。其中，所述用户设备包括但不限于电脑、智能手机、PDA等；所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量计算机或网络服务器构成的云，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中，所述计算机设备可单独运行来实现本申请，也可接入网络并通过与网络中的其他计算机设备的交互操作来实现本申请。其中，所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。

需要说明的是，所述用户设备、网络设备和网络等仅为举例，其他现有的或今后可能出现的计算机设备或网络如可适用于本申请，也应包含在本申请保护范围以内，并以引用方式包含于此。

后面所讨论的方法(其中一些通过流程图示出)可以通过硬件、软件、固件、中间件、微代码、硬件描述语言或者其任意组合来实施。当用软件、固件、中间件或微代码来实施时，用以实施必要任务的程序代码或代码段可以被存储在机器或计算机可读介质(比如存储介质)中。(一个或多个)处理器可以实施必要的任务。

这里所公开的具体结构和功能细节仅仅是代表性的，并且是用于描述本申请的示例性实施例的目的。但是本申请可以通过许多替换形式来具体实现，并且不应当被解释成仅仅受限于这里所阐述的实施例。

应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元，但是这些单元不应当受这些术语限制。使用这些术语仅仅是为了将一个单元与另一个单元进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一单元可以被称为第二单元，并且类似地第二单元可以被称为第一单元。这里所使用的术语“和/或”包括其中一个或更多所列出的相关联项目的任意和所有组合。

应当理解的是，当一个单元被称为“连接”或“耦合”到另一单元时，其可以直接连接或耦合到所述另一单元，或者可以存在中间单元。与此相对，当一个单元被称为“直接连接”或“直接耦合”到另一单元时，则不存在中间单元。应当按照类似的方式来解释被用于描述单元之间的关系的其他词语(例如“处于…之间”相比于“直接处于…之间”，“与…邻近”相比于“与…直接邻近”等等)。

这里所使用的术语仅仅是为了描述具体实施例而不意图限制示例性实施例。除非上下文明确地另有所指，否则这里所使用的单数形式“一个”、“一项”还意图包括复数。还应当理解的是，这里所使用的术语“包括”和/或“包含”规定所陈述的特征、整数、步骤、操作、单元和/或组件的存在，而不排除存在或添加一个或更多其他特征、整数、步骤、操作、单元、组件和/或其组合。

还应当提到的是，在一些替换实现方式中，所提到的功能/动作可以按照不同于附图中标示的顺序发生。举例来说，取决于所涉及的功能/动作，相继示出的两幅图实际上可以基本上同时执行或者有时可以按照相反的顺序来执行。

下面结合附图对本申请作进一步详细描述。

图1是根据本申请一个实施例的互联网接口的防护方法的流程图。

互联网接口是指网站服务器提供的与客户端通信的接口。客户端通过该接口访问网站的网页，Web漏洞扫描者也通过该接口进行漏洞扫描。互联网接口的防护方法是指对互联网接口进行防护，从而防止漏洞扫描者通过该接口进行漏洞扫描的方法。它可以由独立于网站服务器的一个互联网接口的防护装置执行(如图2所示)，例如作为另一台与网站服务器不同的认证服务器，也可以由网站服务器上的一个模块执行(如图3所示)。在后一种情况下，也可以看做网站服务器同时具有提供正常网站访问的功能和互联网接口防护的功能。

结合图1中所示，本实施例所述的互联网接口的防护方法包括步骤S110-S150。

在步骤S110中，获取基于客户端发送的第一请求生成的第一响应页面。

第一请求例如是客户端发出的访问特定页面的请求。第一响应页面就是为该客户端返回的、该客户端要访问的特定页面。第一请求可以是对网站的主页的请求，例如，用户在浏览器输入http：//www.taobao.com，就发出了一个对淘宝主页的请求，这时第一响应页面就是淘宝主页。第一请求也可以是对：/，/index.heml，/index.php，/index.asp等常见根目录下的默认页面的请求。可选地，对于子路径下的默认页面，比如/test下的组合，可能会有/test/，/test/index.html，/test/index.php，/test/index.asp等。此时，第一响应页面就是常见根目录下的默认页面。

在图1所示的方法由独立于网站服务器的一个互联网接口的防护装置(如另一台认证服务器)执行的情况(即图2的情况)下，步骤S110中的获取是指从网站服务器接收该第一响应页面。即，网站服务器接收到(有可能是通过互联网接口的防护装置中转而接收到)客户端发送的第一请求，基于第一请求生成第一响应页面。该第一响应页面不直接发给客户端，而是先发给互联网接口的防护装置。

在图1所示的方法由网站服务器上的一个模块执行的情况(即图3的情况)下，网站服务器同时具有提供正常网站访问的功能和互联网接口防护的功能，步骤S110中的获取是指获取网站服务器本身基于客户端发送的第一请求生成的第一响应页面。

在步骤S120中，在所述第一响应页面中插入用于产生签名信息的预定组件。

具体地，预定组件可以是JS(Javascript)脚本，其可以包括预定算法，或者包括预定算法和密钥。客户端接收到插入预定组件的第一响应页面后，下载该预定组件。该预定组件中的预定算法就开始收集例如客户端浏览器中的一些信息、客户端的属性信息、客户端的光标信息等等，用预定算法处理后，就生成了签名信息。但是，网络爬虫或者Web漏洞扫描器即使下载了该预定组件，也无法生成正确的签名信息，或者能生成正确的签名信息，但从该签名信息中还原出的客户端的属性信息、客户端的光标信息表现出一些网络爬虫或者Web漏洞扫描器的特性，因而很容易识别出来。

对于网络爬虫，当网络爬虫在获取分析网址链接时，主要有2类实现机制，一是正则表达式分析URL的方法，另一类是基于浏览器内核的模拟解析法。对于第一种方法，由于预定组件是一段JS代码，故基于正则式分析URL的方法无法静态产生签名信息，所以将插入所述预定组件的第一响应页面发送给客户端后，客户端返回的请求没有签名信息，就可轻易判断出这是自动化工具提交的请求。对于第二种方法，基于浏览器内核实现的模拟解析爬虫，会将预定组件进行解析来产生签名信息，但这类爬虫因为都缺少正常浏览器所拥有的渲染引擎部分，即会使得从签名信息中还原出来的例如屏幕大小等客户端的属性信息是异常的。通过识别此异常，也可正确识别出它是自动化工具提交的请求。

对于Web漏洞扫描器，其在提交网络请求时，一般都是自己来拼装请求信息，在这个环境缺少JS解释器的支持，即使下载了预定组件，也无法解读，从而无法产生签名信息，使得通不过验证。

这样，通过在所述第一响应页面中插入用于产生签名信息的预定组件，在客户端接收到插入所述预定组件的第一响应页面并下载所述预定组件后，由所述预定组件产生签名信息，由于对于网络爬虫或Web漏洞扫描器，不是无法产生正确的签名信息，就是从签名信息中还原出来的例如屏幕大小等客户端的属性信息、客户端的光标信息等出现异常，因此通过对这样的签名信息进行验证，达到了防止漏洞扫描的效果。

在步骤S130中，将插入所述预定组件的第一响应页面发送给客户端。

在步骤S140中，接收客户端发送的第二请求。

第二请求例如是客户端发出了访问特定页面的请求之后的后续请求。例如，客户端发出了访问特定页面的第一请求后，在客户端显示特定页面，用户又点击了特定页面上的某链接，则针对该链接指向的页面发出了第二请求。第二请求可以多次发出。例如，用户点击了特定页面上的链接A，关掉后又点击了特定页面上的链接B，则发出的两个请求都是第二请求，分别对应于对链接A和B指向的页面的请求。

如果客户端正常产生了签名信息，该签名信息要加入到第二请求中。所述签名信息是在客户端接收到插入所述预定组件的第一响应页面并下载所述预定组件后，由所述预定组件产生并加入到第二请求中的。

在一种实现方式中，所述签名信息是由所述预定组件通过以下产生的：至少收集所述客户端的属性信息和/或客户端的光标信息，根据预定组件中包括的预定算法生成签名片段，将所述签名片段、客户端的属性信息和/或客户端的光标信息作为签名信息。具体地说，它包括三种情况：

1、至少收集客户端的属性信息，根据预定算法生成签名片段，将所述签名片段和客户端的属性信息作为签名信息；

2、收集所述客户端的属性信息和客户端的光标信息，根据预定算法生成签名片段，将所述签名片段、客户端的属性信息和客户端的光标信息作为签名信息；

3、收集客户端的光标信息，根据预定算法生成签名片段，将所述签名片段和客户端的光标信息作为签名信息。

本申请实施例生成签名信息的过程并不局限于以上3种，其只要至少通过浏览器的参数信息和/或光标位置，以使互联网接口的防护装置能够根据该签名信息判断出该第二请求是正常用户发起的，还是网络爬虫或web漏洞扫描动作导致程序自动发起的即可。

客户端的属性信息可以是屏幕的大小、键盘或鼠标的配置和/或屏幕亮度等。光标信息可以是光标的位置信息和/或光标的显示信息。

作为通过客户端的属性信息识别第二请求是正常用户发起的、还是网络爬虫或web漏洞扫描动作导致程序自动发起的例子，例如一些基于浏览器内核实现的网络爬虫，这类爬虫缺少正常浏览器拥有的渲染引擎部分，其生成的签名信息中的客户端的属性信息中的屏幕的大小这一项一般会很小，故可轻易辨认出其非正常用户操作。

作为通过客户端的光标信息识别第二请求是正常用户发起的、还是网络爬虫或web漏洞扫描动作导致程序自动发起的例子，要记录对于某个客户端连续多次发出第二请求时第二请求中包含的签名信息中恢复出来的光标的位置信息不变，则也可轻易辨认出其非正常用户操作。这主要是考虑到正常用户实际浏览页面时，即使点击同一个链接进去，其光标在屏幕的物理位置是会有差异的。

在某些情况下，生成签名片段时还结合客户端的浏览器参数信息，即收集客户端的浏览器参数信息和/或所述客户端的属性信息和/或客户端的光标信息，根据预定组件中包括的预定算法生成签名片段，将所述签名片段、客户端的浏览器参数信息和/或客户端的属性信息和/或客户端的光标信息作为签名信息。例如，它包括三种情况：

1、收集客户端的浏览器参数信息、客户端的属性信息，根据预定算法生成签名片段，将所述签名片段同客户端的属性信息作为签名信息；

2、收集客户端的浏览器参数信息、所述客户端的属性信息和客户端的光标信息，根据预定算法生成签名片段，将所述签名片段、客户端的属性信息和客户端的光标信息作为签名信息；

3、收集客户端的浏览器参数信息、客户端的光标信息，根据预定算法生成签名片段，将所述签名片段和客户端的光标信息作为签名信息。

其中，浏览器的参数信息可以是http标头中的refer字段、请求的URL(统一资源定位符)和/或请求参数信息。生成签名片段时还结合客户端的浏览器参数信息是因为，网络爬虫或web漏洞扫描器发出的浏览器请求中的一些参数会与正常用户浏览网页时发出的浏览器请求中的参数不一样。通过识别这种不同，也能够识别出第二请求是正常用户发起的、还是网络爬虫或web漏洞扫描动作导致程序自动发起的。

在步骤S150中，对所述第二请求进行签名信息的验证。

在一种实现方式中，该步骤包括：

-判断第二请求中是否包含签名信息，如不包含签名信息，则验证失败。

例如，在前述网络爬虫基于正则表达式分析URL的方法来获取分析网址链接的情况下，由于预定组件是一段JS代码，故基于正则式分析URL的方法无法静态产生签名信息，因此，在这种情况，就会判断出第二请求中不包含签名信息，验证失败。

-通过预定算法还原签名信息中的签名片段，将从签名片段中还原出的客户端的属性信息和/或客户端的光标信息分别与签名信息中的客户端的属性信息和/或客户端的光标信息进行对比，如不匹配，则验证失败；

在步骤S120中，在所述第一响应页面中插入用于产生签名信息的预定组件时，预定组件中包括的预定算法(如果有密钥的话，还有包括的密钥)要存储在互联网接口的防护装置(如前所述，其可以是独立于网站服务器的装置，也可以是网站服务器上的一个模块)上。在步骤S150中，就可以用互联网接口的防护装置上在步骤S120中存储的预定算法(以及密钥，如果有的话)去还原签名信息中的签名片段，还原出客户端的属性信息和/或客户端的光标信息。由于签名信息中除了签名片段之外还包括未经预定算法处理的客户端的属性信息和/或客户端的光标信息，将这个未经预定算法处理的客户端的属性信息和/或客户端的光标信息与还原出的客户端的属性信息和/或客户端的光标信息进行比对。如果不匹配，则验证失败。

例如，有些漏洞扫描器可以无法解读JS代码，因而无法识别预定组件，但它可能会试图用其它算法生成一个假的签名片段，伪造签名信息。在这种情况下，它采用的算法与互联网接口的防护装置端存储的预定算法是不同的。用互联网接口的防护装置端存储的预定算法去还原签名信息，得到的客户端的属性信息和/或客户端的光标信息会与签名信息中带的客户端的属性信息和/或客户端的光标信息不同。通过这种对比，会检查出这种用其它算法伪造签名信息的漏洞扫描者。

-判断从签名片段中还原出的客户端的属性信息和/或客户端的光标信息是否符合预定条件，如符合，则验证失败，如不符合，则验证成功。

预定条件例如：

1)从签名片段中还原出的客户端的属性信息中屏幕的大小低于预定阈值。

如前所述，一些基于浏览器内核实现的网络爬虫缺少正常浏览器拥有的渲染引擎部分，其生成的签名信息中的客户端的属性信息中的屏幕的大小这一项一般会很小，故可轻易辨认出其非正常用户操作。

2)从某个客户端连续多次发出的第二请求包含的签名信息中恢复出来的光标的位置信息不变。

如前所述，正常用户实际浏览页面时，即使点击同一个链接进去，其光标在屏幕的物理位置是会有差异的。如果从某个客户端连续多次发出的第二请求包含的签名信息中恢复出来的光标的位置信息不变，则很可能是非正常用户操作。

如验证失败，可以拒绝该客户端访问互联网接口。如验证成功，可以通过网站服务器允许该客户端继续访问。

为了进一步提高检测Web漏洞扫描的准确率，预定组件中的预定算法可以更新。即，每次需要在所述第一响应页面中插入用于产生签名信息的预定组件的情况下，动态生成预定组件中包含的所述预定算法，并存储该预定算法。例如，用户输入网站主页的地址，用户的客户端浏览器发出第一请求，互联网接口的防护装置返回加入了预定组件1的网站主页给用户，这个预定组件1中包含预定算法1；当用户点击网站主页的某链接后，互联网接口的防护装置返回加入预定组件2的该链接指向的网页，预定组件2包含与预定算法1不同的预定算法2。

这样做的好处是使目前市面上的一些半自动化工具失效。通过半自动化工具，可以分析出预定算法，从而产生签名信息。然后，由于本申请实施例中预定算法可以不断更新，而半自动化工具分析预定算法需要时间，当半自动化工具分析出预定算法时，预定算法已经更新了。这样，使得这类工具即使有人工分析算法来分析预定算法，也变得没有意义。

结合图2中所示，以互联网接口的防护装置是独立于网站服务器的一个单独的装置为例，所述的互联网接口的防护方法的一个详细过程包括：

步骤210、客户端发送第一请求给服务器。

进一步，互联网接口的防护装置可以接收客户端的第一请求后转发给服务器。

步骤220、服务器接收到第一请求后生成第一响应页面，返回给互联网接口的防护装置。具体地，第一响应页面为第一请求中的网址对应的页面内容。

步骤230、互联网接口的防护装置在接收到的第一响应页面中插入用于产生签名信息的预定组件后发送给客户端。

客户端接收到该第一响应页面后下载该预定组件。在加载该组件之后，用户又点击第一响应页面中的某个链接，再次发起对该链接指向的页面的第二请求，其请求的页面地址例如为http：//www.taobao.com/test.php？q＝a，该预定组件此时捕获到此信息，并收集浏览器特征(比如，refer字段、请求的url、请求参数和值信息等)，收集客户端属性信息(如屏幕大小信息)，收集点击时的光标信息(如光标位置信息或光标显示信息)，将这些信息按照其包括的预定算法和密钥计算出签名片段，同时可以将客户端属性信息、点击时的光标信息与签名片段一起加到第二请求URL中，使客户端发送的第二请求变为：http：//www.taobao.com/test.php？q＝a&waf_sign＝12345678&waf_info＝qwertyyyyuuuuuuuuuuu，其中，Waf_sign是签名信息，waf_info则是使用对称加密封装的屏幕特征信息。

步骤240、客户端将包含有签名信息的第二请求发送给互联网接口的防护装置。

步骤250、互联网接口的防护装置接收客户端发送的第二请求，并对该第二请求进行签名信息验证。若验证通过，则通知服务器，否则发出警告通知或丢弃该第二请求。

例如，互联网接口的防护装置接收到第二请求后，其先检查是否存在签名信息字段waf_sign和waf_info，如果不存在，说明这个提交是可疑的，验证不通过；若存在，则采用客户端同样的预定算法来解码签名信息，与提交过来的waf_sign和waf_info进行对比，如果一致，则进一步分析例如屏幕信息的有效性。对于屏幕信息的有效性，例如需要记录对同一个客户端IP发送过来的屏幕信息进行对比，如果光标位置相对屏幕一直未发生变化，则可认为此次提交是可疑的。另外，如果客户端提交的签名信息中解析出的屏幕大小太小，则此次提交也是可疑的，认为验证不通过。如果前述问题没有验证出问题，则验证通过。

结合图3中所示，以互联网接口的防护装置是网站服务器中的一个模块为例，所述的互联网接口的防护方法的一个详细过程包括：

步骤310、客户端发送第一请求给网站服务器。

步骤320、网站服务器接收到第一请求后生成第一响应页面。具体地，第一响应页面为第一请求中的网址对应的页面内容。

步骤330、带有互联网接口的防护装置的网站服务器在生成的第一响应页面中插入用于产生签名信息的预定组件后发送给客户端。

客户端接收到该第一响应页面后下载该预定组件。在加载该组件之后，用户又点击第一响应页面中的某个链接，再次发起对该链接指向的页面的第二请求，其请求的页面地址例如为http：//www.taobao.com/test.php？q＝a，该预定组件此时捕获到此信息，并收集浏览器特征(比如，refer字段、请求的url、请求参数和值信息等)，收集客户端属性信息(如屏幕大小信息)，收集点击时的光标信息(如光标位置信息或光标显示信息)，将这些信息按照其包括的预定算法和密钥计算出签名片段，同时可以将客户端属性信息、点击时的光标信息与签名片段一起加到第二请求URL中，使客户端发送的第二请求变为：http：//www.taobao.com/test.php？q＝a&waf_sign＝12345678&waf_info＝qwertyyyyuuuuuuuuuuu，其中，Waf_sign是签名信息，waf_info则是使用对称加密封装的屏幕特征信息。

步骤340、客户端将包含有签名信息的第二请求发送给网站服务器。

步骤350、网站服务器接收客户端发送的第二请求，并对该第二请求进行签名信息验证。

例如，网站服务器接收到第二请求后，其先检查是否存在签名信息字段waf_sign和waf_info，如果不存在，说明这个提交是可疑的，验证不通过；若存在，则采用客户端同样的预定算法来解码签名信息，与提交过来的waf_sign和waf_info进行对比，如果一致，则进一步分析例如屏幕信息的有效性。对于屏幕信息的有效性，例如需要记录对同一个客户端IP发送过来的屏幕信息进行对比，如果光标位置相对屏幕一直未发生变化，则可认为此次提交是可疑的。另外，如果客户端提交的签名信息中解析出的屏幕大小太小，则此次提交也是可疑的，认为验证不通过。如果前述问题没有验证出问题，则验证通过。

图4示出了根据本申请一个实施例的一种互联网接口的防护装置。它可以是独立于网站服务器的一个单独的装置，也可以是网站服务器上的一个模块。它包括：获取单元410，被配置为获取基于客户端发送的第一请求生成的第一响应页面；插入单元420，被配置为在所述第一响应页面中插入用于产生签名信息的预定组件；发送单元430，被配置为将插入所述预定组件的第一响应页面发送给客户端；接收单元440，被配置为接收客户端发送的第二请求；验证单元450，被配置为对所述第二请求进行签名信息的验证。

可选地，所述签名信息是在客户端接收到插入所述预定组件的第一响应页面并下载所述预定组件后，由所述预定组件产生并加入到第二请求中的。

可选地，所述签名信息是由所述预定组件通过以下产生的：

至少收集所述客户端的属性信息和/或客户端的光标信息，根据预定组件中包括的预定算法生成签名片段，将所述签名片段、客户端的属性信息和/或客户端的光标信息作为签名信息。

可选地，所述验证单元进一步被配置为：判断第二请求中是否包含签名信息，如不包含签名信息，则验证失败；通过预定算法还原签名信息中的签名片段，将从签名片段中还原出的客户端的属性信息和/或客户端的光标信息分别与签名信息中的客户端的属性信息和/或客户端的光标信息进行对比，如不匹配，则验证失败；判断从签名片段中还原出的客户端的属性信息和/或客户端的光标信息是否符合预定条件，如符合，则验证失败，如不符合，则验证成功。

可选地，所述插入单元进一步被配置为：每次需要在第一响应页面中插入用于产生签名信息的预定组件的情况下，动态生成预定组件中包含的所述预定算法，并存储该预定算法。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，本申请的各个装置可采用专用集成电路(ASIC)或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (6)

1.一种互联网接口的防护方法，包括：

获取基于客户端发送的第一请求生成的第一响应页面；

在所述第一响应页面中插入用于产生签名信息的预定组件；

将插入所述预定组件的第一响应页面发送给客户端；

接收客户端发送的第二请求；

对所述第二请求进行签名信息的验证；其中，所述签名信息是在客户端接收到插入所述预定组件的第一响应页面并下载所述预定组件后，由所述预定组件产生并加入到第二请求中的；其中，所述签名信息是由所述预定组件通过以下产生的：

至少收集所述客户端的属性信息和客户端的光标信息，根据预定组件中包括的预定算法生成签名片段，将所述签名片段、客户端的属性信息和/或客户端的光标信息作为签名信息。

2.根据权利要求1所述的防护方法，其中，所述对所述第二请求进行签名信息的验证的步骤包括：

判断第二请求中是否包含签名信息，如不包含签名信息，则验证失败；

通过预定算法还原签名信息中的签名片段，将从签名片段中还原出的客户端的属性信息和/或客户端的光标信息分别与签名信息中的客户端的属性信息和/或客户端的光标信息进行对比，如不匹配，则验证失败；

判断从签名片段中还原出的客户端的属性信息和/或客户端的光标信息是否符合预定条件，如符合，则验证失败，如不符合，则验证成功。

3.根据权利要求1-2任一项所述的防护方法，其中，每次需要在所述第一响应页面中插入用于产生签名信息的预定组件的情况下，动态生成预定组件中包含的所述预定算法，并存储该预定算法。

4.一种互联网接口的防护装置，包括：

获取单元，被配置为获取基于客户端发送的第一请求生成的第一响应页面；

插入单元，被配置为在所述第一响应页面中插入用于产生签名信息的预定组件；

发送单元，被配置为将插入所述预定组件的第一响应页面发送给客户端；

接收单元，被配置为接收客户端发送的第二请求；

验证单元，被配置为对所述第二请求进行签名信息的验证；其中，所述签名信息是在客户端接收到插入所述预定组件的第一响应页面并下载所述预定组件后，由所述预定组件产生并加入到第二请求中的；其中，所述签名信息是由所述预定组件通过以下产生的：

至少收集所述客户端的属性信息和客户端的光标信息，根据预定组件中包括的预定算法生成签名片段，将所述签名片段、客户端的属性信息和/或客户端的光标信息作为签名信息。

5.根据权利要求4所述的防护装置，其中，所述验证单元进一步被配置为：

判断第二请求中是否包含签名信息，如不包含签名信息，则验证失败；

通过预定算法还原签名信息中的签名片段，将从签名片段中还原出的客户端的属性信息和/或客户端的光标信息分别与签名信息中的客户端的属性信息和/或客户端的光标信息进行对比，如不匹配，则验证失败；

判断从签名片段中还原出的客户端的属性信息和/或客户端的光标信息是否符合预定条件，如符合，则验证失败，如不符合，则验证成功。

6.根据权利要求4-5任一项所述的防护装置，其中，所述插入单元进一步被配置为：

每次需要在第一响应页面中插入用于产生签名信息的预定组件的情况下，动态生成预定组件中包含的所述预定算法，并存储该预定算法。