CN103179088A - 通用网关接口业务的保护方法及系统 - Google Patents

Abstract

本发明提供了通用网关接口CGI业务的保护方法及系统，其中，该方法包括：前一CGI接收来自客户端的前一业务请求，向客户端反馈加密串；后一CGI接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。本发明方案能够在减少验证码验证次数的前提下保障通用网关接口业务的安全性。

Description

通用网关接口业务的保护方法及系统

技术领域

本发明涉及安全保护技术，尤其涉及通用网关接口业务的保护方法及系统。

背景技术

一般地，通用网关接口(CGI，Common Gateway Interface)业务由服务器上的多个CGI配合完成。CGI为服务器上的，为客户端提供请求数据的接口。

为便于描述，下面以某CGI业务需要服务器上的两个CGI配合完成进行说明，该CGI业务的执行过程包括：客户端向服务器发送第一业务请求，服务器上的CGI1对该第一业务请求进行处理，向服务器返回第一业务响应；客户端接收第一业务响应后向服务器发送第二业务请求，服务器上的CGI2对第二业务请求进行处理，向服务器返回第二业务响应。

这里，以CGI业务具体为即时通讯中的好友添加业务进行说明，该添加业务的执行过程包括：客户端向服务器发送第一业务请求，该第一业务请求为用户A查询用户B资料信息的请求，服务器上的CGI1对该第一业务请求进行处理，向服务器返回用户B的资料信息；客户端接收用户B的资料信息，展示给用户，接收用户输入的添加B做好友的指令，向服务器发送第二业务请求，该第二业务请求为添加B做好友的请求，服务器上的CGI2将B添加为A的好友，向服务器返回添加完成的响应。

在服务器进行CGI业务的创建过程中，预先配置了该CGI业务包含的各CGI的前后顺序，每个CGI用于处理不同的CGI业务请求，服务器接收来自客户端的业务请求后，由与该业务请求对应的CGI进行处理。

对于CGI业务，为了防止服务器数据被用户恶意遍历，目前主要采用两种方法进行CGI业务的安全性保护，下面分别进行说明。

一种是频率限制方法。该方法由建立在服务器的频率限制系统实现，具体地：频率限制系统记录客户端的来源IP、访问CGI的频率等信息；然后根据统计的数据判断来自客户端的业务请求是否合法，如果有来自同一IP的大量请求，或者同一用户对某CGI大量访问，则将相应的业务请求认定为非法业务请求而拒绝。

该方法存在以下缺陷：需要在服务器上建立频率限制系统，开发复杂，需要很大的存储空间，成本较高，并且根据用户的访问记录判断是否拒绝访问，可能出现误判断的情况。

另一种是验证码保护方法。该方法无需在服务器上建立频率限制系统，可节省开发成本。该方法对每个来自客户端的业务请求，都进行验证，具体地，每个CGI接收业务请求后，随机生成验证码图片，向客户端发送验证码图片；接收客户端返回的验证码，验证其合法性，验证合法后，对业务请求进行处理，向客户端反馈业务响应。

验证码技术大大损伤了用户体验，尤其是在复杂web应用程序中，一个CGI业务操作需要向服务器发起多个CGI业务请求，相应地，如果对这些CGI业务请求都使用验证码来保护，需要用户多次输入验证码。如果减少验证码验证的次数，只对首次业务请求进行验证，将出现用户在第二次添加好友操作时出现修改用户名B而添加其他用户，甚至添加多个其他用户的恶意遍历行为，导致CGI业务的安全性受到影响。

可见，验证码技术虽然可以节省开发成本，却不能在减少验证次数的前提下保证安全性。

发明内容

本发明提供了一种通用网关接口保护的方法，该方法能够在减少验证码验证次数的前提下保障通用网关接口业务的安全性。

本发明提供了一种通用网关接口保护的系统，该系统能够在减少验证码验证次数的前提下保障通用网关接口业务的安全性。

本发明提供了一种服务器，该服务器能够在减少验证码验证次数的前提下保障通用网关接口业务的安全性。

一种通用网关接口保护的方法，该方法包括：

前一CGI接收来自客户端的前一业务请求，向客户端反馈加密串；

后一CGI接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

一种通用网关接口保护的系统，该系统包括客户端和服务器；

所述客户端，用于向所述服务器发送前一业务请求，接收服务器反馈的加密串，将加密串包含在后一业务请求中发送给所述服务器；

所述服务器包含的前一CGI，用于接收来自客户端的前一业务请求，向客户端反馈加密串；

所述服务器包含的后一CGI，用于接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

一种服务器，该服务器包括前一CGI和后一CGI；

所述前一CGI，用于接收来自客户端的前一业务请求，向客户端反馈加密串；

所述后一CGI，用于接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

从上述方案可以看出，本发明中，前一CGI接收来自客户端的前一业务请求后，向客户端反馈加密串；后一CGI接收来自客户端的后一业务请求，对后一业务请求中包含的加密串进行验证，通过验证后，向客户端反馈第二业务响应。采用本发明方案，客户端在发送后一业务请求时，在后一业务请求中包含前一CGI反馈的加密串即可，无需进行验证码验证；并且，必须在后一业务请求中包含前一CGI反馈的加密串，用户不能向后一CGI发送恶意的后一业务请求，保障了CGI业务的安全性；从而，实现了在减少验证码验证次数的前提下保障CGI业务的安全性。

附图说明

图1为本发明通用网关保护的方法示意性流程图；

图2为本发明通用网关保护的方法流程图实例；

图3为本发明通用网关保护的系统结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明进一步详细说明。

本发明采用加密串将一个CGI业务包含的各CGI关联起来，在发送业务请求时携带该加密串，CGI对加密串进行验证，这样，无需每次都采用验证码验证技术，也保障CGI业务的安全性。

参见图1，为本发明CGI业务的保护方法示例性流程图，其包括以下步骤：

步骤101，前一CGI接收来自客户端的前一业务请求，向客户端反馈加密串。

本发明所述的前一CGI和后一CGI为一个CGI业务中处理流程中的相邻两个CGI。

步骤102，后一CGI接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

本步骤所述验证后一业务请求中是否包含所述加密串有多种实现方式，下面进行举例说明：

方式一：所述验证后一业务请求中是否包含所述加密串包括：判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取加密串，与后一业务请求中包含的加密串进行比较，如果相同，则通过验证。

在服务器进行CGI业务的创建过程中，预先配置了该CGI业务包含的各CGI的前后顺序，每个CGI用于处理不同的CGI业务请求，服务器接收来自客户端的业务请求后，传送给与该业务请求对应的CGI进行处理。

本发明中，还预先为各个CGI配置了与其相邻的前一CGI的标识信息，根据该标识信息可以获取前一CGI使用的加密串、业务参数等信息。方式一中所述从前一CGI获取加密串的具体实现可以为：前一CGI将加密串存储到服务器为其配置的存储单元中；后一CGI在需要时，根据前一CGI标识信息向前一CGI发送加密串获取请求，前一CGI从存储单元获取加密串，返回给后一CGI。方式一中所述从前一CGI获取加密串的具体实现还可以为：前一CGI将信息存储到各CGI共用的存储单元中，存储时，对应前一CGI标识存储加密串、业务参数等；后一CGI在需要时，根据前一CGI标识信息从存储单元获取对应的加密串。这里对获取前一CGI使用的加密串进行了说明，对于获取前一CGI使用的其他信息，如业务参数等，与之类似，这里不多赘述。

方式二：前一CGI向客户端反馈的加密串的获取方法包括：对业务参数进行加密，得到加密串；所述验证后一业务请求中是否包含所述加密串包括：判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取业务参数，对后一业务请求中的加密串进行解密，将得到的解密信息与从前一CGI获取的业务参数进行比较，如果相同，则通过验证。

所述业务参数的内容可根据需要设置。例如，所述业务参数包括主用户名和被请求用户名；方式二中所述将得到的解密信息与从前一CGI获取的业务参数进行比较包括：将解密得到的主用户名与从前一CGI获取的主用户名进行比较，如果相同，则将解密得到的被请求用户名与从前一CGI获取的被请求用户名进行比较，如果相同，则通过验证。

再如，所述业务参数还包括主用户名、被请求用户名和接收第一业务请求的时间；方式二中所述将得到的解密信息与从前一CGI获取的业务参数进行比较包括：将解密得到的主用户名与从前一CGI获取的主用户名进行比较，如果相同，则将解密得到的被请求用户名与从前一CGI获取的被请求用户名进行比较，如果相同，则判断接收后一业务请求的时间与解密得到的时间间隔是否在设定范围内，如果是，则通过验证。

如果所述前一CGI为第一CGI时，步骤101中向客户端反馈加密串之前，该方法还包括：随机生成验证码图片，向客户端发送验证码图片；接收客户端返回的验证码，判断是否合法，如果是，则执行所述向客户端反馈加密串的步骤。

本发明方案采用加密串将一个CGI业务包含的各CGI关联起来，客户端在发送后一业务请求时，在后一业务请求中包含前一CGI反馈的加密串即可，无需进行验证码验证；这样，除第一CGI进行验证码验证外，其他CGI都无需进行验证码验证。并且，必须在后一业务请求中包含前一CGI反馈的加密串，用户不能向后一CGI发送恶意的后一业务请求，保障了CGI业务的安全性。从而，实现了在减少验证码验证次数的前提下保障CGI业务的安全性。

下面同样以CGI业务具体为即时通讯中的好友添加业务，对本发明方法进行详细说明，该实例流程为图2所示，其包括以下步骤：

步骤201，CGI1接收来自客户端的第一业务请求。

该第一业务请求为用户A查询用户B资料信息的请求，将该请求包含的参数表示为：参数(A1，B1)。

步骤202，CGI1进行验证码验证，验证通过后，对该第一业务请求进行处理，向服务器返回用户B的资料信息，并对业务参数进行加密，向客户端反馈加密串。

进行验证码验证具体包括：CGI1随机生成验证码图片，向客户端发送验证码图片；接收客户端返回的验证码，验证接收的验证码是否合法，如果是，则通过验证。

如果验证失败，则拒绝返回业务响应。

本实例中，所述业务参数包含A1、B1和Time，Time为接收第一业务请求的时间，将加密串表示为Token，加密串可具体为带有上下文信息的加密串。

步骤203，CGI2接收来自客户端的第二业务请求。

该第二业务请求为添加B做好友的请求。客户端将Token包含在第二业务请求中发送给服务器；将该请求包含的参数表示为：参数(A2，B2)。

步骤204，CGI2判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取业务参数，对后一业务请求中的加密串进行解密。

如果不包含加密串，则拒绝返回业务响应。

步骤205，CGI2将解密得到的主用户名与从CGI1获取的主用户名进行比较，如果相同，则执行步骤206；否则，验证失败。

判断A1和A2是否相同，如果相同，则通过验证，执行步骤206。

步骤206，CGI2将解密得到的被请求用户名与从CGI1获取的被请求用户名进行比较，如果相同，则执行步骤207；否则，验证失败。

判断B1和B2是否相同，如果相同，则执行步骤207；否则，验证失败。

步骤207，CGI2判断接收后一业务请求的时间与解密得到的时间间隔是否在设定范围内，如果是，则通过验证。

将接收后一业务请求的时间表示为Time2，将Time1与Time2的时间间隔表示为Time，将设定范围表示为M，判断Time是否小于或等于M，如果是，则通过验证，否则，认为是非法业务请求，验证失败。

本实施例中，步骤204之后，按照主用户名、被请求用户名和时间间隔的顺序进行验证；在实际应用中，对主用户名、被请求用户名和时间间隔三者的验证，可无序执行。

步骤208，CGI2对第二业务请求进行处理，向客户端反馈第二业务响应。

CGI2将B添加为A的好友，向服务器返回添加完成的响应。

本发明利用加密串，将一个CGI业务包含的多个CGI在逻辑上关联起来。当用户访问第一个CGI时，需要输入验证码，使得服务器能够甄别合法用户和机器用户；如果校验验证码成功，则派发一个带有一些上下文信息的加密串给浏览器，在访问后一CGI时，必须带上该加密串；后一个CGI解析该加密串进行用户的合法性验证。这样，可以将多个相关联的CGI形成一个状态机，使得恶意用户无法单独地对中间的某一CGI发起业务请求，所谓状态机，指逻辑上关联的整体；同时只需要在第一个CGI处设置验证码保护，而不是像现有技术那样针对每个业务请求进行验证码验证。

参见图3，为本发明CGI业务的保护系统结构示意图，该系统包括客户端和服务器；

所述客户端，用于向所述服务器发送前一业务请求，接收服务器反馈的加密串，将加密串包含在后一业务请求中发送给所述服务器；

所述服务器包含的前一CGI，用于接收来自客户端的前一业务请求，向客户端反馈加密串；

所述服务器包含的后一CGI，用于接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

可选地，该服务器包括前一CGI和后一CGI；

所述前一CGI，用于接收来自客户端的前一业务请求，向客户端反馈加密串；

所述后一CGI，用于接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

可选地，所述前一CGI包括加密单元，用于对业务参数进行加密，得到加密串；

所述后一CGI包括第一验证单元，用于判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取加密串，与后一业务请求中包含的加密串进行比较，如果相同，则通过验证。

可选地，所述后一CGI包括第二验证单元，用于判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取业务参数，并对后一业务请求中的加密串进行解密，将得到的解密信息与从前一CGI获取的业务参数进行比较，如果相同，则通过验证。

本发明建立在验证码技术的基础之上，可用于解决复杂Web应用程序的CGI保护问题，在不伤害用户体验的前提下，用最少的开发代价实现了对多个CGI的安全保护。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种通用网关接口CGI业务的保护方法，其特征在于，该方法包括：

前一CGI接收来自客户端的前一业务请求，向客户端反馈加密串；

后一CGI接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

2.如权利要求1所述的方法，其特征在于，所述验证后一业务请求中是否包含所述加密串包括：

判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取加密串，与后一业务请求中包含的加密串进行比较，如果相同，则通过验证。

3.如权利要求1所述的方法，其特征在于，前一CGI向客户端反馈的加密串的获取方法包括：对业务参数进行加密，得到加密串；

所述验证后一业务请求中是否包含所述加密串包括：判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取业务参数，并对后一业务请求中的加密串进行解密，将得到的解密信息与从前一CGI获取的业务参数进行比较，如果相同，则通过验证。

4.如权利要求3所述的方法，其特征在于，所述业务参数包括主用户名和被请求用户名；

所述将得到的解密信息与从前一CGI获取的业务参数进行比较包括：将解密得到的主用户名与从前一CGI获取的主用户名进行比较，如果相同，则将解密得到的被请求用户名与从前一CGI获取的被请求用户名进行比较，如果相同，则通过验证。

5.如权利要求4所述的方法，其特征在于，所述业务参数还包括接收第一业务请求的时间；

判断出解密得到的被请求用户名与从前一CGI获取的被请求用户名相同之后，该方法还包括：判断接收后一业务请求的时间与解密得到的时间间隔是否在设定范围内，如果是，则通过验证。

6.如权利要求1至5中任一项所述的方法，其特征在于，当所述前一CGI为第一CGI时，所述前一CGI向客户端反馈加密串之前，该方法还包括：

随机生成验证码图片，向客户端发送验证码图片；

接收客户端返回的验证码，判断是否合法，如果是，则执行所述向客户端反馈加密串的步骤。

7.一种通用网关接口业务的保护系统，其特征在于，该系统包括客户端和服务器；

所述客户端，用于向所述服务器发送前一业务请求，接收服务器反馈的加密串，将加密串包含在后一业务请求中发送给所述服务器；

所述服务器包含的前一CGI，用于接收来自客户端的前一业务请求，向客户端反馈加密串；

所述服务器包含的后一CGI，用于接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

8.一种服务器，其特征在于，该服务器包括前一CGI和后一CGI；

所述前一CGI，用于接收来自客户端的前一业务请求，向客户端反馈加密串；

所述后一CGI，用于接收来自客户端的后一业务请求，验证后一业务请求中是否包含所述加密串，如果是，则通过验证，向客户端反馈第二业务响应。

9.如权利要求8所述的服务器，其特征在于，所述前一CGI包括加密单元，用于对业务参数进行加密，得到加密串；

所述后一CGI包括第一验证单元，用于判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取加密串，与后一业务请求中包含的加密串进行比较，如果相同，则通过验证。

10.如权利要求8或9所述的服务器，其特征在于，所述后一CGI包括第二验证单元，用于判断后一业务请求中是否包含加密串，如果是，则从前一CGI获取业务参数，并对后一业务请求中的加密串进行解密，将得到的解密信息与从前一CGI获取的业务参数进行比较，如果相同，则通过验证。

Images