Website request tamper-proofing method, server side, webpage side and storage medium

Abstract

The embodiment of the invention provides a website request tamper-proofing method, a server side, a webpage side and a storage medium. The method is applied to a server side and comprises the following steps: generating an access token of a webpage side under the condition that login of the webpage side succeeds, performing encryption calculation on a first request parameter carried by a login request of the webpage side to generate a first signature, and returning the first signature to the webpage side; receiving a resource request which is initiated by the webpage end and carries a second request parameter; determining whether a webpage side ciphertext exists in the resource request or not; under the condition of determining that the webpage side ciphertext exists in the resource request, obtaining effective parameters in the second request parameters; generating a second object character string according to the effective parameter; splicing the first signature and the second object character string to obtain a second character string; performing encryption calculation on the second character string by taking the access token as a secret key to generate a server ciphertext; and when the webpage side ciphertext is consistent with the server side ciphertext, determining that the second request parameter carried by the resource request is not tampered in the issuing process.

Description

Technical Field

[0001] The present application relates to the technical field of secure data transmission, and in particular to a method, a server, a web page, a storage medium and a computer program product for preventing website request tampering. Background Art

[0002] Web-side network security is one of the most important application areas and directions of network security. The interaction security between the Web and the server is particularly important. If the interaction request parameters are tampered with, they may be used by criminals to impersonate super administrators and obtain system permissions that they do not have. Therefore, the tamper-proof problem of the interaction request parameters between the Web and the server is of utmost importance.

[0003] In the prior art, the security mechanisms commonly used in the Web field are generally token verification and parameter encryption. However, the security and timeliness issues of tokens are more prominent, and there is still a risk that criminals can use intercepted tokens to tamper with parameters and resend them. Therefore, a signature parameter rtoken (refreshtoken) similar to the token that can be updated in real time is also needed, and then the encryption method of the secret key agreed upon by the Web and server is combined for encryption verification to prevent request parameters from being tampered with.

[0004] In view of the above technical problems, the prior art provides a method for preventing http request data from being tampered with and a method for preventing URL tampering and verification based on the MD5 algorithm. The time window in the method for preventing http request data from being tampered with is a vague concept. If the time window is set too short, the effect is not obvious, and the replay attack after exceeding the time interval cannot be identified. If the time window is set too long, the data that needs to be saved in the database will be very large, and the system has many interfaces and many users, which may cause the amount of data to be too large, greatly reduce the comparison query performance, and increase the burden on the server. The URL anti-tampering signature and verification method based on the MD5 algorithm only performs encryption comparison on the parameters in the URL, and does not perform encryption comparison on the parameters in the request body. Therefore, if the parameters of the body are tampered with, the Sign and Sign2 obtained by the final encryption calculation will not be affected, and the two are still the same. This technology can only be used for requests such as GET that pass parameters through the URL, and can only prevent URL parameters from being tampered with. It cannot be used for requests such as POST that pass parameters through the body, and cannot prevent body parameters from being tampered with. Moreover, when replaying the request that has been sent, since the interface and parameters have not changed, the Sign in the parameters has not changed, and the Sign2 calculated after the backend receives the request has not changed. Therefore, this solution cannot solve the problem of replay attacks. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a method, server, web page, storage medium and computer program product for preventing website request tampering, so as to solve the technical defect in the prior art that the server cannot effectively identify whether the received request has been tampered with, resulting in the server being unable to identify replay attacks.

[0006] In order to achieve the above-mentioned purpose, the first aspect of the present application provides a method for preventing website request tampering, which is applied to a server, and the method includes:

[0007] If the web page login is successful, an access token for the web page is generated, and the first request parameter carried in the web page login request is encrypted and calculated to generate a first signature;

[0008] Return the access token and the first signature to the web page;

[0009] Receive a resource request initiated by a web page, where the resource request carries a second request parameter;

[0010] Determine whether there is a web page ciphertext in the resource request, wherein the web page ciphertext is generated by encrypting a first string using an access token as a secret key, and the first string is obtained by concatenating a first signature and a first object string;

[0011] When it is determined that the resource request contains web page ciphertext, obtain valid parameters in the second request parameter;

[0012] Generate a second object string according to valid parameters;

[0013] Concatenate the first signature and the second object string to obtain a second string;

[0014] The second character string is encrypted using the access token as a secret key to generate a server-side ciphertext;

[0015] When the ciphertext on the web page is consistent with the ciphertext on the server, it is determined that the second request parameter carried in the resource request has not been tampered with during the sending process, and the second request parameter is received.

[0016] In an embodiment of the present application, the method further includes: when the web page ciphertext is inconsistent with the server ciphertext, determining that the second request parameter carried by the resource request has been tampered with during the sending process, and refusing to receive the second request parameter.

[0017] In an embodiment of the present application, generating a second object string based on valid parameters includes: converting the data included in the valid parameters into first key-value pairs, sorting the first key-value pairs based on keywords to obtain first intermediate parameters, wherein each first key-value pair consists of a keyword and a value; and converting the first intermediate parameters into a second object string.

[0018] In an embodiment of the present application, the method also includes: when it is determined that there is no web page ciphertext in the resource request, determining that the resource request is an abnormal request; generating error information for the abnormal request and returning it to the web page.

[0019] In an embodiment of the present application, the method also includes: after determining that the web page ciphertext is consistent with the server ciphertext, replacing the value of the first signature with the server ciphertext to obtain a second signature; and returning the second signature to the web page.

[0020] A second aspect of the present application provides a server, including:

[0021] a memory configured to store instructions;

[0022] The processor is configured to call the instructions from the memory and implement the above-mentioned method for preventing website request from being tampered with when executing the instructions.

[0023] A third aspect of the present application provides a method for preventing website request tampering, which is applied to a web page, and the method includes:

[0024] Initiate a login request to the server, the login request includes a first request parameter, the server generates an access token when determining that the login is successful, and encrypts the first request parameter carried by the login request of the web page to generate a first signature;

[0025] Receive the access token and first signature returned by the server;

[0026] Generate a first object string according to valid parameters;

[0027] Concatenate the first signature and the first object string to obtain a first string;

[0028] Using the access token as a secret key, the first character string is encrypted to generate a web page ciphertext, and the web page ciphertext is added to the second request parameter;

[0029] A resource request is sent to the server, wherein the resource request includes a second request parameter, and the second request parameter includes a valid parameter, a request line, and a request header.

[0030] In an embodiment of the present application, generating a first object string based on valid parameters includes: determining a request method for a resource request to determine a position of a valid parameter in a second request parameter based on the request method; obtaining the valid parameter based on the position of the valid parameter; converting the data included in the valid parameter into a second key-value pair, sorting the second key-value pair based on a keyword to obtain a second intermediate parameter, wherein each key-value pair consists of a keyword and a value; and converting the second intermediate parameter into the first object string.

[0031] In an embodiment of the present application, determining the request mode of the resource request to determine the position of the valid parameter in the second request parameter based on the request mode includes: determining whether the request mode of the resource request is a GET request; when the request mode is a GET request, determining that the valid parameter is located in the query of the URL; when the request mode is not a GET request, determining that the valid parameter is located in the body request body.

[0032] In an embodiment of the present application, the method also includes: after receiving the access token and the first signature returned by the server, storing the first signature in a cookie; setting the cookie as a secure cookie so that the web page cannot tamper with the first signature.

[0033] A fourth aspect of the present application provides a web page, including:

[0034] a memory configured to store instructions;

[0035] The processor is configured to call the instructions from the memory and implement the above-mentioned method for preventing website request from being tampered with when executing the instructions.

[0036] A fifth aspect of the present application provides a machine-readable storage medium having instructions stored thereon, which, when executed by a processor, configures the processor to execute the above-mentioned method for preventing website request tampering.

[0037] In a sixth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the method for preventing website request tampering of any one of the above embodiments.

[0038] The above technical solution generates an access token for the web page when the web page login is successful, and encrypts and calculates the first request parameter carried by the web page login request to generate a first signature, and returns it to the web page; receives a resource request initiated by the web page and carrying a second request parameter; determines whether there is a web page ciphertext in the resource request; when it is determined that there is a web page ciphertext in the resource request, obtains the valid parameters in the second request parameter; generates a second object string according to the valid parameters; concatenates the first signature and the second object string to obtain a second string; encrypts and calculates the second string using the access token as a secret key to generate a server-side ciphertext; when the web page ciphertext is consistent with the server-side ciphertext, determines that the second request parameter carried by the resource request has not been tampered with during the issuance process, thereby achieving effective identification of whether the received request has been tampered with, and effectively preventing replay attacks.

[0039] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The accompanying drawings are used to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the following specific implementations, they are used to explain the embodiments of the present application, but do not constitute a limitation on the embodiments of the present application. In the accompanying drawings:

[0041] Figure 1 A schematic diagram of a process of a method for preventing website request tampering according to an embodiment of the present application is shown;

[0042] Figure 2 A timing diagram schematically illustrates another method for preventing website request tampering according to an embodiment of the present application;

[0043] Figure 3 A timing diagram schematically shows a method for preventing website request tampering according to an embodiment of the present application;

[0044] Figure 4 A schematic diagram schematically shows time information of a resource request according to an embodiment of the present application;

[0045] Figure 5 A schematic diagram schematically shows average time information of a resource request according to an embodiment of the present application;

[0046] Figure 6 The internal structure diagram of a computer device according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the specific implementation methods described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0048] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present application, the descriptions of "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0049] Figure 1 The following schematically shows a flow chart of a method for preventing website request tampering according to an embodiment of the present application. Figure 1 As shown, an embodiment of the present application provides a method for preventing website request tampering, which can be applied to a server, and the method may include the following steps.

[0050] Step 101, when the web page login is successful, an access token for the web page is generated, and a first request parameter carried in the web page login request is encrypted and calculated to generate a first signature.

[0051] In the embodiment of the present application, it should be noted that the web page end may refer to the Web end, and the Web end refers to an application or service accessed and used through a Web browser. In the field of computers and the Internet, "Web" refers to web pages and Web applications on the Internet. The service end may refer to the Server end, which refers to a computer or device that provides services in a computer network, usually running on a server on the network, responsible for processing requests from the client or the Web end and providing corresponding services or resources. Specifically, the Web end may initiate a login request carrying a first request parameter to the server end, and the Server end performs login authentication. When the login authentication passes, the Web end successfully logs in to the Server end. Among them, it should be noted that the login request may refer to an http request, and the http request may refer to a request message sent from a client or a Web end to a server, the purpose of which is to obtain resources on the server. The http request consists of a request line, a request header, and a request body, and each http request is independent. Therefore, the first request parameter may refer to a hypertext transfer protocol consisting of a request line, a request header, and a request body.

[0052] It should be noted that the access token can refer to a token, and a token can refer to an encrypted string used for identity authentication and authority control. It is equivalent to the visitor's "identity token". The server determines the visitor's identity and authority by verifying the validity of the token. The first signature can refer to the token generated for the first time, which can be abbreviated as rtoken, which is the abbreviation of refresh token. Rtoken is a string generated by the server and used as a token for the access end to make requests. When the access end logs in for the first time, the server will generate an rtoken and return it to the access end. The access end needs to carry this rtoken in subsequent requests without having to carry the username and password again. The role of rtoken is similar to a "secret code" used for verification before data transmission to ensure the authority and security of data. Specifically, when the Web end successfully logs in to the Server end, the Server end generates a token for the Web end, and encrypts and calculates the first request parameter carried by the Web end's login request to generate rtoken for use by the Web end in subsequent requests. Among them, the encryption calculations in this technical solution may refer to HmacSHA256 encryption calculations. HmacSHA256 is a message authentication code algorithm based on a hash function, which is mainly used to verify the integrity and authenticity of a message, rather than actually being used to encrypt or decrypt data. It uses the SHA-256 hash function in combination with a secret key to calculate the message authentication code to ensure the integrity and authenticity of the data.

[0053] Step 102: Return the access token and the first signature to the web page.

[0054] In the embodiment of the present application, after the server generates the token and rtoken of the web side, it can store the token and rtoken in the database and return them to the web side at the same time. The web side can store the received token and rtoken in a cookie for identifying identity and tracking behavior, and set it as a secure cookie so that the web side cannot tamper with the rtoken later.

[0055] Step 103: receiving a resource request initiated by the web page, where the resource request carries a second request parameter.

[0056] In the embodiment of the present application, it should be noted that a resource request may refer to a request for data access, data query, etc., but in essence a resource request may refer to an http request initiated by a Web end to a Server end. Therefore, a resource request carrying a second request parameter may refer to a hypertext transfer protocol consisting of a request line, a request header, and a request body, wherein the request body may refer to a valid parameter. Specifically, after the Web end successfully logs in to the Server end and receives the token and rtoken returned by the Server end, the Web end may initiate the next http request to the Server end again, and the http request carries the second request parameter, and the Server end receives the http request initiated by the Web end.

[0057] Step 104, determine whether there is a web page ciphertext in the resource request, wherein the web page ciphertext is generated by encrypting and calculating a first string using an access token as a secret key, and the first string is obtained by concatenating a first signature and a first object string.

[0058] In the embodiment of the present application, it should be noted that before the Web end initiates a resource request to the Server end, it needs to perform a preparatory action before initiating the request. Specifically, the Web end needs to first construct a resource request carrying a second request parameter, and generate a first object string through the second request parameter, and the first object string can be _str. Then the first signature rtoken and the generated first object string are concatenated into a first string, and finally the first string is encrypted with HmacSHA256 using token as the secret key to generate a Web-end ciphertext. Among them, the Web-end ciphertext can refer to sign0. After obtaining sign0, the Web end can further add sign0 to the second request parameter to be sent to the Server end together with the second request parameter. At this point, the preparatory action before initiating the request of the Web end is completed, and at this time, the Web end initiates an http request to the Server end. When the Server end receives the http request initiated by the web page end, it needs to further determine whether there is sign0 in the http request, so as to verify whether the second request parameter carried in the http request is tampered with during the issuance process.

[0059] Step 105: When it is determined that the web page ciphertext exists in the resource request, obtain the valid parameters in the second request parameters.

[0060] In an embodiment of the present application, when the server determines that sign0 exists in the http request, it obtains the valid parameters in the second request parameters. It should be noted that the server can record the valid parameters as data parameters, where the data parameter is a way to send data in an http request, and it usually contains the data to be sent.

[0061] In an embodiment of the present application, the method also includes: when it is determined that there is no web page ciphertext in the resource request, determining that the resource request is an abnormal request; generating error information for the abnormal request and returning it to the web page.

[0062] In this embodiment, it should be noted that if the Server determines that sign0 does not exist in the http request, the Server may consider that the http request initiated by the Web is abnormal. At this time, the Web generates an error message of the abnormal request and returns it to the Web, and refuses to receive the second request parameter.

[0063] Step 106: Generate a second object character string according to the valid parameters.

[0064] In the embodiment of the present application, it should be noted that the second object string may refer to __str. After obtaining the valid parameter data, the server may further process the data parameter to obtain the corresponding second object string __str.

[0065] In an embodiment of the present application, generating a second object string based on valid parameters includes: converting the data included in the valid parameters into first key-value pairs, sorting the first key-value pairs based on keywords to obtain first intermediate parameters, wherein each first key-value pair consists of a keyword and a value; and converting the first intermediate parameters into a second object string.

[0066] In this embodiment, it should be noted that the key-value pair may refer to Key-Value, which is a common data representation method, in which the key (Key) is a unique identifier, which can also be called a keyword, and the value (Value) is the corresponding data of the key. The first intermediate parameter may refer to _data. Specifically, the server converts the data parameter into Key-Value, and then sorts it based on the Key to obtain the first intermediate parameter _data. It should be noted that the data content of _data at this time includes {first parameter, value; second parameter, value; ...}. It should be noted that the second object string may refer to _str. After obtaining the first intermediate parameter _data, the server can further process and convert the first intermediate parameter _data into the corresponding second object string _str.

[0067] Step 107: concatenate the first signature and the second object character string to obtain a second character string.

[0068] In the embodiment of the present application, it should be noted that the second object string may refer to _str. Specifically, after obtaining the second object string _str, the server may further concatenate the first signature rtoken with the second object string _str, and record the concatenated data as the second string.

[0069] Step 108: encrypt the second character string using the access token as a secret key to generate a server-side ciphertext.

[0070] In the embodiment of the present application, it should be noted that the server-side ciphertext may refer to sign1, which may refer to an authentication identifier. After obtaining the second string, the server-side may perform HmacSHA256 encryption calculation on the second string using token as the secret key to generate the server-side ciphertext sign1, which is used to subsequently verify whether the second request parameter carried in the http request has been tampered with during the issuance process.

[0071] Step 109, when the ciphertext on the web page is consistent with the ciphertext on the server, determine that the second request parameter carried by the resource request has not been tampered with during the sending process, and receive the second request parameter.

[0072] In the embodiment of the present application, after generating the server-side ciphertext sign1, the Web-side ciphertext sign0 obtained in the http request is compared with the server-side ciphertext sign1 to determine whether the two are consistent. When the Web-side ciphertext sign0 is consistent with the server-side ciphertext sign1, the server side can assume that the second request parameter carried by the http request has not been tampered with during the issuance process, and receives the second request parameter.

[0073] In an embodiment of the present application, when the ciphertext on the web page is inconsistent with the ciphertext on the server, it is determined that the second request parameter carried by the resource request has been tampered with during the issuance process, and the second request parameter is refused to be received.

[0074] In this embodiment, when the Web-side ciphertext sign0 is inconsistent with the Server-side ciphertext sign1, the Server-side may consider that the second request parameter carried by the http request has been tampered with during the sending process, the http request is blocked, and the second request parameter is refused to be received, and an error prompt is given.

[0075] In an embodiment of the present application, the method also includes: after determining that the web page ciphertext is consistent with the server ciphertext, replacing the value of the first signature with the server ciphertext to obtain a second signature; and returning the second signature to the web page.

[0076] In this embodiment, when the Web-side ciphertext sign0 is consistent with the Server-side ciphertext sign1, the Server-side will replace the value of the first signature rtoken with the Server-side ciphertext sign1, thereby obtaining a second signature rtoken for the Web-side to initiate an http request next time, and return the second signature rtoken to the Web-side. The Web-side can store the second signature rtoken in a cookie and set it as a secure cookie to prevent the Web-side from tampering with the second signature rtoken.

[0077] The above technical solution generates an access token for the web page when the web page login is successful, and encrypts and calculates the first request parameter carried by the web page login request to generate a first signature, and returns it to the web page; receives a resource request initiated by the web page and carrying a second request parameter; determines whether there is a web page ciphertext in the resource request; when it is determined that there is a web page ciphertext in the resource request, obtains the valid parameters in the second request parameter; generates a second object string according to the valid parameters; concatenates the first signature and the second object string to obtain a second string; encrypts and calculates the second string using the access token as a secret key to generate a server-side ciphertext; when the web page ciphertext is consistent with the server-side ciphertext, determines that the second request parameter carried by the resource request has not been tampered with during the issuance process, thereby achieving effective identification of whether the received request has been tampered with, and effectively preventing replay attacks.

[0078] Figure 2 The flowchart of another method for preventing website request tampering according to an embodiment of the present application is schematically shown. Figure 2 As shown, an embodiment of the present application provides a method for preventing website request tampering, which can be applied to a web page. The method may include the following steps.

[0079] Step 201, initiate a login request to the server, the login request includes a first request parameter, and when the server determines that the login is successful, generates an access token and encrypts the first request parameter carried by the login request of the web page to generate a first signature.

[0080] In the embodiment of the present application, it should be noted that the web page end may refer to the Web end, and the Web end refers to an application or service accessed and used through a Web browser. In the field of computers and the Internet, "Web" refers to web pages and Web applications on the Internet. The service end may refer to the Server end, which refers to a computer or device that provides services in a computer network, usually running on a server on the network, responsible for processing requests from the client or the Web end and providing corresponding services or resources. Specifically, the Web end may initiate a login request carrying a first request parameter to the server end, and the Server end performs login authentication. When the login authentication passes, the Web end successfully logs in to the Server end. Among them, it should be noted that the login request may refer to an http request, and the http request may refer to a request message sent from a client or a Web end to a server, the purpose of which is to obtain resources on the server. The http request consists of a request line, a request header, and a request body, and each http request is independent. Therefore, the first request parameter may refer to a hypertext transfer protocol consisting of a request line, a request header, and a request body.

[0081] It should be noted that the access token can refer to a token, and a token can refer to an encrypted string used for identity authentication and authority control. It is equivalent to the visitor's "identity token". The server determines the visitor's identity and authority by verifying the validity of the token. The first signature can refer to the token generated for the first time, which can be abbreviated as rtoken, which is the abbreviation of refresh token. Rtoken is a string generated by the server and used as a token for the access end to make requests. When the access end logs in for the first time, the server will generate an rtoken and return it to the access end. The access end needs to carry this rtoken in subsequent requests without having to carry the username and password again. The role of rtoken is similar to a "secret code" used for verification before data transmission to ensure the authority and security of data. Specifically, when the Web end successfully logs in to the Server end, the Server end generates a token for the Web end, and encrypts and calculates the first request parameter carried by the Web end's login request to generate rtoken for use by the Web end in subsequent requests. Among them, the encryption calculations in this technical solution may refer to HmacSHA256 encryption calculations. HmacSHA256 is a message authentication code algorithm based on a hash function, which is mainly used to verify the integrity and authenticity of a message, rather than actually being used to encrypt or decrypt data. It uses the SHA-256 hash function in combination with a secret key to calculate the message authentication code to ensure the integrity and authenticity of the data.

[0082] Step 202: Receive the access token and the first signature returned by the server.

[0083] In an embodiment of the present application, after generating the token and rtoken of the Web side, the Server side can store the token and rtoken in a database and return them to the Web side at the same time, and the Web side receives the token and rtoken returned by the Server side.

[0084] In an embodiment of the present application, the method also includes: after receiving the access token and the first signature returned by the server, storing the first signature in a cookie; setting the cookie as a secure cookie so that the web page cannot tamper with the first signature.

[0085] In this embodiment, after receiving the token and rtoken returned by the server, the web side can store the received token and rtoken in a cookie used to identify the identity and track the behavior, and set it as a secure cookie so that the web side cannot tamper with the rtoken later.

[0086] Optional step 203: construct a resource request, the resource request includes a second request parameter, the second request parameter includes a valid parameter, a request line and a request header.

[0087] In the embodiments of the present application, it should be noted that a resource request may refer to a request for data access, data query, etc., but in essence a resource request may refer to an http request initiated by a Web end to a Server end. Therefore, a resource request carrying a second request parameter may refer to a hypertext transfer protocol consisting of a request line, a request header, and a request body, wherein the request body may refer to a valid parameter. It should be noted that before the Web end initiates a resource request to the Server end, it needs to perform preparatory actions before initiating the request. Specifically, the Web end needs to first construct an http request carrying a second request parameter, wherein the second request parameter should include valid parameters, a request line, and a request header.

[0088] Step 204: Generate a first object character string according to the valid parameters.

[0089] In the embodiment of the present application, it should be noted that the first object string may be _str. Specifically, after the Web end constructs the http request carrying the second request parameter, the Web end may further generate the first object string may be _str according to the valid parameters in the second request parameter.

[0090] In an embodiment of the present application, generating a first object string based on valid parameters includes: determining a request method for a resource request to determine a position of a valid parameter in a second request parameter based on the request method; obtaining the valid parameter based on the position of the valid parameter; converting the data included in the valid parameter into a second key-value pair, sorting the second key-value pair based on a keyword to obtain a second intermediate parameter, wherein each key-value pair consists of a keyword and a value; and converting the second intermediate parameter into the first object string.

[0091] In this embodiment, it should be noted that the request method of the http request may include multiple types such as GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH. Before the Web end generates the first object string according to the valid parameters in the second request parameter, it is necessary to first determine which specific request method the http request is, so that the position of the valid parameter data in the second request parameter can be determined according to the request method. After determining the position of the valid parameter data, the valid parameter data can be obtained, and the subsequent step of generating the first object string _str can be performed.

[0092] It should be noted that the key-value pair may refer to Key-Value, which is a common way of representing data, in which the key (Key) is a unique identifier, also known as a keyword, and the value (Value) is the corresponding data of the key. The second intermediate parameter may refer to _data. Specifically, the Web end converts the data parameter into Key-Value, and then sorts it based on the Key to obtain the second intermediate parameter _data. It should be noted that at this time, the data content of _data includes {first parameter, value; second parameter, value; ...}. After obtaining the second intermediate parameter _data, the Web end further processes and converts the second intermediate parameter _data into the corresponding first object string _str.

[0093] In an embodiment of the present application, determining the request mode of the resource request to determine the position of the valid parameters in the second request parameter based on the request mode includes: determining whether the request mode of the resource request is a GET request; when the request mode is a GET request, determining that the valid parameters are located in the query of the URL; when the request mode is not a GET request, determining that the valid parameters are located in the body request body.

[0094] In this embodiment, it should be noted that the request method of the http request may include multiple types such as GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE and PATCH. Before the Web end generates the first object character according to the valid parameters in the second request parameter, it is necessary to first determine which specific request method the http request is, so that the position of the valid parameter data in the second request parameter can be determined according to the request method. After determining the position of the valid parameter data, the valid parameter data can be obtained, and the subsequent generation step of the first object string _str is performed. Specifically, if the Web end determines that the request method of the http request is a GET request, it can be considered that the valid parameters of the second request parameter are located in the query of the URL. If the Web end determines that the request method of the http request is not a GET request, it can be considered that the valid parameters of the second request parameter are located in the body request body.

[0095] Step 205: concatenate the first signature and the first object character string to obtain a first character string.

[0096] In the embodiment of the present application, it should be noted that after obtaining the first object string _str, the Web end can further concatenate the first signature token and the generated first object string _str, and record the concatenated data as the first string.

[0097] Step 206: Use the access token as a secret key to perform encryption calculation on the first character string to generate a web page ciphertext, and add the web page ciphertext to the second request parameter.

[0098] In the embodiment of the present application, it should be noted that the Web-side ciphertext may refer to sign0, which may refer to an authentication identifier. After obtaining the first character string, the Web-side may perform HmacSHA256 encryption calculation on the first character string using token as the secret key to generate the Web-side ciphertext sign0, so that the Server-side can subsequently verify whether the second request parameter carried in the http request has been tampered with during the sending process. After obtaining sign0, the Web-side may further add sign0 to the second request parameter so that it can be sent to the Server-side together with the second request parameter. At this point, the preparatory actions before the Web-side initiates the request have been completed.

[0099] Step 207: Send a resource request to the server, wherein the resource request includes a second request parameter, and the second request parameter includes a valid parameter, a request line, and a request header.

[0100] In an embodiment of the present application, after the preparatory actions before initiating the request on the Web side are completed, the Web side initiates an http request carrying a second request parameter to the Server side, wherein the second request parameter includes a valid parameter, a request line and a request header, and the valid parameter may refer to the actual data to be sent.

[0101] like Figure 3 As shown, a timing diagram of a method for website request tamper-proofing is provided.

[0102] The web side can initiate a login request carrying the first request parameter to the server side, and the server side performs login authentication. When the login authentication is passed, the web side successfully logs in to the server side. When the web side successfully logs in to the server side, the server side generates a token for the web side, and encrypts and calculates the first request parameter carried by the login request of the web side to generate an rtoken for use by the web side to initiate subsequent requests. After generating the token and rtoken of the web side, the server side can store the token and rtoken in the database and return them to the web side at the same time. The web side receives the token and rtoken returned by the server side. After receiving the token and rtoken returned by the server side, the web side can store the received token and rtoken in a cookie used to identify identity and track behavior, and set it as a secure cookie so that the web side cannot tamper with the rtoken later.

[0103] Before the Web side initiates a resource request to the Server side, it needs to perform preparatory actions before initiating the request. Specifically, the Web side needs to first construct an http request carrying a second request parameter, where the second request parameter should include valid parameters, a request line, and a request header. After constructing the http request carrying the second request parameter, the Web side needs to first determine which specific request method the http request is, so that the location of the valid parameter data in the second request parameter can be determined according to the request method. Specifically, if the Web side determines that the request method of the http request is a GET request, it can be considered that the valid parameters of the second request parameter are located in the query of the URL. If the Web side determines that the request method of the http request is not a GET request, it can be considered that the valid parameters of the second request parameter are located in the body request body. After determining the location of the valid parameter data, the valid parameter data can be obtained.

[0104] The Web end converts the data parameter into a Key-Value, and then sorts based on the Key to obtain the second intermediate parameter _data. At this time, the data content of _data includes {first parameter, value; second parameter, value; ...}. After obtaining the second intermediate parameter _data, the Web end further processes and converts the second intermediate parameter _data into the corresponding first object string _str.

[0105] After the Web end obtains the first object string _str, the Web end can further concatenate the first signature token and the generated first object string _str, and record the concatenated data as the first string, and use token as the secret key to perform HmacSHA256 encryption calculation on the first string to generate the Web end ciphertext sign0, so that the Server end can subsequently verify whether the second request parameter carried in the http request has been tampered with during the sending process. After the Web end obtains sign0, it can further add sign0 to the second request parameter to be sent to the Server end together with the second request parameter. At this point, the preparatory actions before initiating the request on the Web end are completed. After the preparatory actions before initiating the request on the Web end are completed, the Web end initiates an http request carrying the second request parameter to the Server end.

[0106] The server receives the http request initiated by the web end and carries the second request parameter, and determines whether the web end ciphertext sign0 exists in the http request. If the server end determines that there is no sign0 in the http request, the server end may consider that the http request initiated by the web end is abnormal. At this time, the web end generates an error message of the abnormal request and returns it to the web end, and refuses to receive the second request parameter. If the server end determines that there is sign0 in the http request, the valid parameter data in the second request parameter is obtained. The server end converts the data parameter into Key-Value, and then sorts it based on the Key to obtain the first intermediate parameter _data. It should be noted that the data content of _data at this time includes {first parameter, value; second parameter, value; ......}. After obtaining the first intermediate parameter _data, the server end further processes and converts the first intermediate parameter _data into the corresponding second object string _str. After obtaining the second object string _str, the server end further splices the first signature rtoken with the second object string _str, and records the spliced ​​data as the second string.

[0107] After the server obtains the second string, it can use token as the secret key to perform HmacSHA256 encryption calculation on the second string to generate the server-side ciphertext sign1, and compare the Web-side ciphertext sign0 obtained in the http request with the server-side ciphertext sign1 to determine whether the two are consistent. When the Web-side ciphertext sign0 is consistent with the Server-side ciphertext sign1, the server can assume that the second request parameter carried by the http request has not been tampered with during the issuance process, and receive the second request parameter. When the Web-side ciphertext sign0 is inconsistent with the Server-side ciphertext sign1, the server can assume that the second request parameter carried by the http request has been tampered with during the issuance process, the http request is blocked, and the second request parameter is refused to be received, and an error prompt is given.

[0108] When the Web-side ciphertext sign0 is consistent with the Server-side ciphertext sign1, the Server-side will replace the value of the first signature rtoken with the Server-side ciphertext sign1, thereby obtaining the second signature rtoken for the Web-side to initiate the next http request, and return the second signature rtoken to the Web-side. The Web-side can store the second signature rtoken in a cookie and set it as a secure cookie to prevent the Web-side from tampering with the second signature rtoken.

[0109] This technical solution has real-time signature updates, irreversible encryption, and high security. It covers all types of http requests, not just GET and POST. It performs sorting before encryption calculation to avoid the problem of inconsistent parameter order between the Web-side transmission and the server-side reception due to various reasons such as third-party libraries. It uses the HmacSHA256 encryption algorithm, which is more suitable for parameter verification scenarios, and the secret key token is also based on the user and login session, so different users and different Web terminals have different tokens, and the final encryption results are also different, making the system more secure.

[0110] In one embodiment, a performance test and analysis is performed. The system environment used in the test is configured as: Linux system, total memory 16G, remaining memory about 4.8G, CPU 4 cores 2.4GHz. The test method is to take 50 groups of using and not using the anti-tampering method in the technical solution, and compare the time information of the same http request before and after. The data collection is shown in Table 1:

[0111] Table 1 Comparison of request time information data before and after use

[0112]

[0113]

[0114]

[0115] According to the data in Table 1, it can be calculated that before using the anti-tampering technology in this technical solution, the average time of the http request is 41.8364, and after using the anti-tampering technology in this technical solution, the average time of the http request is 41.8510. In order to more intuitively reflect the before and after comparison, this technical solution constructs the following Figure 4 and Figure 5 The line chart shows the time information and average time information of http requests before and after use.

[0116] In summary, for a request that takes an average of 41.8364ms, the anti-tampering technology in this technical solution increases the time by an average of 0.0146ms, or 0.035%. For other requests that take longer, the increase of 0.0146ms accounts for a smaller proportion. Therefore, the impact on performance is minimal and can be ignored.

[0117] In a specific embodiment, based on the scenario that after a user successfully logs into the Web system, a browser developer tool or a third-party tool is used to adjust the parameters of the request that has been sent and then re-send it, the process of using the technical solution to identify and handle dangerous behaviors is described. The specific process includes:

[0118] (1) The user logs in to the system Web end. At this time, the real-time signature is rtoken. The page operation generates a new request. Before the request is made, the Web end sorts and concatenates the valid parameters data and the real-time signature rtoken, and then uses token as the secret key to perform HmacSHA256 encryption calculation to obtain the ciphertext sign0. The original parameters carrying the ciphertext continue to be sent normally.

[0119] (2) After receiving the request, the server sorts and concatenates the valid parameters data and the real-time signature rtoken, and then uses token as the secret key to perform HmacSHA256 encryption calculation to obtain the ciphertext sign1. At this time, sign0 and sign1 are consistent, and the request is normal. The server then updates rtoken to sign1, which is recorded as _rtoken.

[0120] (3) The user uses the browser developer tools or third-party tools to capture the requests that have been sent.

[0121] (4) The captured request's valid parameter data is modified to the intermediate parameter _data and then re-issued. At this time, the intermediate parameter _data issued already contains the encryption calculation result sign0 calculated by the Web end based on the valid parameter data before modification. The Web end will not calculate a new ciphertext again.

[0122] (5) The server receives the request to replay the message, takes out the old sign0, sorts the valid parameter _data, and concatenates it with the real-time signature _rtoken, and then uses token as the secret key to perform HmacSHA256 encryption to obtain the ciphertext _sign1.

[0123] (6) The server compares sign0 and _sign1.

[0124] (7) Since the values ​​of _rtoken (current value is sign1) and rtoken are different, and the values ​​of data, one of the original data of the current parameters _data and sign0, are also different, the final server-side calculation results, the latest ciphertext _sign1 and sign0, are also different, so the request is identified as an abnormal request, the request is intercepted, and the dangerous behavior is blocked.

[0125] In a specific embodiment, based on the scenario of issuing a request with fake user authentication information, the process of using this technical solution to identify and handle dangerous behaviors is described. The specific process is as follows:

[0126] (1) A normal user logs in to the system Web end and generates a request through page operation. At this time, the real-time signature is rtoken. The request is sorted and concatenated by the Web end. The parameter data and the real-time signature rtoken are encrypted with HmacSHA256 using token as the secret key to obtain the ciphertext sign0, which is then sent normally.

[0127] (2) The server sorts and concatenates the parameter data and the real-time signature rtoken, and uses token as the secret key to perform HmacSHA256 encryption to obtain the ciphertext sign1. At this time, sign0 and sign1 are consistent, and the request is normal. The server then updates rtoken to sign1, which is recorded as _rtoken.

[0128] (3) Illegal users obtain the request information of normal users through special means, including cookies, request addresses, parameters, etc.

[0129] (4) Illegal users use tools such as Postman to send cookies together with tokens, request addresses, parameters, etc.

[0130] (5) At this time, the ciphertext sent by the illegal user is still sign0 calculated based on rtoken. The server receives the request, takes out the old sign0, sorts the parameter data and concatenates it with the real-time signature _rtoken at this time, and then performs HmacSHA256 encryption with token as the secret key to obtain the ciphertext _sign1.

[0131] (6) The server compares sign0 and _sign1.

[0132] (7) Since the values ​​of _rtoken (current value is sign1) and rtoken are different, the latest ciphertexts _sign1 and sign0 are also different. Therefore, the request is identified as an abnormal request, the request is intercepted, and the dangerous behavior is blocked.

[0133] In this technical solution, the system Web end and the server end uniformly sort the parameters by key name before encrypting them to avoid misjudgment caused by inconsistent order; the valid parameters can be encrypted and calculated for all types of http requests to avoid incomplete coverage of business scenarios; the real-time signature is updated every time a request is made to prevent the fixed signature from being obtained and used for dangerous attacks, and the additional calculation amount and algorithm complexity are not increased. The calculation result is directly used to update the real-time signature each time the parameter is detected; the HmacSHA256 encryption algorithm and token key are used to enhance system security.

[0134] The present application embodiment provides a server, including:

[0135] a memory configured to store instructions;

[0136] The processor is configured to call the instructions from the memory and implement the above-mentioned method for preventing website request from being tampered with when executing the instructions.

[0137] The present application provides a web page, including:

[0138] a memory configured to store instructions;

[0139] The processor is configured to call the instructions from the memory and implement the above-mentioned method for preventing website request from being tampered with when executing the instructions.

[0140] An embodiment of the present application provides a storage medium on which a program is stored. When the program is executed by a processor, the method for preventing website request tampering is implemented.

[0141] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 6As shown. The computer device includes a processor A01, a network interface A02, a memory (not shown in the figure) and a database (not shown in the figure) connected via a system bus. Among them, the processor A01 of the computer device is used to provide computing and control capabilities. The memory of the computer device includes an internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02 and a database (not shown in the figure). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 in the non-volatile storage medium A04. The database of the computer device is used to store method data for website request anti-tampering. The network interface A02 of the computer device is used to communicate with an external terminal through a network connection. When the computer program B02 is executed by the processor A01, a method for website request anti-tampering is implemented.

[0142] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0143] An embodiment of the present application provides a device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, a method for implementing anti-tampering methods for website requests is implemented.

[0144] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing the program of the method steps of initializing website request anti-tampering.

[0145] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0146] The present application is described with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0147] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0148] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0149] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0150] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0151] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0152] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0153] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for preventing website request tampering, characterized in that: Applied to the server, the method includes: If the web page login is successful, an access token for the web page is generated, and a first request parameter carried in the login request of the web page is encrypted and calculated to generate a first signature; Returning the access token and the first signature to the web page; Receiving a resource request initiated by the webpage, wherein the resource request carries a second request parameter; Determine whether there is a web page ciphertext in the resource request, wherein the web page ciphertext is generated by encrypting a first character string using the access token as a secret key, and the first character string is obtained by concatenating the first signature and the first object character string; When it is determined that the web page ciphertext exists in the resource request, obtaining valid parameters in the second request parameters; Generate a second object character string according to the valid parameters; Concatenate the first signature and the second object character string to obtain a second character string; Using the access token as a secret key, encrypting the second character string to generate a server-side ciphertext; When the web page ciphertext is consistent with the server ciphertext, it is determined that the second request parameter carried by the resource request has not been tampered with during the sending process, and the second request parameter is received.

2. The method for preventing website request tampering according to claim 1, characterized in that: The method further comprises: When the web page ciphertext is inconsistent with the server ciphertext, it is determined that the second request parameter carried by the resource request has been tampered with during the sending process, and the second request parameter is refused to be received.

3. The method for preventing website request tampering according to claim 1, characterized in that: Generating a second object character string according to the valid parameters comprises: Convert the data included in the effective parameters into first key-value pairs, and sort the first key-value pairs based on the keywords to obtain first intermediate parameters, wherein each first key-value pair consists of a keyword and a value; Convert the first intermediate parameter into the second object string.

4. The method for preventing website request tampering according to claim 1, characterized in that: The method further comprises: When it is determined that the web page end ciphertext does not exist in the resource request, determining that the resource request is an abnormal request; Generate an error message for the abnormal request and return it to the web page.

5. The method for preventing website request tampering according to claim 1, characterized in that: The method further comprises: After determining that the webpage ciphertext is consistent with the server ciphertext, replacing the value of the first signature with the server ciphertext to obtain a second signature; The second signature is returned to the web page.

6. A method for preventing website requests from being tampered with, characterized in that: Applied to a web page, the method includes: Initiate a login request to the server, the login request including a first request parameter, the server generates an access token when determining that the login is successful, and encrypts the first request parameter carried by the login request of the web page to generate a first signature; Receive the access token and the first signature returned by the server; Generate a first object string according to valid parameters; Concatenate the first signature and the first object character string to obtain a first character string; Using the access token as a secret key, encrypt the first character string to generate a web page ciphertext, and add the web page ciphertext to the second request parameter; Send a resource request to the server, wherein the resource request includes the second request parameter, and the second request parameter includes the valid parameter, the request line, and the request header.

7. The method for preventing website request tampering according to claim 6, characterized in that: Generating the first object character string according to the valid parameters comprises: Determine a request mode of the resource request, and determine a position of a valid parameter in the second request parameter based on the request mode; Acquire the valid parameters based on their positions; Convert the data included in the effective parameters into second key-value pairs, and sort the second key-value pairs based on the keywords to obtain second intermediate parameters, wherein each key-value pair consists of a keyword and a value; Convert the second intermediate parameter into the first object string.

8. The method for preventing website request tampering according to claim 7, characterized in that: The determining the request mode of the resource request to determine the position of the valid parameter in the second request parameter based on the request mode includes: Determine whether the request method of the resource request is a GET request; When the request method is a GET request, determining that the valid parameter is located in the query of the URL; When the request mode is not a GET request, it is determined that the valid parameters are located in the body request body.

9. The method for preventing website request tampering according to claim 8, characterized in that: The method further comprises: After receiving the access token and the first signature returned by the server, storing the first signature in a cookie; The cookie is set as a secure cookie so that the web page cannot tamper with the first signature.

10. A server, characterized in that: include: a memory configured to store instructions; A processor is configured to call the instructions from the memory and implement the method for preventing website request tampering according to any one of claims 1 to 5 when executing the instructions.

11. A web page, characterized in that: include: a memory configured to store instructions; A processor is configured to call the instructions from the memory and implement the method for preventing website request tampering according to any one of claims 6 to 9 when executing the instructions.

12. A machine-readable storage medium having instructions stored thereon, characterized in that: When the instruction is executed by a processor, the processor is configured to execute the method for preventing website request tampering according to any one of claims 1 to 5 or the method for preventing website request tampering according to any one of claims 6 to 9.

13. A computer program product, characterized in that The invention comprises a computer program, which, when executed by a processor, implements the method for preventing website request tampering according to any one of claims 1 to 5 or the method for preventing website request tampering according to any one of claims 6 to 9.

Images