CN108259619B

CN108259619B - Network request protection method and network communication system

Info

Publication number: CN108259619B
Application number: CN201810091901.4A
Authority: CN
Inventors: 罗频捷; 温荷; 刘毅; 巨星
Original assignee: Chengdu Neusoft University
Current assignee: Chengdu Neusoft University
Priority date: 2018-01-30
Filing date: 2018-01-30
Publication date: 2021-08-24
Anticipated expiration: 2038-01-30
Also published as: CN108259619A

Abstract

The application provides a network request protection method and a network communication system, wherein the network communication system comprises a server and a user terminal system which are communicated with each other; the method comprises the following steps: the method comprises the steps that a server obtains a first HTTP request sent by a user terminal; the server replaces preset characters in the first HTTP request to obtain a second HTTP request, and detects whether preset sensitive keywords are included; if the sensitive keyword is not included, the server acquires and verifies whether the Referer value in the first HTTP request starts with the preset domain name or not, and verifies that the token value in the first HTTP request is the preset value. Therefore, sensitive keywords in the HTTP request are shielded, and the request is verified by combining the refer field and the token to identify and eliminate cross-site scripting attack and cross-site request forgery, so that the safety of data interaction between a legal user terminal and a server is improved.

Description

Network request protection method and network communication system

Technical Field

The present application relates to the field of network security technologies, and in particular, to a network request protection method and a network communication system.

Background

With the continuous development of network technology and the popularization of personal computer terminals, scenes for realizing various information interactions by means of the internet are more and more abundant. In the process of data interaction through a webpage, communication between a legal user terminal and a server may be attacked, so that an attacker operates the server by using the identity of the legal user terminal. In the prior art, the attack is only protected by a plurality of single means, the protection mode is not comprehensive, and the attack is easily bypassed by an attacker and cannot be effectively protected.

Disclosure of Invention

In order to overcome the above disadvantages in the prior art, the present application aims to provide a network request protection method, which is applied to a system including a server and a user terminal that communicate with each other; the method comprises the following steps:

the server acquires a first HTTP request sent by a user terminal;

the server replaces preset characters in the first HTTP request to obtain a second HTTP request, and detects whether the second HTTP request comprises preset sensitive keywords or not;

if the second HTTP request is detected not to include the sensitive keyword, the server acquires and verifies whether a Referer value in the first HTTP request starts with a preset domain name or not, and verifies that a token value in the first HTTP request is a preset value;

and if the server detects that the refer value in the first HTTP request starts with a preset domain name and the token value in the first HTTP request is the preset value, the server responds to the first HTTP request.

Optionally, in the above method, the first HTTP request comprises a login request; the server prestores a corresponding relation between a user account and a first reference hash value, wherein the first reference hash value is generated in advance according to the user account and a corresponding user password; if it is detected that the refer value in the first HTTP request starts with a preset domain name and the token value in the first HTTP request is the preset value, the step of the server responding to the first HTTP request includes:

if the server detects that the Referer value in the login request starts with a preset domain name and the token value in the first HTTP request is the preset value, the server sends a randomly generated salt value to the user terminal, wherein the login request comprises a user account;

the user terminal generates a first verification hash value according to a login account and a login password input by a user, generates a second verification hash value according to the first verification hash value and the salt value, and sends the second verification hash value to the server;

the server searches the corresponding first reference hash value according to the user account, and generates a second reference hash value according to the first reference hash value and the salt value;

and the server detects whether the second verification hash value is the same as the second reference hash value or not, and sends a login success notification to the user terminal if the second verification hash value is the same as the second reference hash value.

Optionally, in the above method, the first HTTP request includes a user information upload request; the method further comprises the following steps:

the user terminal receives user information input by a user, and generates the first HTTP request and uploads the first HTTP request to the server after the user information is subjected to XOR encryption by adopting a preset key to obtain a ciphertext;

and after responding to the first HTTP request, the server decrypts the ciphertext by adopting the preset key to obtain the user information.

Optionally, in the method, the server is preset with a plurality of Struts2 interceptors and records a list of the plurality of Struts2 interceptors; the step of detecting whether the second HTTP request includes a preset sensitive keyword includes:

and sequentially calling the plurality of Struts2 interceptors to detect the second HTTP request according to the list so as to judge whether the second HTTP request comprises preset sensitive keywords.

Optionally, in the above method, the method further comprises:

and the user terminal adds a token in a URL address included in the HTTP request to be sent as the first HTTP request and sends the first HTTP request to the server.

Optionally, in the above method, the method further comprises:

and the user terminal adds a token in the attribute preset in the header field part of the HTTP request to be sent and then sends the HTTP request to the server as the first HTTP request.

Another object of the present application is to provide a network communication system, which includes a server and a user terminal communicating with each other;

the server acquires a first HTTP request sent by a user terminal;

Optionally, in the above system, the first HTTP request comprises a login request; the server prestores a corresponding relation between a user account and a first reference hash value, wherein the first reference hash value is generated in advance according to the user account and a corresponding user password;

if the server detects that the refer value in the login request starts with a preset domain name and the token value in the first HTTP request is the preset value, the server sends a randomly generated salt value to the user terminal, wherein the login request comprises a user account;

Optionally, in the system, the first HTTP request includes a user information upload request;

Optionally, in the system, the server is preset with a plurality of Struts2 interceptors and a list recording the plurality of Struts2 interceptors;

and the server sequentially calls the plurality of Struts2 interceptors to detect the second HTTP request according to the list so as to judge whether the second HTTP request comprises preset sensitive keywords.

Compared with the prior art, the method has the following beneficial effects:

according to the network request protection method and the network communication system, sensitive keywords in the HTTP request are shielded, and the request is verified by combining the refer field and the token, so that cross-site script attack and cross-site request forgery are identified and eliminated, and the security of data interaction between a legal user terminal and a server is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.

Fig. 1 is a schematic diagram of a network communication system provided in an embodiment of the present application;

fig. 2 is a flowchart illustrating steps of a network request protection method according to an embodiment of the present application;

fig. 3 is a second flowchart illustrating steps of a network request protection method according to an embodiment of the present application;

fig. 4 is a third schematic step flow chart of a network request protection method according to an embodiment of the present application.

Icon: 10-a network communication system; 100-a server; 200-a user terminal; 300-network.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations.

Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

In the description of the present application, it is noted that the terms "first", "second", "third", and the like are used merely for distinguishing between descriptions and are not intended to indicate or imply relative importance.

In the description of the present application, it is further noted that, unless expressly stated or limited otherwise, the terms "disposed," "mounted," "connected," and "connected" are to be construed broadly, e.g., as meaning either a fixed connection, a removable connection, or an integral connection; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meaning of the above terms in the present application can be understood in a specific case by those of ordinary skill in the art.

Referring to fig. 1, the present embodiment provides a network communication system 10, which includes a server 100 and at least one user terminal 200 that communicate with each other. In this embodiment, the user terminal 200 may access a WEB site provided by the server 100 through the network 300, and data interaction between the user terminal 200 and the server 100 may be performed through an HTTP protocol.

Referring to fig. 2, fig. 2 is a flowchart of a network request protection method applied to the network communication system 10 shown in fig. 1, and the method including various steps will be described in detail below.

In step S110, the server 100 obtains a first HTTP request sent by the user terminal 200.

In this embodiment, protection against Cross Site Scripting (XSS) attack is considered first. XSS is an attack mode for inserting malicious Script codes into a Web page, and when a user browses the Web page, the Script codes embedded into the Web page can be executed, so that the purpose of maliciously attacking the user is achieved. Since the XSS attacks the HTTP request, the attacker can hide the Script code by some means, in this embodiment, the keyword in the HTTP request is identified and restored in step S120, and then the detection masking is performed.

Step S120, the server 100 replaces the preset characters in the first HTTP request to obtain a second HTTP request, and detects whether the second HTTP request includes preset sensitive keywords.

In this embodiment, after receiving the first HTTP request, the server 100 replaces the preset characters summarized by the first HTTP request, for example, the preset characters in the first HTTP request may be replaced and removed by a regular expression. The alternatives are as follows:

A. and replacing and deleting the < '> and the >' characters in the first HTTP request, and putting the content input by the user in the first HTTP request into a single quotation mark, so that the isolation of the user input data and the code of the HTTP request is basically realized.

B. And replacing and deleting the double quotation mark characters in the first HTTP request to prevent the user from crossing the allowed mark and adding a custom mark.

C. The replacement deletes TAB characters and space characters in the first HTTP request to prevent keywords from being split around checks.

D. And replacing the script key words in the first HTTP request.

E. The "& #" character is deleted instead to prevent the HTML attribute from bypassing the check.

Thus, the first HTTP request is processed to obtain a second HTTP request.

In this embodiment, the identification of the sensitive keyword may be performed on the second HTTP request using a Struts2 interceptor. The server 100 is pre-configured with a plurality of Struts2 interceptors and a list recording the plurality of Struts2 interceptors. Wherein the plurality of Struts2 interceptors are an implementation of Aspect Oriented Programming (AOP), and are configurable when enabled.

The server 100 sequentially calls the plurality of Struts2 interceptors to detect the second HTTP request according to the list, so as to determine whether the second HTTP request includes a preset sensitive keyword.

And if the sensitive keywords are detected to be included in the second HTTP request, not responding to the first HTTP request.

If it is detected that the second HTTP request does not include the sensitive keyword, step S130 is performed to perform identification protection on Cross-site request forgery (CSRF for short).

Step S130, if it is detected that the second HTTP request does not include the sensitive keyword, the server 100 obtains and verifies whether the refer value in the first HTTP request starts with a preset domain name, and verifies that the token value in the first HTTP request is a preset value.

In this embodiment, the preset domain name may be a domain name of a WEB site provided by the server 100.

CSRF is an attack mode in which an attacker unauthorized operates the server 100 by the identity of a legitimate user terminal, for example, a CSRF attack may falsify a request sent to a victim site on behalf of the victim without the victim knowing it, and thus perform an operation under authority protection without authorization. For example, where the victim Bob has a deposit at the bank, Bob may be caused to transfer 1000000 deposits under Bob's 2 account by sending a request to the bank's website as follows:

HTTP://bank.example/withdrawaccount＝bob&amount＝1000000&for＝bob2

typically, after the request is sent to the website, the server 100 will verify that the request is from a legitimate session (session) and that the user Bob of the session has successfully logged in. The hacker Mallory also has an account with the bank himself and knows that the URL in the above text can transfer money. Mallory may then send itself a request to the bank as follows:

HTTP://bank.example/withdrawaccount＝bob&amount＝1000000&for＝Mallory

but this request comes from Mallory, not Bob, he cannot pass the security authentication and therefore the request does not work.

In this case, Mallory may create a website through CSRF attack, and put the following codes into the website:

src＝HTTP://bank.example/withdrawaccount＝bob&amount＝1000000&for＝Mal lory

and entices Bob to visit his website through an advertisement or the like. When Bob accesses the website, the URL is sent from Bob's browser to the bank, and the request is sent to the bank server 100 with the cookie in Bob's browser. In most cases, the request will fail because he requires Bob's authentication information. However, if the session between his browser and his bank website has not expired shortly after Bob happens to visit his bank, the cookie of the browser contains Bob's authentication information. At this point, the URL request is responded to and money is transferred from Bob's account to Mallory's account, all of which is unknown to Bob at that time. After that Bob finds that the account is low in money, even if he goes to the bank to inquire the log, he can only find that there is really a legal request from himself to transfer the funds, and there is no trace of attack. While Mallory can get away from the leisure after money.

Therefore, in this embodiment, CSRF is protected by verifying the refer field in the HTTP request and adding token verification to the request address.

Specifically, according to the specification of the HTTP protocol, there is a refer field in the HTTP request header, which records the source address of the HTTP request. In general, a request to access a security restricted page comes from the same website, such as the following:

http://bank.example/withdrawaccount＝bob&amount＝1000000&for＝Mallory

example, the user must first log on to the bank and then trigger a transfer event by clicking a button on the page. In this case, the refer value of the transfer request is the URL of the page where the transfer button is located, and is usually the address beginning with the bank name. Whereas if a hacker wants to implement a CSRF attack on a bank's website, he can only construct a request at his own website, and when the user sends a request to the bank through the hacker's website, the Referer of the request is directed to the hacker's own website. Therefore, to defend against CSRF attacks, the bank website only needs to verify the Referer value of each transfer request, and if the domain name starts with bank. If the Referer is another web site, it may be a CSRF attack by a hacker, denying the request.

However, the value of Referer is provided by the browser, and although there is a clear requirement on the HTTP protocol, there may be a difference between each browser and the specific implementation of Referer, and it cannot be guaranteed that the browser itself has no security hole. The method for verifying the Referer value is to rely on a third party (i.e. a browser) to ensure the security, and theoretically, the method is not safe. In fact, for some browsers, such as IE6 or FF2, there are currently some ways to tamper with the Referer value. If the bank.example website supports the IE6 browser, a hacker can completely set the refer value of the user browser to the address beginning with the bank.example domain name, so that the CSRF attack can be carried out through verification.

Therefore, in this embodiment, a randomly generated token may be added to the HTTP request, and an interceptor may be established at the server 100 to verify the token, and if there is no token in the request or the content of the token is incorrect, the request may be considered to be a CSRF attack and rejected.

In an implementation manner of this embodiment, the user terminal 200 adds a token to a URL address included in an HTTP request to be sent as the first HTTP request, and sends the first HTTP request to the server 100.

In this embodiment, the token may be generated and placed in the session after the user logs in, and then the token is taken out of the session at each request and compared with the token in the request. For GET requests, token will be appended to the request address, so the URL becomes http:// urlcsrftoken ═ token value. For the POST request, add "input type" name "csrften" value "token value"/> (in terms of "input type"/") at the end of form, so that token is added to the request in the form of a parameter.

In another implementation manner of this embodiment, the user terminal 200 adds a token to an attribute preset in a header field portion of an HTTP request to be sent, and sends the token as the first HTTP request to the server 100.

In this embodiment, the token is placed in a custom attribute in the HTTP header. By using the XMLHttpRequest class, the HTTP header attribute of csrftop can be added to all class requests at one time, and the token value is put into the HTTP header attribute. Therefore, the inconvenience of adding token in the request by the method is solved, meanwhile, the address requested by the XMLHttpRequest cannot be recorded in the address bar of the browser, and the token cannot be leaked to other websites through the Referer.

Based on the design, the embodiment can more effectively defend the CSRF attack by adopting token verification and the combined use of the verification of the HTTP refer field.

In step S140, if it is detected that the refer value in the first HTTP request starts with a preset domain name and the token value in the first HTTP request is the preset value, the server 100 responds to the first HTTP request.

The first HTTP request may include different request types.

In an implementation manner of this embodiment, the first HTTP request may include a login request. The server 100 prestores a corresponding relationship between a user account and a first reference hash value, where the first reference hash value is generated in advance according to the user account and a corresponding user password, and for example, the first reference hash value may be generated by performing MD5 calculation on the user account and the corresponding user password.

Referring to fig. 3, the network communication system 10 may process the first HTTP request through steps S210 to S240.

In step S210, the server 100 sends a randomly generated salt value to the user terminal 200.

In step S220, the user terminal 200 generates a first verification hash value according to the login account and the login password input by the user, generates a second verification hash value according to the first verification hash value and the salt value, and sends the second verification hash value to the server 100.

In this embodiment, the user terminal 200 performs MD5 calculation on the login account and the login password input by the user to obtain the first verification hash value, then performs MD5 calculation on the first verification hash value and the salt value again to obtain a second verification hash value, and transmits the second verification hash value to the server 100.

In step S230, the server 100 searches for the corresponding first reference hash value according to the user account, and generates a second reference hash value according to the first reference hash value and the salt value.

The user account in the login request of the server 100 searches for a corresponding first reference hash value, and then MD5 is performed on the first reference hash value and the salt value to obtain a second verification hash value.

In step S240, the server 100 detects whether the second verification hash value is the same as the second reference hash value, and sends a login success notification to the user terminal 200 if the second verification hash value is the same as the second reference hash value.

In this embodiment, since the hash values generated in steps S220 and S230 are unique when the salt value is unique for one-time login, if the second verification hash value is the same as the second reference hash value, it is determined that the correspondence between the user name and the password input by the user is correct, and the server 100 transmits a login success notification to the user terminal 200.

In another implementation manner of this embodiment, the first HTTP request includes a user information upload request.

Referring to fig. 4, the network communication system 10 may process the user information uploading request through steps S310 and S320.

In step S310, the user terminal 200 receives user information input by a user, performs xor encryption on the user information by using a preset key to obtain a ciphertext, generates the first HTTP request, and uploads the first HTTP request to the server 100.

The principle of xor encryption is that if the initial values of the two parameters are not known, it is not possible to reverse the operation, e.g. if the values of the two variables that are xor-ed are not known, it is not possible to infer the values of the two variables from the result; if A XOR B returns true, it is not known whether A is true, B is false, or A is false, B is true; further, even if the result returns false, it is still not possible to determine whether both are true or false.

However, if the initial value of A or B is known, the XOR operation is fully reversible (unlike a logical AND, logical OR). For example, if A XOR TRUE is TRUE, A is false; a XOR TRUE is false, then A is TRUE. The principle of the exclusive-or encryption is that if the encrypted character string and the encrypted key are possessed at the same time, the decryption can be correctly carried out; without the key, the only way to crack is to make a completely random key and try it one after another until the output of the decryption program is readable text or other similar content. The longer the encryption key, the more difficult it is to break.

In step S320, after responding to the first HTTP request, the server 100 decrypts the ciphertext using the preset key to obtain the user information.

After receiving the first HTTP request sent by the user terminal 200, the server 100 performs xor decryption using the same preset key to obtain the user information. Therefore, the safety of user information transmission is greatly improved.

In summary, the network request protection method and the network communication system provided by the application identify and exclude cross-site scripting attack and cross-site request forgery by shielding sensitive keywords in the HTTP request and verifying the request by combining the Referer field and token, thereby improving the security of data interaction between a legal user terminal and a server.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A network request protection method is characterized in that the method is applied to a system comprising a server and a user terminal which are communicated with each other; the method comprises the following steps:

the server acquires a first HTTP request sent by a user terminal;

if the server detects that the refer value in the first HTTP request is the beginning of a preset domain name and the token value in the first HTTP request is the preset value, the server responds to the first HTTP request;

the step of obtaining a second HTTP request after the server replaces preset characters in the first HTTP request includes:

replacing and deleting the < '> character and the >' character in the first HTTP request, and putting the content input by the user in the first HTTP request into a single quotation mark;

replacing and deleting the double quotation mark characters in the first HTTP request;

replacing and deleting the TAB character and the space character in the first HTTP request;

replacing the script key words in the first HTTP request;

the "& # character is deleted instead.

2. The method of claim 1, wherein the first HTTP request comprises a login request including a user account; the server prestores a corresponding relation between a user account and a first reference hash value, wherein the first reference hash value is generated in advance according to the user account and a corresponding user password; the step of the server responding to the first HTTP request includes:

the server sends a randomly generated salt value to the user terminal;

3. The method of claim 1, wherein the first HTTP request comprises a user information upload request; the method further comprises the following steps:

4. The method according to claim 1, wherein the server is pre-provisioned with a plurality of Struts2 interceptors and records a list of the plurality of Struts2 interceptors; the step of detecting whether the second HTTP request includes a preset sensitive keyword includes:

5. The method of claim 1, further comprising:

6. The method of claim 1, further comprising:

7. A network communication system is characterized by comprising a system of a server and a user terminal which are communicated with each other;

the server acquires a first HTTP request sent by a user terminal;

replacing the script key words in the first HTTP request;

the "& # character is deleted instead.

8. The system of claim 7, wherein the first HTTP request comprises a login request; the server prestores a corresponding relation between a user account and a first reference hash value, wherein the first reference hash value is generated in advance according to the user account and a corresponding user password;

9. The system of claim 7, wherein the first HTTP request comprises a user information upload request;

10. The system according to claim 7, wherein the server is pre-provisioned with a plurality of Struts2 interceptors and records a list of the plurality of Struts2 interceptors;