CN103944900B - It is a kind of that attack prevention method and its device are asked across station based on encryption - Google Patents

Abstract

Attack prevention method is asked across station based on encryption the invention discloses a kind of, applied to the system for including client and server end, methods described includes：Authentication step, client side attack take precautions against step and server end attack-defending step；Authentication step is used to carry out authentication to client by server end；Client side attack takes precautions against the random number token that step is verified as the client the reception server end transmission of validated user by authentication step, and follow-up request is encrypted as CIPHERING REQUEST using random number token；Server end attack-defending step is used in the follow-up CIPHERING REQUEST of the client of received server-side validated user, and checking is decrypted using random number token, and attack-defending is asked across station to realize.Attack-defending device is asked across station based on encryption the invention also discloses a kind of.

Description

An encryption-based cross-site request attack prevention method and device thereof

technical field

The invention relates to network security, mainly browser security and web application security. More specifically, it relates to a method and system for defending against cross-site request forgery attacks by embezzling user rights.

Background technique

A Cross Site Request Forgery (CSRF) attack is an attack method that coerces an end user to perform an operation not intended by the user on a logged-in web application. The target of its attack is users rather than web applications, and it does not need to exploit any browser vulnerabilities, but uses authenticated sessions to attack, that is, exploits implicit authentication vulnerabilities to achieve attacks.

Cross-site request forgery is a relatively subtle attack. The victim may accidentally click a malicious link and be exploited by the attacker. The essence is that the attacker steals the identity of the victim and sends a malicious request in the name of the victim. , Things that can be done include: sending emails, messages, stealing accounts, even purchasing goods, transferring virtual currency, etc. The problems caused include: leakage of personal privacy and property safety. The consequences of an attack depend on the vulnerability exploited and the privileges of the victim.

In the prior art, since the Hyper Text Transfer Protocol (Hyper Text Transfer Protocol, HTTP) itself is a stateless protocol, that is, two consecutive requests cannot be associated, so the status is recorded through authentication information such as Cookie, Session, and HTTP. Associate consecutive requests from the same user. For example, when the user successfully authenticates, the browser will get a cookie that identifies his identity. As long as the browser is not closed or logged out, whenever a request is sent to the site, the browser will "automatically" include the cookie issued together without user intervention, regardless of whether the request originates from an application-provided link, a Uniform Resource Locator (URL) received from elsewhere, or another source. The site server uses cookies to identify users, that is, if the site server receives a request with the victim's cookie, it will treat the request as a log-in victim, and the site server will think it is Confirmed valid request, so this "credible action" will be performed, thus providing an opportunity for attack. Although this authentication mechanism of the Web site can assure the target site that a request comes from a certain user's browser, it cannot guarantee that the request is indeed sent by that user, or approved by that user. The root cause of cross-site request forgery attacks is that the Web site authenticates the Web browser rather than the user itself.

Figure 1 is a flowchart related to CSRF attacks. Step 1 in the figure is for the user to request the protection page of the protected site; then step 2 is for the site server to prompt the user to enter authentication information; step 3 is for the user to submit his user name and password information; step 4 is for the site server to verify user information and establish a legal session , and generate cookie information identifying the user to the user; step 5-8 is that the user normally sends a request to the site server, and the site server sends a response for its business processing; steps 9-11 are the attack process of the attacker, and step 9 is The victim and the user visit the malicious site, step 10 is that the malicious site returns the content requested by the user, and the returned content contains a malicious request to the protected site, and step 11 is that the user accidentally clicks a malicious link to initiate a request to the protected site or the The malicious request automatically initiates a request to the protected site, and the browser will automatically carry the cookie of the user under the site and then send this request. Since the request contains cookie information, the site server will think that it is a legitimate request sent by the logged-in user, so as to conduct business Processing, performing malicious actions of the attacker.

Currently, there are two main methods for cross-site request forgery:

The first is to use POST requests for cross-site request forgery attacks. For important write operations, the website only accepts POST requests to prevent cross-site request forgery attacks. However, the disadvantage of this method is that any GET request can construct a form and send it through a POST request, so this method can only increase the difficulty for attackers to implement attacks, and cannot prevent cross-site request forgery.

The second is to prevent cross-site request forgery attacks by verifying the token. You can add a randomly generated token as a parameter in the HTTP request, and establish an interceptor on the server side to verify the token. If there is no If the token or token content is incorrect, it is considered that it may be a CSRF attack and the request is rejected. This "authentication token" should not be easily guessed by a non-logged-in user. However, developers often forget to implement this precaution. Another disadvantage of this method is that it is difficult to guarantee the security of the token itself, and it is possible to leak the token to other sites through the URL or HTTP Refererheader. Disclosed in the journal titled: In IEEE International Conference on Security and Privacy in Communication Networks (SecureComm), 2006., document titled: Preventing cross site request forgery attacks, author names: Nenad Jovanovic, Engin Kirda, and Christopher Kruegel the method.

The third is to verify the HTTP Referer header, (HTTP Referer is a part of the header, when the browser sends a request to the web server, it will usually bring the Referer and tell the server which page I am linking from, so the server can get Some information is used for processing.) By verifying the HTTP Referer header, only requests from trusted sources are accepted. However, since the Referrer content involves privacy content such as user browsing records, most HTTP requests prohibit the use of the Referer header file. In the journal name: Proc.15th ACM Conf. Computer and Communications Security, ACM Press, 2008, pp.75–87., the document name: RobustDefenses for Cross-Site Request Forgery, the author name: A.Barth, C.Jackson , and J.C. Mitchell discloses this method in the literature.

It can be seen that for existing servers, some solutions in the prior art cannot prevent cross-site request forgery attacks well. Therefore, a method is needed to effectively prevent cross-site request forgery attacks.

Contents of the invention

The technical problem to be solved by the present invention is to provide an encryption-based cross-site request attack prevention method and its device, so as to overcome the problem that the cross-site request attack cannot be well prevented in the prior art.

In order to achieve the above purpose, the present invention provides an encryption-based cross-site request attack prevention method, which is applied to a system including a client and a server, and is characterized in that the method includes:

Authentication step: for authenticating the client through the server;

Client attack prevention step: the client who is authenticated as a legitimate user by the identity verification step receives the random number token sent by the server, and uses the random number token to encrypt subsequent requests to become an encrypted request;

A server-side attack prevention step: when the server receives the subsequent encrypted request from the legitimate user's client, the random number token is used for decryption verification, so as to realize cross-site request attack prevention.

The above encryption-based cross-site request attack prevention method is characterized in that the server-side defense steps include:

Page judging step: judging that the page logged in by the client is a protected page or a public access page;

Random number token generation step: generate the random number token for the client of the legal user through verification, and send the random number token to the client of the legal user, the random number token and the legal The user's session id is associated.

The above encryption-based cross-site request attack prevention method is characterized in that the client defense steps include:

Step of extracting token: the client of the legitimate user receives the random number token sent from the server, and extracts the random number token;

Judging the request step: judging whether the request is sent by the client application according to whether the domain name of the source website server is the same as the domain name of the destination website server, if it is the request of the client application, then encrypt it by the random number token, If it is not the client application request, it will be sent directly;

Encrypting the request step: encrypting the request content sent by the client of the legal user to the server through the random number token;

Sending the request step: sending the encrypted request to the server.

The above encryption-based cross-site request attack prevention method is characterized in that the server-side defense step also includes:

Decryption step: decrypting the encrypted request sent by the client using the token as a key to verify the legitimacy of the encrypted request;

Business processing step: perform corresponding business processing according to the encrypted request after decryption.

The above encryption-based cross-site request attack prevention method is characterized in that the random number token generation step also includes:

The user does not log in step: the session id of querying the user does not exist, and judging that the user is not logged in, then re-login authentication, generate the random number token and session id for the client of the legal user passed through the authentication;

The user has logged in step: inquire about the existence of the session id of the user, if it is judged that the user has logged in, then it is the client of the legal user.

The above encryption-based cross-site request attack prevention method is characterized in that the decryption step also includes:

Find token step: through the session id with described legal user, search described random number token associated with described session id;

Original request decryption step: using the random number token obtained in the token search step to decrypt the request sent by the client, and obtain the original request of the client.

The above encryption-based cross-site request attack prevention method is characterized in that the business processing step also includes:

Successful decryption step: if the original request decryption step is used to decrypt the request successfully, then perform business processing according to the request;

Decryption failure step: if the original request decryption step fails to decrypt the request, no business processing is performed, and a warning message is issued to the legitimate user.

The present invention also provides an encryption-based cross-site request attack prevention device, adopting the encryption-based cross-site request attack prevention method, the method is applied to a system including a client and a server, and the device is characterized in that include:

Identity verification module: used to authenticate the client through the server;

Client attack defense module: the client that is authenticated as a legitimate user by the identity verification step receives the random number token sent by the server, and uses the random number token to encrypt subsequent requests to become an encrypted request;

Server-side attack defense module: when the server side receives the subsequent encrypted request from the legal user's client, it uses the random number token to perform decryption verification, so as to realize cross-site request attack defense.

The above encryption-based cross-site request attack prevention device is characterized in that the server-side defense module includes:

Page judging module: judging that the page logged in by the client is a protected page or a public access page;

Random number token generation module: generate the random number token for the client of the legal user who has passed the verification, and send the random number token to the client of the legal user, the random number token is consistent with the legal The user's session id is associated.

The above encryption-based cross-site request attack prevention device is characterized in that the client defense module includes:

extract token module: the client of the legal user receives the random number token sent from the server, and extracts the random number token;

Judgment request module: according to whether the domain name of the source website server is the same as the domain name of the destination website server, it is judged whether the request is sent by the client application, if it is the client application request, it is encrypted by the random number token, If it is not the client application request, it will be sent directly;

An encryption request module: encrypting the content of the request sent by the client of the legal user to the server through the random number token;

Sending request module: sending the encrypted request to the server.

The above encryption-based cross-site request attack defense device is characterized in that the server-side defense module also includes:

Decryption module: decrypt the encrypted request sent by the client using the token as a key to verify the legitimacy of the encrypted request;

Business processing module: perform corresponding business processing according to the encrypted request after decryption.

The above-mentioned encryption-based cross-site request attack prevention device is characterized in that the random number token generation module also includes:

The user does not log in module: the session id of querying the user does not exist, and judging that the user is not logged in, then re-login authentication, generate the random number token and session id for the client of the legal user who passed the authentication;

The user has logged in module: query the existence of the user's session id, and judge that the user has logged in, then it is the client of the legal user.

The above encryption-based cross-site request attack prevention device is characterized in that the decryption module also includes:

Find token module: through the session id with described legitimate user, search described random number token associated with described session id;

Original request decryption module: use the random number token obtained in the token search step to decrypt the request sent by the client, and obtain the original request of the client.

The above encryption-based cross-site request attack prevention device is characterized in that the business processing module also includes:

Successful decryption module: if the original request decryption step is used to decrypt the request successfully, then perform business processing according to the request;

Decryption failure module: if the original request decryption step fails to decrypt the request, no business processing is performed, and a warning message is issued to the legal user.

Compared with the existing cross-site request attack prevention technology, the present invention has the beneficial effects of:

1. There is no need to modify the existing site server code: cross-site request forgery attacks can be prevented through simple configuration. Some existing defense technologies need to modify the site server code to achieve this. For many mature applications , if you want to use this prevention technology, it means that you must redevelop or modify the application, which will not only consume a lot of resources, but also cause a lot of performance degradation, so the development of this prevention method that requires modifying the site server is very slow;

2. Strong applicability: there are no special requirements for applications that need to be protected, and no specific development technology is required for applications. Applications developed by development technologies such as JAVA, PHP, and ASP can use the method proposed by the present invention;

3. Easy to use: no user interaction is required, no user-defined whitelist is required, and users who use the application do not need to have relevant security knowledge, which reduces the difficulty for users to use;

4. By encrypting the URL request, the attacker cannot know the specific format of the request (call page, parameters, etc.), which increases the difficulty for the attacker to understand the application to be attacked, that is, increases the difficulty for the attacker to realize the attack.

Description of drawings

Figure 1 is a flowchart related to CSRF attacks;

Fig. 2 is a schematic flow chart of the method steps of the present invention;

Fig. 3 is a schematic flow chart of the detailed steps of the method of the present invention;

Fig. 4 is the server-side schematic diagram of defense CSRF attack that the present invention provides;

FIG. 5 is a schematic diagram of the client flow of the cross-site attack prevention method of the present invention;

FIG. 6 is a schematic structural diagram of a cross-site request attack prevention device of the present invention;

FIG. 7 is a schematic diagram of the detailed structure of the cross-site request attack prevention device of the present invention.

Among them, reference signs:

100 Authentication module 200 Client attack defense module

300 server-side attack defense module

201 Extract token module 202 Judgment request module

203 Encryption request module 204 Send request module

301 Page judgment module 302 Random number token generation module

303 Decryption module 304 Business processing module

S1～S3, S21～S24, S31～S34, S321～S322, S331～S332, S341～S342: implementation steps of each embodiment of the present invention

detailed description

The specific implementation manner of the present invention is given below, and the present invention will be described in detail in conjunction with the drawings and specific implementation examples.

The invention proposes a method for encrypting a URL by using a random number (token) as a key to prevent cross-site request forgery attacks. In order to achieve the above object, the present invention utilizes the random number generated by the site server which is difficult for the attacker to guess, and uses the random number to encrypt the URL. Since the attacker cannot intercept the random number by means of sniffing and capturing packets, he cannot forge the correct request. Even if the browser automatically attaches the logged-in user's cookie to the forged request, the site server will not process the request because the request is not approved by the site server, thereby preventing cross-site request forgery attacks.

The present invention mainly involves two types of entities: client (the user accesses the application site through a browser) and server (the server deployed by the application site).

An encryption-based cross-site request attack prevention method provided by the present invention is applied to a system including a client and a server. FIG. 2 is a schematic flow chart of the steps of the method of the present invention. As shown in FIG. 2, the method includes:

Authentication step S1: for authenticating the client through the server;

Client-side attack prevention step S2: the client that is authenticated as a legitimate user through the identity verification step receives the random number token sent by the server, and uses the random number token to encrypt subsequent requests to become encrypted requests;

Server-side attack prevention step S3: When the server side receives the subsequent encrypted request from the legitimate user's client, it uses a random number token for decryption verification, so as to realize cross-site request attack prevention.

Wherein, the client attack defense step S2 includes:

Extract token step S21: the client of the legitimate user receives the random number token sent from the server, and extracts the random number token;

Judgment request step S22: According to whether the domain name of the source website server is the same as that of the destination website server, it is judged whether the request is sent by the client application. If the request is from the client application, it will be encrypted with a random number token. If it is not from the client end application request, send it directly;

Encryption request step S23: Encrypt the request content sent by the legal user's client to the server through a random number token;

Sending the request step S24: sending the encrypted request to the server.

Wherein, the server-side attack defense step S3 includes:

Page judging step S31: judging that the page logged in by the client is a protected page or a public access page;

Random number token generating step S32: generate a random number token for the client of the legal user through verification, and send the random number token to the client of the legal user, and the random number token is associated with the session id of the legal user;

Decryption step S33: decrypt the encrypted request sent by the client using token as a key to verify the legitimacy of the encrypted request;

Business processing step S34: Perform corresponding business processing according to the decrypted encrypted request.

Wherein, Fig. 3 is a schematic flow chart of the detailed steps of the method of the present invention, as shown in Fig. 3, the random number token generation step S32 also includes:

The user does not log in step S321: the session id of the query user does not exist, and if it is judged that the user is not logged in, the login authentication is performed again, and the random number token and session id are generated for the client of the legal user who has passed the authentication;

The user has logged in step S322: query the existence of the user's session id, if it is judged that the user has logged in, then it is a client of a legitimate user.

Wherein, the decryption step S33 also includes:

Search token step S331: search for a random number token associated with the session id through the session id of the legal user;

Original request decryption step S332: use the random number token obtained in the token search step to decrypt the request sent by the client, and obtain the original request of the client.

Wherein, the business processing step S34 also includes:

Successful decryption step S341: if the original request decryption step is used to decrypt the request successfully, perform business processing according to the request;

Decryption failure step S342: If the original request decryption step fails to decrypt the request, no business processing is performed, and a warning message is sent to the legal user.

In order to better introduce the principle of the technical solution of the present invention, a specific embodiment is firstly given for the cross-site request forgery attack.

Assuming that user A has logged into his bank account, the site server returns the corresponding session id authentication information for A, and A has a deposit in the bank. At this time, he sends an HTTP request to the bank's website http://bank.example/ withdraw?account=A&amount=10000&for=B allows A to transfer the deposit of 10000 to B's account. After the request is sent to the bank website, the site server will first verify whether the request comes from a legitimate session, and whether the user of this session is Already logged in, if the request is accompanied by A's session id authentication information, the site server will think that this request operation is sent by the logged-in user A.

If there is an attacker B who also has an account in the bank, and he knows that the transfer operation can be performed through the above URL through his understanding of the bank website. B can send a request to the bank by itself: http://bank.example/withdraw?account=A&amount=10000&for=B. However, since this request comes from B itself instead of A, it does not contain the relevant authentication information of A, and cannot pass the security authentication, so the request will not work.

At this time, B thought of using the CSRF attack method. He put the following code in a website he could control: src="http://bank.example/withdraw?account=A&amount=10000&for=B", and passed the advertisement , winning information, etc. to induce A to visit his website. If A has logged into the bank website at this time and opens a new tab to visit the malicious website, the above URL will send an HTTP request to the bank from A’s browser in the form of GET. Since A has logged into the bank website at this time, the browser will A’s session id will be sent out together. If the session between A’s browser and the bank has not expired, since the site server identifies the user through the session id, the bank’s website will think that this is a request sent by A, and a tragedy will happen. , the bank website will treat the above request as a legitimate request, and the money will be transferred from A's account to B's account without A's knowledge at the time. When A finds that the account has less money, he goes to the bank to check the logs, and he can only find that there is indeed a legal request from himself to transfer the funds, without any trace of being attacked.

The above briefly introduces the principle of cross-site request forgery attack. In the present invention, the site server judges whether the content requested to be accessed is protected content, and if it prompts the user to input verification information such as user name and password, and generates a corresponding session id and random number token , sent to the client. In the user's subsequent request, the client will encrypt the content of the URL request with a random number token, and then send the request. The site server will find the corresponding token according to the corresponding session id, and decrypt the URL request. For a successfully decrypted request, it means that the request is encrypted with a random number token, and this random number is only known by the client user, which is a legal request, so The site server will perform relevant business processing according to the request content. Since the attacker cannot obtain the random number and cannot correctly encrypt the forged request, even if the browser automatically attaches the session id of the logged-in user to the forged request, the decryption will fail, and the site server will not perform business processing, and A warning is issued to the user, which protects against cross-site request forgery attacks.

The steps of the embodiments of the present invention will be described in detail below in conjunction with the above embodiments and the accompanying drawings.

Fig. 4 is the server-side schematic diagram of defense CSRF attack that the present invention provides, and as shown in Fig. 4, the main steps of server-side include:

10. Determine whether it is a protected page;

20. Determine whether the user is logged in;

30. Decrypt the encrypted request;

40. Business processing.

A specific implementation is as follows:

10. Determine whether it is a protected page. General applications are divided into protected pages and public pages.

1) Public pages can be accessed without user login, such as login.html, index.html, etc., because there are no important operations and will not cause harm, so the site server can directly perform corresponding business processing according to the request.

2) The protected page requires the user to log in to access, that is, the user needs to authenticate, such as changing the user password, personal information, transfer, etc. Therefore, the site server needs to determine whether the user is logged in and whether the current session is legal.

20. Determine whether the user is logged in. According to whether the session id is valid or not, it is judged whether the user is logged in or not, and whether there is a legal session.

1) If there is no session id, it means that the user has not logged in, or the session has expired, and login authentication is required again. Specifically, it mainly includes the following steps:

11) Jump to the login interface, prompting the user to enter authentication information (usually user name and password).

12) The site server verifies whether the user name and password entered by the user are correct. If not, it will redirect to the login page and require the user to re-enter the authentication information.

13) After passing the verification, the site server will create a valid session, generate a session id and a random number token associated with the user session, return the page requested by the user, and return the session id and random number token to the client.

2) If there is a session id, it means that the user has successfully logged in, and the client has the random number token sent by the site server. At this time, if the subsequent request is legal and sent by the application, it should be encrypted with the random number of the token of.

30. Decrypt the encrypted request, and the logged-in user will have the random number token sent back by the site server, so subsequent requests sent by this application should be encrypted using the token as the key, because the attacker does not have the token and cannot A properly decrypted request could have been forged by an attacker.

1) In the session id and token association table stored on the site server, find the corresponding token according to the session id in the request.

2) Use the token to decrypt the encrypted part of the request (call page, parameters, etc.), and you can get the original request sent by the client.

40. Business processing.

1) Successful decryption with the token means that the request is encrypted with the token sent by the site server, which is a legal request sent by the application, so the site server will perform corresponding business processing according to the request.

2) Decryption fails, indicating that the encryption key used in the request is wrong, it may be the token guessed by the attacker, and the forged request is encrypted with the guessed token; or the request is not encrypted and decryption fails, so it is not valid Perform business processing and issue corresponding warning messages to users.

Fig. 5 is a schematic diagram of the client process of the cross-site attack prevention method of the present invention. As shown in Fig. 5, the main steps of the client include:

50. Extract token;

60. Determine whether the request is sent by this application;

70. Encryption request;

80. Send request.

A specific implementation is as follows:

50. Extract the token. The client extracts the token sent by the server to the client from the response of the web server. The token can be brought back in the response page of the site server, or it can be sent separately.

60. Determine whether the request is sent by the application. Determine whether the source website server that sends the request matches the complete domain name of the destination website. If it matches, it can be considered that the request was sent by this application, otherwise it is considered that the request was not sent by this application.

1) If the request is sent by this application, use token to encrypt it.

2) If the request is not sent by this application, it will not be processed and sent directly.

70. Encrypt the request. Part of the content in the URL request (call page, parameters, etc.) is encrypted, and the server address of the application in the URL request is still sent in plain text to ensure that the request can be sent to the server correctly. The encryption operation can be completed through a plug-in released by the application.

For example, in the above example, http://bank.example/withdraw?account=A&amount=10000&for=B, use the token sent by the server to encrypt part of "withdraw?account=A&amount=10000&for=B". It should be understood that the present invention may be encrypted in other ways, and the specific embodiments described here are only used to explain the present invention, and are not intended to limit the present invention.

80. Send request. Send the encrypted request to the server.

The present invention also provides an encryption-based cross-site request attack prevention device, using the encryption-based cross-site request attack prevention method, which is applied to a system including a client and a server. Figure 6 shows the cross-site request attack of the present invention The structural schematic diagram of the preventive device, as shown in Figure 6, the device includes:

Identity verification module 100: used for authenticating the client through the server;

Client-side attack prevention module 200: the client that is authenticated as a legitimate user through the identity verification step receives the random number token sent by the server, and uses the random number token to encrypt subsequent requests to become an encrypted request;

Server-side attack defense module 300: when the server side receives a subsequent encrypted request from a legal user's client, it uses a random number token for decryption verification, so as to realize cross-site request attack defense.

Wherein, the client attack defense module 200 includes:

Extracting token module 201: the client of the legal user receives the random number token sent from the server, and extracts the random number token;

Judgment request module 202: According to whether the domain name of the source website server is the same as the domain name of the destination website server, it is judged whether the request is sent by the client application, if it is the request of the client application, it is encrypted by a random number token, if it is not the client end application request, send it directly;

Encryption request module 203: Encrypt the request content sent by the client of the legal user to the server through a random number token;

Sending request module 204: sending the encrypted request to the server.

Wherein, the server-side attack defense module 300 includes:

Page judging module 301: judging that the page logged in by the client is a protected page or a public access page;

Random number token generating module 302: generate a random number token for the client of the legal user through verification, and send the random number token to the client of the legal user, and the random number token is associated with the session id of the legal user;

Decryption module 303: decrypt the encrypted request sent by the client using token as a key to verify the legitimacy of the encrypted request;

Business processing module 304: perform corresponding business processing according to the decrypted encrypted request.

Wherein, FIG. 7 is a schematic diagram of the detailed structure of the cross-site request attack prevention device of the present invention. As shown in FIG. 7, the random number token generation module 302 also includes:

The user does not log in module 3021: the session id of querying the user does not exist, and judging that the user is not logged in, then re-login authentication, generate the random number token and session id for the client of the legal user who has passed the authentication;

User has logged in module 3022: Query the existence of the user's session id, if it is judged that the user has logged in, then it is a client of a legitimate user.

Wherein, the decryption module 303 also includes:

Find token module 3031: through the session id with legal user, search the random number token associated with session id;

The original request decryption module 3032: use the random number token obtained in the token search step to decrypt the request sent by the client, and obtain the original request of the client.

Wherein, the business processing module 304 also includes:

Successful decryption module 3041: if the original request decryption step is used to decrypt the request successfully, then perform business processing according to the request;

Decryption failure module 3042: If the original request decryption step fails to decrypt the request, no business processing will be performed, and a warning message will be issued to the legal user.

To sum up, the encryption-based cross-site request attack prevention method and device provided by the present invention can perform good cross-site request attack defense without modifying the existing site server.

Of course, the present invention can also have other various embodiments, and those skilled in the art can make various corresponding changes and deformations according to the present invention without departing from the spirit and essence of the present invention. All changes and deformations should belong to the protection scope of the appended claims of the present invention.

Claims (14)

1. An encryption-based cross-site request attack prevention method, applied to a system comprising a client and a server, is characterized in that the method comprises: Authentication step: for authenticating the client through the server; Client attack prevention step: the client that is authenticated as a legal user by the identity verification step receives the random number token sent by the server, and adopts the random number token to encrypt subsequent URL requests to become an encrypted request; A server-side attack prevention step: when the server receives the subsequent encrypted request from the legitimate user's client, the random number token is used for decryption verification, so as to realize cross-site request attack prevention. 2. The encryption-based cross-site request attack prevention method according to claim 1, wherein the server-side attack prevention step comprises: Page judging step: judging that the page logged in by the client is a protected page or a public access page; Random number token generation step: generate the random number token for the client of the legal user through verification, and send the random number token to the client of the legal user, the random number token and the legal The user's session id is associated. 3. The encryption-based cross-site request attack prevention method according to claim 1, wherein the client attack prevention step comprises: Step of extracting token: the client of the legitimate user receives the random number token sent from the server, and extracts the random number token; Judging the request step: judging whether the request is sent by the client application according to whether the domain name of the source website server is the same as the domain name of the destination website server, if it is the request of the client application, then encrypt it by the random number token, If it is not the client application request, it will be sent directly; Encrypting the request step: encrypting the request content sent by the client of the legal user to the server through the random number token; Sending the request step: sending the encrypted request to the server. 4. The encryption-based cross-site request attack prevention method according to claim 1, wherein the server-side attack prevention step further comprises: Decryption step: decrypting the encrypted request sent by the client using the token as a key to verify the legitimacy of the encrypted request; Business processing step: perform corresponding business processing according to the encrypted request after decryption. 5. according to the described encryption-based cross-site request attack prevention method according to claim 2, it is characterized in that, described random number token generation step also comprises: The user does not log in step: the session id of querying the user does not exist, and judging that the user is not logged in, then re-login authentication, generate the random number token and session id for the client of the legal user passed through the authentication; The user has logged in step: inquire about the existence of the session id of the user, if it is judged that the user has logged in, then it is the client of the legal user. 6. The encryption-based cross-site request attack prevention method according to claim 4, wherein the decryption step further comprises: Find token step: through the session id with described legal user, search described random number token associated with described session id; Original request decryption step: using the random number token obtained in the token search step to decrypt the request sent by the client, and obtain the original request of the client. 7. The encryption-based cross-site request attack prevention method according to claim 6, wherein the business processing step further comprises: Successful decryption step: if the original request decryption step is used to decrypt the request successfully, then perform business processing according to the request; Decryption failure step: if the original request decryption step fails to decrypt the request, no business processing is performed, and a warning message is issued to the legal user. 8. An encryption-based cross-site request attack prevention device, adopting the encryption-based cross-site request attack prevention method according to any one of claims 1-7, said method being applied to a system comprising a client and a server, It is characterized in that the device includes: Identity verification module: used to authenticate the client through the server; Client attack defense module: the client that is authenticated as a legitimate user by the identity verification step receives the random number token sent by the server, and uses the random number token to encrypt subsequent URL requests to become an encrypted request; Server-side attack defense module: when the server side receives the subsequent encrypted request from the legal user's client, it uses the random number token to perform decryption verification, so as to realize cross-site request attack defense. 9. The encryption-based cross-site request attack prevention device according to claim 8, wherein the server-side attack prevention module includes: Page judging module: judging that the page logged in by the client is a protected page or a public access page; Random number token generation module: generate the random number token for the client of the legal user who has passed the verification, and send the random number token to the client of the legal user, the random number token is consistent with the legal The user's session id is associated. 10. The encryption-based cross-site request attack defense device according to claim 8, wherein the client attack defense module includes: extract token module: the client of the legal user receives the random number token sent from the server, and extracts the random number token; Judgment request module: according to whether the domain name of the source website server is the same as the domain name of the destination website server, it is judged whether the request is sent by the client application, if it is the client application request, it is encrypted by the random number token, If it is not the client application request, it will be sent directly; An encryption request module: encrypting the content of the request sent by the client of the legal user to the server through the random number token; Sending request module: sending the encrypted request to the server. 11. The encryption-based cross-site request attack defense device according to claim 9, wherein the server-side attack defense module further comprises: Decryption module: decrypt the encrypted request sent by the client using the token as a key to verify the legitimacy of the encrypted request; Business processing module: perform corresponding business processing according to the encrypted request after decryption. 12. The encryption-based cross-site request attack prevention device according to claim 11, wherein the random number token generation module further comprises: The user does not log in module: the session id of querying the user does not exist, and judging that the user is not logged in, then re-login authentication, generate the random number token and session id for the client of the legal user who passed the authentication; The user has logged in module: query the existence of the user's session id, and judge that the user has logged in, then it is the client of the legal user. 13. The encryption-based cross-site request attack prevention device according to claim 12, wherein the decryption module further comprises: Find token module: through the session id with described legitimate user, search described random number token associated with described session id; Original request decryption module: use the random number token obtained in the token search step to decrypt the request sent by the client, and obtain the original request of the client. 14. The encryption-based cross-site request attack prevention device according to claim 12, wherein the business processing module further comprises: Successful decryption module: if the original request decryption step is used to decrypt the request successfully, then perform business processing according to the request; Decryption failure module: if the original request decryption step fails to decrypt the request, no business processing is performed, and a warning message is issued to the legal user.