Website request tamper-proofing method, server, web page, and storage medium

Abstract

This application provides a method, server, web page, and storage medium for preventing website request tampering. Applied to the server, the method includes: upon successful login on the web page, generating an access token for the web page; encrypting and calculating a first request parameter carried in the login request to generate a first signature, and returning it to the web page; receiving a resource request from the web page carrying a second request parameter; determining whether the resource request contains web page ciphertext; if web page ciphertext is found, obtaining valid parameters from the second request parameter; generating a second object string based on the valid parameters; concatenating the first signature and the second object string to obtain a second string; encrypting and calculating the second string using the access token as a key to generate server-side ciphertext; and determining that the second request parameter carried in the resource request has not been tampered with during the distribution process when the web page ciphertext and the server-side ciphertext match.

Description

Technical Field

[0001] This application relates to the field of data security transmission technology, specifically to a method for preventing website requests from being tampered with, a server, a web page, a storage medium, and a computer program product. Background Technology

[0002] Web-based network security is one of the most important application areas and directions of network security, and the security of interactions between the web client and the server is particularly important. If interaction request parameters are tampered with, they could be used by malicious actors to impersonate super administrators and gain unauthorized system privileges. Therefore, preventing the tampering of interaction request parameters between the web client and the server is of paramount importance.

[0003] In existing technologies, the security mechanisms commonly used in the web application domain are token verification and parameter encryption. However, token security and timeliness are significant issues, and there is still a risk that malicious actors can use intercepted tokens to tamper with parameters and resend them. Therefore, a signature parameter rtoken (refreshtoken) that can be updated in real time and serves a similar function to the token is also needed. This, combined with an encryption method using a key agreed upon by the web and server sides, is used for encrypted verification to prevent request parameters from being tampered with.

[0004] To address the aforementioned technical issues, existing technologies provide a method for preventing HTTP request data tampering and a URL anti-tampering signature and verification method based on the MD5 algorithm. The time window in the HTTP request data tampering prevention method is a vague concept. If the time window is set too short, the effect is insignificant, and replay attacks after the time interval cannot be detected. If the time window is set too long, the database needs to store a large amount of data, which, given the large number of system interfaces and users, could lead to excessive data volume, significantly reducing comparison and query performance and increasing the server load. The MD5-based URL anti-tampering signature and verification method only encrypts and compares parameters in the URL, not in the request body. Therefore, if the parameters in the body are tampered with, it will not affect the final encrypted Sign and Sign2 results; they will remain identical. This technology only works for GET requests (such as those that pass parameters via the URL) and can only prevent URL parameter tampering; it cannot prevent POST requests (such as those that pass parameters via the body) from having their body parameters tampered with. Furthermore, replaying requests that have already been sent does not solve the problem of replay attacks because the interface and parameters remain unchanged, and therefore the Sign parameter also remains unchanged. The Sign2 calculated by the backend after receiving the request also remains unchanged. Summary of the Invention

[0005] The purpose of this application is to provide a method, server, web page, storage medium, and computer program product for preventing website requests from being tampered with, in order to solve the technical defects in the prior art where the server cannot effectively identify whether the received request has been tampered with, resulting in the server's inability to identify replay attacks.

[0006] To achieve the above objectives, the first aspect of this application provides a method for preventing website requests from being tampered with, applied on the server side, the method comprising:

[0007] Upon successful login via the web page, an access token for the web page is generated, and the first request parameter carried in the login request from the web page is encrypted and calculated to generate the first signature.

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

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

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

[0011] If it is determined that there is encrypted content from the web page in the resource request, obtain the valid parameters from the second request parameters;

[0012] Generate a second object string based on the valid parameters;

[0013] The first signature is concatenated with the second object string to obtain the second string;

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

[0015] If the encrypted message on the webpage matches the encrypted message 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 embodiments of this application, the method further includes: if the encrypted text on the webpage is inconsistent with the encrypted text on the server, determining that the second request parameter carried in the resource request has been tampered with during the sending process, and refusing to receive the second request parameter.

[0017] In embodiments of this 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 embodiments of this application, the method further includes: determining that the resource request is an abnormal request if the webpage ciphertext is not present in the resource request; generating error information for the abnormal request and returning it to the webpage.

[0019] In embodiments of this application, the method further includes: after determining that the ciphertext on the webpage is consistent with the ciphertext on the server, replacing the value of the first signature with the ciphertext on the server to obtain the second signature; and returning the second signature to the webpage.

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

[0021] The memory is configured to store instructions;

[0022] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned method for preventing website request tampering.

[0023] A third aspect of this application provides a method for preventing website requests from being tampered with, applied to a webpage, the method comprising:

[0024] A login request is sent to the server. The login request includes the first request parameter. If the login is successful, the server generates an access token and performs encrypted calculation on the first request parameter carried by the login request from the web page to generate the first signature.

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

[0026] Generate a first object string based on the valid parameters;

[0027] The first signature is concatenated with the first object string to obtain the first string;

[0028] The first string is encrypted using the access token as the key to generate ciphertext on the web page, and then the ciphertext on the web page is added to the second request parameter.

[0029] Send a resource request to the server. The resource request includes a second request parameter, which includes valid parameters, a request line, and a request header.

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

[0031] In embodiments of this application, determining the request method of a resource request to determine the location of a valid parameter in the second request parameter based on the request method includes: determining whether the request method of the resource request is a GET request; if the request method is a GET request, determining that the valid parameter is located in the query of the URL; if the request method is not a GET request, determining that the valid parameter is located in the request body.

[0032] In embodiments of this application, the method further includes: after receiving the access token and the first signature returned by the server, storing the first signature in a cookie; and setting the cookie as a secure cookie so that the webpage cannot tamper with the first signature.

[0033] A fourth aspect of this application provides a web-based interface, including:

[0034] The memory is configured to store instructions;

[0035] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned method for preventing website request tampering.

[0036] A fifth aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the aforementioned method for preventing website request tampering.

[0037] The sixth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method for preventing website request tampering according to any of the above embodiments.

[0038] The above technical solution, upon successful login on the webpage, generates an access token for the webpage, encrypts the first request parameters carried in the login request to generate a first signature, and returns it to the webpage; receives a resource request from the webpage carrying a second request parameter; determines whether the resource request contains webpage-based ciphertext; if webpage-based ciphertext is found, obtains the valid parameters from the second request parameters; generates a second object string based on the valid parameters; concatenates the first signature and the second object string to obtain a second string; uses the access token as a key to encrypt the second string to generate server-side ciphertext; and when the webpage-side ciphertext matches the server-side ciphertext, it is determined that the second request parameters carried in the resource request have not been tampered with during the distribution process. This effectively identifies whether the received request has been tampered with and effectively prevents replay attacks.

[0039] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0040] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:

[0041] Figure 1 The illustration shows a flowchart of a method for requesting anti-tampering of a website according to an embodiment of this application;

[0042] Figure 2 A timing diagram illustrating yet another method for requesting anti-tampering for a website according to an embodiment of this application is shown schematically;

[0043] Figure 3 The illustration schematically shows a timing diagram of a method for requesting anti-tampering of a website according to an embodiment of this application;

[0044] Figure 4 This illustration schematically shows a diagram illustrating the timing information of a resource request according to an embodiment of this application;

[0045] Figure 5 This illustration shows a schematic diagram of the average time taken for a resource request according to an embodiment of this application;

[0046] Figure 6 The diagram illustrates the internal structure of a computer device according to an embodiment of this application. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0048] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0049] Figure 1 This illustration schematically depicts a flowchart of a method for preventing website tampering according to an embodiment of this application. Figure 1 As shown in the figure, this application provides a method for preventing website requests from being tampered with, which can be applied to the server side. The method may include the following steps.

[0050] Step 101: If the login is successful on the web page, generate an access token for the web page and perform encrypted calculation on the first request parameter carried in the login request on the web page to generate a first signature.

[0051] In this embodiment, it should be noted that "web client" can refer to a Web client, which refers to an application or service accessed and used through a web browser. In the computer and internet field, "Web" refers to web pages and web applications on the internet. "Server" can refer to a server, which refers to a computer or device that provides services in a computer network, typically running on a server on the network, responsible for processing requests from clients or Web clients and providing corresponding services or resources. Specifically, the Web client can initiate a login request carrying a first request parameter to the server. The server performs login authentication, and when the authentication is successful, the Web client successfully logs into the server. It should be noted that the login request can refer to an HTTP request, which is a request message sent from a client or Web client to a server to obtain resources from the server. An HTTP request consists of a request line, request headers, and a request body, and each HTTP request is independent. Therefore, the first request parameter can refer to a Hypertext Transfer Protocol (HTTP) consisting of a request line, request headers, and a request body.

[0052] It's important to note that an access token can refer to a single encrypted string used for authentication and access control. It acts as an "identity token" for the visitor; the server verifies the token's validity to determine the visitor's identity and permissions. The first signature (rtoken) refers to the initially generated token, abbreviated as rtoken (refresh token). An rtoken is a server-generated string used by the client to make requests. Upon the first login, the server generates an rtoken and returns it to the client. The client needs to include this rtoken in subsequent requests, eliminating the need to include the username and password again. The rtoken acts like a "secret code," used for verification before data transmission to ensure data accessibility and security. Specifically, when a web client successfully logs into the server, the server generates a token for the web client and encrypts the initial request parameters carried in the web client's login request to generate an rtoken, which the web client can use for subsequent requests. In this technical solution, the encryption calculation can refer to HmacSHA256 encryption calculation. HmacSHA256 is a message authentication code algorithm based on a hash function. It is mainly used to verify the integrity and authenticity of messages, rather than actually used to encrypt or decrypt data. It uses the SHA-256 hash function in combination with a key to calculate the message authentication code to ensure the integrity and authenticity of the data.

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

[0054] In this embodiment, after generating the token and rtoken for the web client, the server can store the token and rtoken in the database and simultaneously return them to the web client. The web client can store the received token and rtoken in a cookie used for identity verification and behavior tracking, and set it as a security cookie so that the web client cannot tamper with the rtoken subsequently.

[0055] Step 103: Receive the resource request initiated by the web page. The resource request carries the second request parameter.

[0056] In this embodiment, it should be noted that a resource request can refer to a data access or data query request, but essentially, a resource request can refer to an HTTP request initiated by a web client to a server. Therefore, the resource request carrying the second request parameter can refer to a Hypertext Transfer Protocol consisting of a request line, request headers, and a request body, where the request body can refer to valid parameters. Specifically, after the web client successfully logs into the server and receives the token and rtoken returned by the server, the web client can initiate another HTTP request to the server, carrying the second request parameter, and the server will receive the HTTP request initiated by the web client.

[0057] Step 104: Determine whether there is web-side ciphertext in the resource request. The web-side ciphertext is generated by encrypting the first string using the access token as the key. The first string is obtained by concatenating the first signature and the first object string.

[0058] In this embodiment, it should be noted that before the Web client initiates a resource request to the Server, it needs to perform preparatory actions. Specifically, the Web client first constructs a resource request carrying a second request parameter, and generates a first object string (which can be _str) using this second request parameter. Then, it concatenates the first signature rtoken and the generated first object string into a first string. Finally, it uses the token as the key to perform HmacSHA256 encryption on the first string to generate the Web client's ciphertext. The Web client's ciphertext can refer to sign0. After obtaining sign0, the Web client can further add sign0 to the second request parameter, which is then sent to the Server along with the second request parameter. At this point, the preparatory actions for initiating the request by the Web client are complete. The Web client then initiates an HTTP request to the Server. When the Server receives the HTTP request from the Web client, it needs to further determine whether sign0 exists in the HTTP request, in order to verify whether the second request parameter carried in the HTTP request has been tampered with during the transmission process.

[0059] Step 105: If it is determined that there is encrypted text from the web page in the resource request, obtain the valid parameters from the second request parameters.

[0060] In this embodiment of the 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. The data parameters are a way to send data in the HTTP request, and they usually contain the data to be sent.

[0061] In this embodiment of the application, the method further includes: determining that the resource request is an abnormal request if the webpage ciphertext is not present in the resource request; generating error information for the abnormal request and returning it to the webpage.

[0062] In this embodiment, it should be noted that if the server determines that sign0 does not exist in the HTTP request, the server can consider the HTTP request initiated by the web client to be abnormal. In this case, the web client generates an error message for the abnormal request and returns it to the web client, and refuses to accept the second request parameter.

[0063] Step 106: Generate a second object string based on the valid parameters.

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

[0065] In this embodiment of the 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 key-value pairs can refer to Key-Value pairs, a common data representation method. The key serves as a unique identifier, also known as a keyword, and the value is the corresponding data for that key. The first intermediate parameter can refer to _data. Specifically, the server converts the data parameter into a Key-Value pair, 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 point includes {first parameter, value; second parameter, value; ...}. It should also be noted that the second object string can refer to _str. After obtaining the first intermediate parameter _data, the server can further process it to convert the first intermediate parameter _data into the corresponding second object string _str.

[0067] Step 107: Concatenate the first signature with the second object string to obtain the second string.

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

[0069] Step 108: Use the access token as the key to perform encrypted calculations on the second string to generate server-side ciphertext.

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

[0071] Step 109: If the encrypted text on the webpage is consistent with the encrypted text on the server, determine that the second request parameter carried in the resource request has not been tampered with during the sending process, and receive the second request parameter.

[0072] In this embodiment, after generating the server-side ciphertext sign1, the web-side ciphertext sign0 obtained from the HTTP request is compared with the server-side ciphertext sign1 to determine if they are consistent. If the web-side ciphertext sign0 and the server-side ciphertext sign1 are consistent, the server can assume that the second request parameter carried in the HTTP request has not been tampered with during the sending process and accept the second request parameter.

[0073] In this embodiment of the application, if the encrypted text on the webpage is inconsistent with the encrypted text on the server, it is determined that the second request parameter carried in the resource request has been tampered with during the sending process, and the second request parameter is refused to be received.

[0074] In this embodiment, when the ciphertext sign0 on the Web side is inconsistent with the ciphertext sign1 on the Server side, the Server side can assume that the second request parameter carried in the HTTP request has been tampered with during the sending process, the HTTP request is blocked, the second request parameter is refused to be received, and an error message is displayed.

[0075] In this embodiment of the application, the method further includes: after determining that the ciphertext on the webpage is consistent with the ciphertext on the server, replacing the value of the first signature with the ciphertext on the server to obtain the second signature; and returning the second signature to the webpage.

[0076] In this embodiment, when the ciphertext sign0 on the Web side matches the ciphertext sign1 on the Server side, the Server side will replace the value of the first signature rtoken with the ciphertext sign1 on the Server side, 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.

[0077] The above technical solution, upon successful login on the webpage, generates an access token for the webpage, encrypts the first request parameters carried in the login request to generate a first signature, and returns it to the webpage; receives a resource request from the webpage carrying a second request parameter; determines whether the resource request contains webpage-based ciphertext; if webpage-based ciphertext is found, obtains the valid parameters from the second request parameters; generates a second object string based on the valid parameters; concatenates the first signature and the second object string to obtain a second string; uses the access token as a key to encrypt the second string to generate server-side ciphertext; and when the webpage-side ciphertext matches the server-side ciphertext, it is determined that the second request parameters carried in the resource request have not been tampered with during the distribution process. This effectively identifies whether the received request has been tampered with and effectively prevents replay attacks.

[0078] Figure 2 This illustration schematically depicts a flowchart of another website request anti-tampering method according to an embodiment of this application. Figure 2 As shown in the figure, this application provides a method for preventing website requests from being tampered with, which can be applied to web pages. The method may include the following steps.

[0079] Step 201: Send a login request to the server. The login request includes a first request parameter. If the login is successful, the server generates an access token and performs encrypted calculation on the first request parameter carried by the login request from the web page to generate a first signature.

[0080] In this embodiment, it should be noted that "web client" can refer to a Web client, which refers to an application or service accessed and used through a web browser. In the computer and internet field, "Web" refers to web pages and web applications on the internet. "Server" can refer to a server, which refers to a computer or device that provides services in a computer network, typically running on a server on the network, responsible for processing requests from clients or Web clients and providing corresponding services or resources. Specifically, the Web client can initiate a login request carrying a first request parameter to the server. The server performs login authentication, and when the authentication is successful, the Web client successfully logs into the server. It should be noted that the login request can refer to an HTTP request, which is a request message sent from a client or Web client to a server to obtain resources from the server. An HTTP request consists of a request line, request headers, and a request body, and each HTTP request is independent. Therefore, the first request parameter can refer to a Hypertext Transfer Protocol (HTTP) consisting of a request line, request headers, and a request body.

[0081] It's important to note that an access token can refer to a single encrypted string used for authentication and access control. It acts as an "identity token" for the visitor; the server verifies the token's validity to determine the visitor's identity and permissions. The first signature (rtoken) refers to the initially generated token, abbreviated as rtoken (refresh token). An rtoken is a server-generated string used by the client to make requests. Upon the first login, the server generates an rtoken and returns it to the client. The client needs to include this rtoken in subsequent requests, eliminating the need to include the username and password again. The rtoken acts like a "secret code," used for verification before data transmission to ensure data accessibility and security. Specifically, when a web client successfully logs into the server, the server generates a token for the web client and encrypts the initial request parameters carried in the web client's login request to generate an rtoken, which the web client can use for subsequent requests. In this technical solution, the encryption calculation can refer to HmacSHA256 encryption calculation. HmacSHA256 is a message authentication code algorithm based on a hash function. It is mainly used to verify the integrity and authenticity of messages, rather than actually used to encrypt or decrypt data. It uses the SHA-256 hash function in combination with a key to calculate the message authentication code to ensure the integrity and authenticity of the data.

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

[0083] In this embodiment of the application, after the server generates the token and rtoken for the web client, it can store the token and rtoken in the database and simultaneously return them to the web client. The web client receives the token and rtoken returned by the server.

[0084] In this embodiment of the application, the method further includes: after receiving the access token and the first signature returned by the server, storing the first signature in a cookie; and 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 client can store the received token and rtoken in a cookie used for identity verification and behavior tracking, and set it as a security cookie so that the web client cannot tamper with the rtoken later.

[0086] Optional step 203: Construct a resource request. The resource request includes a second request parameter, which includes valid parameters, a request line, and a request header.

[0087] In this embodiment, it should be noted that a resource request can refer to a data access or data query request, but essentially, a resource request can refer to an HTTP request initiated by a web client to a server. Therefore, a resource request carrying a second request parameter can refer to a Hypertext Transfer Protocol (HTTP) request consisting of a request line, request headers, and a request body, where the request body can refer to valid parameters. It should be noted that before initiating a resource request to the server, the web client needs to perform preparatory actions. Specifically, the web client needs to first construct an HTTP request carrying the second request parameter, which should include valid parameters, a request line, and request headers.

[0088] Step 204: Generate the first object string based on the valid parameters.

[0089] In this embodiment of the application, it should be noted that the first object string can be _str. Specifically, after the web client constructs an HTTP request carrying the second request parameters, the web client can further generate the first object string, which can be _str, based on the valid parameters in the second request parameters.

[0090] In this embodiment of the application, generating a first object string based on valid parameters includes: determining the request method of the resource request, and determining the position of the valid parameters in the second request parameters based on the request method; obtaining the valid parameters based on the position of the valid parameters; converting the data included in the valid parameters into second key-value pairs, sorting 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; and converting the second intermediate parameters into a first object string.

[0091] In this embodiment, it should be noted that the HTTP request method can include various types such as GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH. Before generating the first object string on the web side based on the valid parameters in the second request parameters, it is necessary to determine the specific HTTP request method. This allows the location of the valid parameter `data` in the second request parameters to be determined based on the request method. After determining the location of the valid parameter `data`, it can be obtained, and the subsequent step of generating the first object string `_str` can be performed.

[0092] It's important to note that key-value pairs refer to a common data representation method, where the key serves as a unique identifier, also known as a keyword, and the value is the corresponding data. The second intermediate parameter can refer to `_data`. Specifically, the web application converts the `data` parameter into a key-value pair, then sorts it based on the key to obtain the second intermediate parameter `_data`. It's worth noting that the content of `_data` at this point includes {first parameter, value; second parameter, value; ...}. After obtaining the second intermediate parameter `_data`, the web application can further process it by converting it into the corresponding first object string `_str`.

[0093] In this embodiment of the application, determining the request method of the resource request in order to determine the location of the valid parameter in the second request parameter based on the request method includes: determining whether the request method of the resource request is a GET request; if the request method is a GET request, determining that the valid parameter is located in the query of the URL; if the request method is not a GET request, determining that the valid parameter is located in the request body.

[0094] In this embodiment, it should be noted that the HTTP request method can include various types such as GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH. Before generating the first object string on the web side based on the valid parameters in the second request parameters, it is necessary to determine the specific HTTP request method. This allows the location of the valid parameter `data` in the second request parameters to be determined based on the request method. After determining the location of the valid parameter `data`, it can be obtained, and the subsequent step of generating the first object string `_str` can be performed. Specifically, if the web side determines that the HTTP request method is a GET request, the valid parameter of the second request parameter can be considered to be located in the URL query. If the web side determines that the HTTP request method is not a GET request, the valid parameter of the second request parameter can be considered to be located in the request body.

[0095] Step 205: Concatenate the first signature with the first object string to obtain the first string.

[0096] In this embodiment of the application, it should be noted that after obtaining the first object string _str, the Web client 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: Using the access token as the key, perform encryption calculations on the first string to generate web-side ciphertext, and add the web-side ciphertext to the second request parameters.

[0098] In this embodiment, it should be noted that the Web-side ciphertext can refer to sign0, which can be an authentication identifier. After obtaining the first string, the Web client can use the token as the key to perform HmacSHA256 encryption calculation on the first string to generate the Web-side ciphertext sign0, which is used by the Server to verify whether the second request parameter carried in the HTTP request has been tampered with during the sending process. After obtaining sign0, the Web client can further add sign0 to the second request parameter so that it can be sent to the Server along with the second request parameter. At this point, the Web client's preparatory actions before initiating the request are completed.

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

[0100] In this embodiment of the application, after the preparatory actions before initiating the request on the Web side are completed, the Web side initiates an HTTP request to the Server side carrying a second request parameter, 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 The diagram shows a sequence diagram of a method for preventing website requests from being tampered with.

[0102] The web client can send a login request carrying initial request parameters to the server. The server performs login authentication, and upon successful authentication, the web client successfully logs in to the server. Upon successful login, the server generates a token for the web client and encrypts the initial request parameters carried in the login request to generate an rtoken, which is used by the web client for subsequent requests. After generating the web client's token and rtoken, the server can store them in a database and simultaneously return them to the web client. The web client receives the token and rtoken returned by the server. After receiving the token and rtoken, the web client can store them in a cookie used for identity verification and behavior tracking, setting it as a secure cookie to prevent the web client from tampering with the rtoken later.

[0103] Before initiating a resource request to the server, the web application needs to perform preparatory actions. Specifically, the web application first needs to construct an HTTP request carrying a second request parameter, which should include valid parameters, a request line, and request headers. After constructing the HTTP request with the second request parameter, the web application needs to determine the specific request method. This allows it to determine the location of the valid parameter `data` in the second request parameter. Specifically, if the web application determines that the HTTP request method is a GET request, the valid parameter can be assumed to be located in the URL's query field. If the web application determines that the HTTP request method is not a GET request, the valid parameter can be assumed to be located in the request body. After determining the location of the valid parameter `data`, it can then retrieve that valid parameter.

[0104] The web application converts the `data` parameter into a key-value pair, then sorts it based on the key to obtain the second intermediate parameter `_data`. The content of `_data` at this point includes {first parameter, value; second parameter, value; ...}. After obtaining the second intermediate parameter `_data`, the web application further processes it by converting it into the corresponding first object string `_str`.

[0105] After obtaining the first object string _str, the web client can further concatenate the first signature token and the generated first object string _str, recording the concatenated data as the first string. Using the token as the key, this first string is then encrypted using HmacSHA256 to generate the web client's ciphertext sign0. This ciphertext is used by the server to verify whether the second request parameter carried in the HTTP request has been tampered with during transmission. After obtaining sign0, the web client can further add sign0 to the second request parameter, sending it along with the second request parameter to the server. At this point, the web client's preparatory actions before initiating the request are complete. After these preparatory actions are completed, the web client sends an HTTP request carrying the second request parameter to the server.

[0106] The server receives an HTTP request from the web client carrying a second request parameter. Simultaneously, it checks if the web client's encrypted message `sign0` exists in the HTTP request. If the server determines that `sign0` does not exist in the HTTP request, it considers the web client's HTTP request abnormal. In this case, the server generates an error message for the abnormal request and returns it to the web client, refusing to accept the second request parameter. If the server determines that `sign0` exists in the HTTP request, it retrieves the valid parameter `data` from the second request parameter. The server converts the `data` parameter into a key-value pair and 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 point includes {first parameter, value; second parameter, value; ...}. After obtaining the first intermediate parameter `_data`, the server further processes it by converting it into a corresponding second object string `_str`. After obtaining the second object string `_str`, the server further concatenates the first signature `rtoken` with this second object string `_str`, and records the concatenated data as the second string.

[0107] After obtaining the second string, the server can use the token as the key to perform HmacSHA256 encryption on the second string to generate server-side ciphertext `sign1`. The server then compares this ciphertext `sign0` obtained from the HTTP request with the server-side ciphertext `sign1` to determine if they match. If the web-side ciphertext `sign0` and the server-side ciphertext `sign1` match, the server assumes the second request parameter carried in the HTTP request has not been tampered with during transmission and accepts the second request parameter. If the web-side ciphertext `sign0` and the server-side ciphertext `sign1` do not match, the server assumes the second request parameter carried in the HTTP request has been tampered with during transmission, blocks the HTTP request, refuses to accept the second request parameter, and displays an error message.

[0108] When the ciphertext sign0 on the web side matches the ciphertext sign1 on the server side, the server 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. The second signature rtoken will be returned 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 features real-time signature updates, irreversible encryption, and high security. It covers all HTTP request types, not just GET and POST. The parameters are sorted before encryption to avoid discrepancies between the order of parameters transmitted on the web client and received by the server due to third-party libraries or other reasons. It uses the HmacSHA256 encryption algorithm, which is more suitable for parameter verification scenarios. Furthermore, the key token is based on the user and login session, so different users and different web terminals will have different tokens, resulting in different encryption results and thus stronger system security.

[0110] In one embodiment, performance testing and analysis were performed. The system environment used for the test was configured as follows: Linux system, 16GB total memory, approximately 4.8GB remaining memory, and a 4-core 2.4GHz CPU. The test method involved taking 50 groups of tests, both using and not using the anti-tampering methods described in this technical solution, and statistically comparing the time taken for the same HTTP request before and after. The data collected is shown in Table 1.

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

[0112]

[0113]

[0114]

[0115] Based on the data in Table 1, the average HTTP request time before using the anti-tampering technology in this technical solution was 41.8364 seconds, and the average HTTP request time after using the anti-tampering technology in this technical solution was 41.8510 seconds. To more intuitively illustrate the comparison before and after, this technical solution constructs the following... Figure 4 and Figure 5 The graph shows the time taken and the average time taken for HTTP requests before and after the use of the method.

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

[0117] In one specific embodiment, based on a scenario where, after a user successfully logs into a web system, they use browser developer tools or third-party tools to resend a previously sent request with adjusted parameters, the process of using this technical solution to identify and handle dangerous behaviors is illustrated. The specific process includes:

[0118] (1) When a user logs into the system's Web client, the real-time signature is rtoken. The page operation generates a new request. Before the request occurs, the Web client sorts and concatenates the valid parameter data and the real-time signature rtoken, and then uses the token as the key to perform HmacSHA256 encryption calculation to obtain the ciphertext sign0. The original parameters are then carried with the ciphertext and the normal delivery continues.

[0119] (2) When the server receives the request, it sorts and concatenates the valid parameter data and the real-time signature rtoken, and then performs HmacSHA256 encryption calculation with the token as the key to obtain the ciphertext sign1. At this time, sign0 and sign1 are consistent, the request is normal, and then the server updates rtoken to sign1, which is denoted as _rtoken.

[0120] (3) Users can capture requests that have already been sent using browser developer tools or third-party tools.

[0121] (4) After modifying the captured request's valid parameter data to the intermediate parameter _data, the request is resent. At this time, the resent intermediate parameter _data already contains the result sign0, which is encrypted and calculated by the Web client based on the valid parameter data before modification. The Web client will not calculate the new ciphertext again.

[0122] (5) When the server receives the request to resend, it retrieves the old sign0, sorts and processes the valid parameter _data, concatenates it with the real-time signature _rtoken, and then uses the token as the 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 (currently sign1) and rtoken are different, and the values ​​of the current parameter _data and one of the original data of sign0, data, are also different, the final ciphertext _sign1 and sign0 calculated by the server are also different. Therefore, the request is identified as an abnormal request, the request is intercepted, and the dangerous behavior is blocked.

[0125] In a specific embodiment, this paper describes the process of identifying and handling dangerous behaviors using this technical solution, based on a scenario where requests are sent using fake user authentication information. The specific process is as follows:

[0126] (1) When a normal user logs into the system's Web client, a request is generated by the page operation. At this time, the real-time signature is rtoken. The request is processed by the Web client by sorting and concatenating the parameter data and the real-time signature rtoken. The token is then used as the key to perform HmacSHA256 encryption calculation to obtain the ciphertext sign0, which is then sent out normally.

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

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

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

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

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

[0132] (7) Since the values ​​of _rtoken (currently sign1) and rtoken are different, the latest ciphertext _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] This technical solution ensures that the system's web client and server uniformly sort the parameters by key name before encryption to avoid misjudgments caused by inconsistent order; it can perform encrypted calculations on valid parameters for all types of HTTP requests to avoid incomplete coverage of business scenarios; it updates the real-time signature with each request to prevent the fixed signature from being obtained and used for dangerous attacks, without increasing the amount of additional computation or algorithm complexity, and directly uses the calculation result to update the real-time signature each time the parameter is checked; and it uses the HmacSHA256 encryption algorithm and token key to enhance system security.

[0134] This application provides a server-side implementation, including:

[0135] The memory is configured to store instructions;

[0136] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned method for preventing website request tampering.

[0137] This application provides a web-based application, including:

[0138] The memory is configured to store instructions;

[0139] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned method for preventing website request tampering.

[0140] This application provides a storage medium on which a program is stored, which, when executed by a processor, implements the above-described method for preventing website requests from being tampered with.

[0141] In one embodiment, a computer device is provided, which 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, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes 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). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The database stores data related to methods for preventing tampering with website requests. The network interface A02 communicates with external terminals via a network connection. When executed by the processor A01, the computer program B02 implements a method for preventing tampering with website requests.

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

[0143] This application provides an apparatus including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of a method for preventing website requests from being tampered with.

[0144] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform method steps for initiating anti-tampering of website requests.

[0145] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0146] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0147] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work 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 The 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 operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function 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] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0151] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0152] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0153] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for preventing website requests from being tampered with, characterized in that, Applied to the server side, the method includes: Upon successful login on the web page, an access token for the web page is generated, and the first request parameter carried in the login request on the web page is encrypted and calculated to generate a first signature. Return the access token and the first signature to the web page; Receive a resource request initiated by the web page, the resource request carrying a second request parameter; Determine whether there is web-side ciphertext in the resource request, wherein the web-side ciphertext is generated by encrypting a first string using the access token as the key, and the first string is obtained by concatenating the first signature and the first object string; If it is determined that the webpage ciphertext exists in the resource request, obtain the valid parameters from the second request parameters; Generate a second object string based on the valid parameters; The first signature is concatenated with the second object string to obtain the second string; The second string is encrypted using the access token as the key to generate server-side ciphertext; If the encrypted text on the webpage matches the encrypted text 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. The step of generating the second object string based on the valid parameters includes: The data included in the effective parameters are converted into first key-value pairs, and the first key-value pairs are sorted based on the keywords to obtain the first intermediate parameters, wherein each first key-value pair consists of a keyword and a value; The first intermediate parameter is converted into the second object string.

2. The method for preventing website request tampering according to claim 1, characterized in that, The method further includes: If the encrypted message on the webpage is inconsistent with the encrypted message on the server, it is determined that the second request parameter carried in 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, The method further includes: If it is determined that the encrypted webpage does not exist in the resource request, the resource request is determined to be an abnormal request; An error message for the abnormal request is generated and returned to the web page.

4. The method for preventing website request tampering according to claim 1, characterized in that, The method further includes: After confirming that the webpage-side ciphertext matches the server-side ciphertext, the value of the first signature is replaced with the server-side ciphertext to obtain the second signature; The second signature is returned to the webpage.

5. A method for preventing website requests from being tampered with, characterized in that, When applied to a web page, the method includes: A login request is initiated to the server. The login request includes a first request parameter. If the login is successful, the server generates an access token and performs encrypted calculation on the first request parameter carried by the login request from 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 based on the valid parameters; The first signature is concatenated with the first object string to obtain the first string; The first string is encrypted using the access token as the key to generate web-side ciphertext, and the web-side ciphertext is added to the second request parameter. A resource request is sent to the server, wherein the resource request includes the second request parameters, which include the valid parameters, a request line, and a request header. Upon receiving the resource request, the server determines whether the resource request contains web-side encrypted text. The web-side encrypted text is generated by encrypting a first string using the access token as the key. The first string is obtained by concatenating the first signature and a first object string. If the server determines that the resource request contains web-side encrypted text, the server obtains the valid parameters from the second request parameters. The server generates a second object string based on the valid parameters and combines the first signature with the first object string. The second string is obtained by concatenating the second object string; the server uses the access token as a key to encrypt the second string to generate server-side ciphertext, and if the web-side ciphertext is consistent with the server-side ciphertext, the server determines that the second request parameter carried in the resource request has not been tampered with during the sending process, and receives the second request parameter; wherein, generating the second object string based on the 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 the second object string.

6. The method for preventing website request tampering according to claim 5, characterized in that, The step of generating the first object string based on valid parameters includes: Determine the request method of the resource request, and determine the position of the valid parameters in the second request parameters based on the request method; The valid parameters are obtained based on their positions. The data included in the effective parameters are converted into second key-value pairs, and the second key-value pairs are sorted based on the keywords to obtain the second intermediate parameters, wherein each key-value pair consists of a keyword and a value; The second intermediate parameter is converted into the first object string.

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

8. The method for preventing website request tampering according to claim 7, characterized in that, The method further includes: After receiving the access token and the first signature returned by the server, the first signature is stored in a cookie; Set the cookie as a secure cookie so that the webpage cannot tamper with the first signature.

9. A server-side component, characterized in that, include: The memory is configured to store instructions; A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the method for preventing website request tampering according to any one of claims 1 to 4.

10. A web-based application, characterized in that, include: The memory is configured to store instructions; A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the method for preventing website request tampering according to any one of claims 5 to 8.

11. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the method for preventing website request tampering according to any one of claims 1 to 4 or the method for preventing website request tampering according to any one of claims 5 to 8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method for website request anti-tampering as claimed in any one of claims 1 to 4 or the method for website request anti-tampering as claimed in any one of claims 5 to 8.

Images