WO2018112878A1

WO2018112878A1 - Token mechanism-based system and method for detecting and defending against cc attack

Info

Publication number: WO2018112878A1
Application number: PCT/CN2016/111695
Authority: WO
Inventors: 覃武权
Original assignee: 深圳投之家金融信息服务有限公司
Priority date: 2016-12-23
Filing date: 2016-12-23
Publication date: 2018-06-28
Also published as: CN108476199A

Abstract

Disclosed by the present invention are a token mechanism-based system and method for detecting and defending against a challenge collapsar (CC) attack, comprising a token detection unit, a token distribution unit, a defense configuration unit and a token management unit. The defense configuration unit is used for reading configuration and issuing a configuration instruction to the token detection unit; the token distribution unit is used for applying for a token from the token management unit and distributing the token to a requesting user, the token distributed by the token distribution unit comprising a token script code; the token detection unit is used for responding to a configuration command issued by the defense configuration unit and determining whether to enable a detection function; and the token management unit is used for responding to requests from the token distribution unit and the token detection unit. The present invention may achieve the purpose of detecting and defending against a CC attack at a first time.

Description

System and method for detecting and defending CC attacks based on token mechanism

Technical field

The present invention relates to the field of network security technologies, and in particular, to a system and method for detecting and defending against CC attacks based on a token mechanism for implementing web secure access.

Background technique

In the prior art, it is usually impossible to resist the CC attack for the first time, that is, a CC attack is required, and the defense system collects some information, and the system responds, and the second attack can be defended. If it is a behavior-based defense method, there are more attacks that need to be tolerated, that is, the attack system will recognize the attacker.

Summary of the invention

The present invention provides a system and method for detecting and defending against CC attacks based on a token mechanism, which can detect and defend against CC attacks at the first time.

The technical solution of the present invention is implemented as follows:

A system for detecting and defending a CC attack based on a token mechanism, comprising a token detecting unit, a token assigning unit, a defense configuration unit, and a token management unit, wherein the defense configuration unit is configured to read a configuration, to the order The token detecting unit sends a configuration instruction; the token assigning unit is configured to apply a token to the token management unit, and allocate the token to the requesting user, where the token assigned by the token assigning unit includes a token script code; The token detecting unit is configured to determine whether to enable the detecting function in response to the configuration command sent by the defense configuration unit, and the token management unit is configured to respond to the request of the token allocating unit and the token detecting unit.

Further, the token includes a token identification code and a token script code, the token identifier is a set of characters consisting of numbers or letters, and the token script code is used to generate the token The script of the identification code, the user access terminal may calculate the token identification code according to the token script code.

Further, the token information database is further configured to allocate a unique random User ID to the visiting user, and store information about the token corresponding to each User ID row, including the token identifier and the token. Script code and token creation time.

Further, the configuration that is read by the defense configuration unit includes three configurations, namely, a blacklist, a whitelist, and a check whether the IP address is detected, and the blacklist is a set of user access IPs that are not passed through. Detecting the set of user access IPs that pass through, whether to enable detection to determine whether to enable blacklist and whitelist detection, and if not, to forward the user access request to the protected service system.

A method for detecting and defending a CC attack based on a token mechanism includes the following steps:

Step 1, receiving the user's HTTP request, reading the configuration, determining whether the detection function is enabled, and if so, proceeding to step 2;

Step 2: Determine whether the user access IP is a whitelist or a blacklist. If not, determine whether the CC defense is enabled. If not, allow the user to access, otherwise go to step 3.

Step 3: Determine whether the HTTP request packet header contains a token. If yes, whether the verification token is consistent with the registration, if the agreement is consistent, the user is allowed to access, otherwise the user's HTTP request is redirected to the original request URL; if the HTTP request packet is The header does not contain the token, go to step 4;

Step 4: Assign a token to the user, redirect the user's HTTP request to the original request URL; the token includes a token script code and a token identifier.

Further, step 2 specifically includes the following steps:

Step 201, determining whether the user access IP belongs to the white list, and if so, allowing the user to access, if not, proceeding to step 202;

Step 202: Determine whether the user access IP belongs to the blacklist, and if yes, reject the user access, and if not, proceed to the next step;

In step 203, it is determined whether the CC defense is enabled. If not, the user is allowed to access, otherwise, the process proceeds to step 3.

Further, in step 3, if the verification token is inconsistent with the registration, it is determined whether the verification number exceeds the threshold, and if so, the user access IP is added to the blacklist, otherwise the user's HTTP request is redirected to the original request URL.

Further, step 4 specifically includes the following steps:

Step 401: The token assigning unit sends a request to the token management unit to apply for a token, and sends a unique random User ID to the visiting user to be sent to the token management unit.

Step 402: The token management unit extracts a token template from the token mouch block, and generates a corresponding token script code and a token identification code according to the random user ID and the token template.

In step 403, the token related information is sent to the token information database for storage.

Further, the token identification code is a set of characters consisting of numbers or letters, and the token script code is a script for generating the token identifier, and the user access terminal can obtain token identification according to the token script code operation. code.

Further, in step 3, verifying whether the token is consistent with the registration specifically includes the following steps:

The information related to the token is extracted from the token information database and compared with the token in the HTTP request packet header of the user.

The invention has the beneficial effects that the user needs to carry the token, and the token contains the token script code, that is, a piece of code, which is difficult for the CC attacker to obtain, thereby achieving the purpose of detecting and defending the CC attack in the first time.

DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below. Obviously, the drawings in the following description are only It is a certain embodiment of the present invention, and other drawings can be obtained from those skilled in the art without any inventive labor.

1 is a schematic block diagram of a system for detecting and defending against CC attacks based on a token mechanism according to the present invention;

2 is a flow chart of a method for detecting and defending a CC attack based on a token mechanism according to the present invention.

detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

As shown in FIG. 1 , the present invention provides a system for detecting and defending against CC attacks based on a token mechanism, including a token detecting unit, a token assigning unit, a defense configuration unit, and a token management unit, and the defense configuration unit is used for Reading the configuration, sending a configuration instruction to the token detecting unit; the token assigning unit is configured to apply for a token to the token management unit, and allocate the token to the requesting user, and the token assigned by the token assigning unit includes the token script code; The token detection unit is configured to determine whether to enable the detection function in response to the configuration command issued by the defense configuration unit, and if not, directly forward the user request to the protected service system of the back end; if enabled, determine the user to visit the IP first. If it is in the whitelist, it can pass. If it is in the blacklist, it will be rejected directly. Otherwise, the token needs to be verified. At this point, it will first determine whether there is a token in the HTTP header of the request. If it does not exist, the request is redirected to the token allocation unit. Otherwise, the token management unit is requested to verify whether the token is legal. If it is not legal, it will be rejected. Otherwise, it will be rejected. The request is forwarded to the backend protected service system; the token management unit is configured to respond to the request of the token allocation unit and the token detecting unit, and when the token assigning unit requests the token from the token management unit, the token allocation is recorded The global unique random UserID of the visiting user submitted by the unit, and then extracts the token template from the implemented token template library, and combines the UserID and the token template to generate a specific token script code and token identifier (analog The title and answer), and recorded in the token information database for reference. When the token detecting unit requests the token management unit whether the verification token is legal, according to the UserID and the token identification, in the token information database, whether the originally assigned token information is consistent, and returns the comparison result.

The token includes a token identification code and a token script code, the token identification code is a set of characters consisting of numbers or letters, and the token script code is a script for generating a token identification code, and the user access terminal can be ordered according to The card script code operation obtains the token identification code. The token consists of the token identifier and the token script code in pairs instead of only one identifier. This avoids the token identifier being transmitted directly on the network, which improves the effectiveness of defending against CC attacks.

The token information database is further configured to allocate a unique random User ID to the visiting user, and store information about the token corresponding to each User ID row, including the token identifier, the token script code, and the token. Create time.

The configuration of the defensive configuration unit includes three configurations, namely, blacklist, whitelist, and whether to enable detection. The blacklist is a collection of IP addresses that the user does not pass (such as the IP that has been confirmed as the attack source), and the whitelist. In order to detect the set of user access IPs that pass all the way (such as exempting the search engine crawler and exempting the trust IP), whether to enable the detection to determine whether to enable the blacklist and white name Single detection, if not, forwards the user access request to the protected service system, ie, agrees to the user's access.

The invention can prevent the CC attack in the first time, because the browser jump idea is introduced in the defense system, the first access does not carry the token identification code, and the token detection unit causes the user terminal to perform the 302 jump. After the token allocation code is obtained, the token execution code is executed again, and 302 is returned to the token detection unit.

The token script code is a piece of code (more specifically, a piece of javascript code) that requires an operation to get the token identifier. This process is complicated for the attacker, but the browser is very simple. Defend the purpose of the attacker.

As shown in FIG. 2, the present invention also provides a method for detecting and defending a CC attack based on a token mechanism, which specifically includes the following steps:

Step 2 specifically includes the following steps:

Step 3: Determine whether the HTTP request packet header contains a token. If yes, whether the verification token is consistent with the registration, if the agreement is consistent, the user is allowed to access, otherwise the user's HTTP request is redirected to the original request URL; if the HTTP request packet is The packet header does not contain the token, and the process proceeds to step 4. In step 3, if the verification token is inconsistent with the registration, it is determined whether the verification number exceeds the threshold. If yes, the user access IP is added to the blacklist, otherwise the user's HTTP request is sent. Redirect to the original request URL.

In step 3, verifying whether the token is consistent with the registration specifically includes the following steps:

Step 4 specifically includes the following steps:

Step 401, the token assigning unit sends a request to the token management unit to apply for a token, and sends a unique random User ID to the visiting user to the token management unit;

The token identification code is a set of characters consisting of numbers or letters. It is a random code randomly assigned by the defense system to the access terminal on the server side. The random code is a pair with the token script code, which can be based on the token script code. The token script code is a script for generating a token identification code, and the user access terminal can obtain the token identification code according to the token script code operation. The token script code is a script for generating a token identification code, and the defense system allocates a script for the access terminal, and the access terminal can calculate the token identification code according to the script. During the access process, the defense system delivers the token script code. The access terminal obtains the token identification code according to the token script code operation, and then carries the token identification code in the accessed http packet header, and the defense system determines whether the submitted token identification code is consistent with the expected, thereby determining whether to allow the access terminal to continue. access.

Give the user a piece of script code. The result of successful operation is the token identification code. In this way, it is a browser or a attack program. The intent of this design is to confirm that the client accessing the protected website is a normal browser user, not a program with attack instructions. For normal browser users, the browser can access the website through the browser, and the browser can easily execute the token script code (because this is the function of the browser), and the operation obtains the token identifier. For the attack program, to develop a set of software to run the script code, this cost is extremely high for the attacker. Therefore, the goal of defending against the attacker is achieved.

For the token script code, a specific example is as follows:

Var codeTable="1234567890";

Var token=(parseInt(codeTable.substr(1,2))*2000+((10+parseInt(codeTable.substr(7,1)))*54))*3+20000000;

The script code is the syntax of javascript, and the result of the browser terminal operation is the token identification code:

20140916

Take the user's first visit to the website as an example. After several interactions, you can access the protected site.

(1) The first access, the request is initiated to the token detection unit, and the token identification code is not carried at this time. The http request is as follows:

GET/HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv: 47.0) Gecko/20100101Firefox/47.0

Accept: text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0.8

Accept-Language: zh-CN, zh; q = 0.8, en-US; q = 0.5, en; q = 0.3

Accept-Encoding: gzip, deflate

Connection: keep-alive

Cache-Control: max-age=0

The token detecting unit does not detect the expected token identification code in the http request packet, returns a 302 jump, and causes the user terminal to request the token allocation unit http://www.example.com/cc_code_assign, and the http response packet is as follows:

HTTP/1.1302Moved Temporarily

Server: TZJ/1.0

Date:Mon,18Jul 201614:09:37GMT

Content-Type: text/html;charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

Vary: Accept-Encoding

X-Powered-By: PHP/7.0.3

Content-Encoding: gzip

Location: http://www.example.com/cc_code_assign

(2) The client turns to the request token allocation unit, and the http request is:

GET/cc_code_assign HTTP/1.1

Host: www.example.com

Accept: text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0.8

Accept-Language: zh-CN, zh; q = 0.8, en-US; q = 0.5, en; q = 0.3

Accept-Encoding: gzip, deflate

Connection: keep-alive

Cache-Control: max-age=0

The token allocation unit prepares the {token identification code, token script code} after receiving the request, wherein

●Token identification code=20140916

●Token script code =

Var+codeTable+%3d+%26quot%3b1234567890%26quot%3b%3bvar+token+%3d+(parseInt(codeTable.substr(1%2c+2))*2000+%2b+((10%2bparseInt(codeTable.substr(7%) 2c+1)))*54))*3%2b20000000%3b

This pair is stored in the token information database, and the token script code is passed back to the client's response packet. The returned http request is also a 302 jump indicating that the terminal wants to access the token detection unit. The http header is:

HTTP/1.1302Moved Temporarily

Server: TZJ/1.0

Date:Mon,18Jul 201614:09:37GMT

Content-Type: text/html;charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

Vary: Accept-Encoding

X-Powered-By: PHP/7.0.3

Content-Encoding: gzip

Location: http://www.example.com/

Cookie: CC_TOKEN_SCRIPT=

Var+codeTable+%3d+%26quot%3b1234567890%26quot%3b%3bvar+token+%3d+(parseInt(

codeTable.substr(1%2c+2))*2000+%2b+((10%2bparseInt(codeTable.substr(7%2c+1)))

*54))*3%2b20000000%3b

Note: Cookie: CC_TOKEN_SCRIPT this line is the line of the token script code issued.

(3) The user terminal obtains CC_TOKEN_SCRIPT from the http request packet obtained by the token allocation unit. This is the token script code allocated by the defense system, and the code is obtained after the urlcode:

Var codeTable="1234567890";

This is a piece of javascript code, run the result: 20140916, and then use the result as a token identifier, carried in the http request packet, requesting the defense system:

GET/HTTP/1.1

Host: www.example.com

Accept: text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0.8

Accept-Language: zh-CN, zh; q = 0.8, en-US; q = 0.5, en; q = 0.3

Accept-Encoding: gzip, deflate

Connection: keep-alive

Cache-Control: max-age=0

Cookie: CC_TOKEN_CODE=20140916

The defense detection unit obtains the CC_TOKEN_CODE item from the http request packet, and the comparison is consistent with the previously assigned value, thus permitting access to the protected system at the back end.

The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., which are included in the spirit and scope of the present invention, should be included in the present invention. Within the scope of protection.

Claims

A system for detecting and defending a CC attack based on a token mechanism, comprising: a token detecting unit, a token assigning unit, a defense configuration unit, and a token management unit, wherein the defense configuration unit is configured to read a configuration, And sending a configuration instruction to the token detecting unit; the token assigning unit is configured to apply a token to the token management unit, and allocate the token to the requesting user, where the token allocated by the token assigning unit includes a command The token detection unit is configured to determine whether to enable the detection function in response to the configuration command issued by the defense configuration unit; the token management unit is configured to respond to the request of the token allocation unit and the token detection unit .
The system for detecting and defending a CC attack based on a token mechanism according to claim 1, wherein the token comprises a token identification code and a token script code, and the token identifier is a group A character string consisting of a number or a letter, the token script code being a script for generating the token identifier, and the user access terminal may calculate the token identifier according to the token script code.
The system for detecting and defending a CC attack based on a token mechanism according to claim 2, further comprising: a token information database, wherein the token information database is configured to allocate a unique random User ID to the visiting user. , storing information about the token corresponding to each User ID line, including the token identification code, the token script code, and the token creation time.
The system for detecting and defending a CC attack based on the token mechanism according to claim 1, wherein the configuration read by the defense configuration unit includes three configurations, namely, a blacklist, a whitelist, and whether to open. The blacklist is configured to detect a set of user access IPs that are not passed, and the whitelist is a set of user access IPs that are uniformly passed, and whether the detection is enabled to determine whether to enable blacklist and whitelist detection, and if not , forwards the user access request to the protected business system.
A method for detecting and defending a CC attack based on a token mechanism, which is characterized by the following steps:

Step 1, receiving the user's HTTP request, reading the configuration, determining whether the detection function is enabled, and if so, proceeding to step 2;

Step 2: Determine whether the user access IP is a whitelist or a blacklist. If not, determine whether the CC defense is enabled. If not, allow the user to access, otherwise go to step 3.

Step 3: Determine whether the HTTP request packet header contains a token. If yes, whether the verification token is consistent with the registration, if the agreement is consistent, the user is allowed to access, otherwise the user's HTTP request is redirected to the original request URL; if the HTTP request packet is The header does not contain the token, go to step 4;

Step 4: Assign a token to the user, redirect the user's HTTP request to the original request URL; the token includes a token script code and a token identifier.
The method for detecting and defending a CC attack based on a token mechanism according to claim 5, wherein the step 2 comprises the following steps:

Step 201, determining whether the user access IP belongs to the white list, and if so, allowing the user to access, if not, proceeding to step 202;

Step 202: Determine whether the user access IP belongs to the blacklist, and if yes, reject the user access, and if not, proceed to the next step;

In step 203, it is determined whether the CC defense is enabled. If not, the user is allowed to access, otherwise, the process proceeds to step 3.
The method for detecting and defending a CC attack based on a token mechanism according to claim 5, wherein in step 3, if the verification token is inconsistent with the registration, it is determined whether the verification number exceeds a threshold, and if so, The user access IP is added to the blacklist, otherwise the user's HTTP request is redirected to the original request URL.
The method for detecting and defending a CC attack based on a token mechanism according to claim 5, wherein the step 4 comprises the following steps:

Step 401: The token assigning unit sends a request to the token management unit to apply for a token, and sends a unique random User ID to the visiting user to be sent to the token management unit.

Step 402: The token management unit extracts a token template from the token mouch block, and generates a corresponding token script code and a token identification code according to the random user ID and the token template.

In step 403, the token related information is sent to the token information database for storage.
A method for detecting and defending a CC attack based on a token mechanism according to claim 8, wherein the token identification code is a set of characters consisting of numbers or letters, and the token script code is used to generate The token identification code script, the user access terminal may obtain the token identification code according to the token script code operation.
The method for detecting and defending a CC attack based on a token mechanism according to claim 8, wherein in step 3, verifying whether the token is consistent with the registration specifically includes the following steps:

The information related to the token is extracted from the token information database and compared with the token in the HTTP request packet header of the user.