Request processing method and device, request verification method and device, medium and program product

Abstract

The invention provides a request processing method and device, a request verification method and device, a medium and a program product. A specific embodiment of the request processing method in the application comprises the steps of performing hash encryption on content of an original request to generate a first hash value; adding the first hash value into the original request to generate a target request; and sending the target request to a server. According to the embodiment, the unique verification identifier is generated by performing hash processing on the request content at the client, and the server can quickly judge the legality of the request only by verifying the identifier.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a request processing, request verification method, device, medium and program product. Background Art

[0002] In the Internet age, servers often face challenges from various malicious requests, including but not limited to DDoS (Distributed Denial of Service) attacks, crawlers, spam sending systems, etc. These requests not only consume valuable computing resources, but may also cause a decline in service quality for legitimate users.

[0003] In view of this, server-side validation methods are widely used. Server-side validation refers to a series of checks and confirmation processes performed on the server in a network application to ensure that the data received from the client conforms to the expected format, type, and validity. This validation is critical to ensuring data integrity and security because it prevents malicious users from submitting non-compliant or dangerous data that may cause security vulnerabilities, database corruption, or application crashes. Traditional server-side validation methods are usually performed on the server, such as rule-based firewalls, intrusion detection systems (IDS), and anti-crawler strategies. Summary of the invention

[0004] Multiple aspects of the present application provide a request processing, request verification method, device, medium and program product to solve the problem that traditional server-side verification methods are inefficient when processing large-scale malicious requests.

[0005] In one aspect of the present application, a request processing method is provided, comprising: hashing the content of an original request to generate a first hash value; adding the first hash value to the original request to generate a target request; and sending the target request to a server.

[0006] Another aspect of the present application provides a request verification method, including: receiving a target request; performing the same hash encryption as that of the client on the content of the original request in the target request to generate a second hash value; comparing the second hash value with the first hash value in the target request, and generating a request verification result based on the hash value comparison result.

[0007] On the other hand, the present application provides a request processing device, including: an encryption module, configured to hash the content of an original request to generate a first hash value; an adding module, configured to add the first hash value to the original request to generate a target request; and a first sending module, configured to send the target request to a server.

[0008] Another aspect of the present application provides a request verification device, including: a receiving module, configured to receive a target request; an encryption module, configured to perform the same hash encryption as that of the client on the content of the original request in the target request, and generate a second hash value; a verification module, configured to compare the second hash value with the first hash value in the target request, and generate a request verification result based on the hash value comparison result.

[0009] Another aspect of the present application provides a request verification system, including a client and a server; the client is used to hash the content of the original request to generate a first hash value; the first hash value is added to the original request to generate a target request; the target request is sent to the server; the server is used to hash the content of the original request in the target request in the same way as the client to generate a second hash value; the second hash value is compared with the first hash value in the target request, and a request verification result is generated based on the hash value comparison result.

[0010] Another aspect of the present application provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the request processing method or request verification method as described above.

[0011] In another aspect of the present application, a computer-readable storage medium is provided, on which computer program instructions are stored. The computer program instructions can be executed by a processor to implement the request processing method or request verification method as described above.

[0012] Another aspect of the present application provides a computer program product, including a computer program, wherein the computer program implements the request processing method or request verification method as described above when executed by a processor.

[0013] The embodiment of the present application provides a request processing method and a request verification method, which generates a unique verification mark by hashing the request content on the client, and the server only needs to verify the mark to quickly determine the legitimacy of the request. Especially for large-scale malicious requests, the processing efficiency is greatly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0015] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0016] Figure 1 A processing flow chart of an embodiment of the request processing method provided by the present application;

[0017] Figure 2 A processing flow chart of another embodiment of the request processing method provided by the present application;

[0018] Figure 3 A processing flow chart of an embodiment of a request verification method provided by the present application;

[0019] Figure 4 A processing flow chart of another embodiment of the request verification method provided by the present application;

[0020] Figure 5 A schematic diagram of the web management interface provided for this application;

[0021] Figure 6 A schematic diagram of the structure of an embodiment of a request processing device provided by the present application;

[0022] Figure 7 A schematic diagram of the structure of an embodiment of a request verification device provided by the present application;

[0023] Figure 8 An interaction sequence diagram of an embodiment of a request verification system provided by the present application;

[0024] Fig. 9 A schematic diagram of the structure of a device suitable for implementing the solution in the embodiment of the present application;

[0025] The same or similar reference numerals in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0026] 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. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0027] In a typical configuration of the present application, the terminal and the equipment of the service network each include one or more processors (CPU), input / output interface, network interface and memory.

[0028] The memory may include non-permanent storage 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.

[0029] Computer readable media include permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. Information can be computer program 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 technology, read-only compact disk (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.

[0030] An embodiment of the present application provides a request processing method, which first hashes the content of an original request to generate a first hash value; then adds the first hash value to the original request to generate a target request; and finally sends the target request to a server.

[0031] An embodiment of the present application provides a request verification method, which first receives a target request; then performs the same hash encryption as that of the client on the content of the original request in the target request to generate a second hash value; finally, compares the second hash value with the first hash value in the target request, and generates a request verification result based on the hash value comparison result.

[0032] By hashing the request content on the client side to generate a unique verification mark, the server only needs to verify this mark to quickly determine the legitimacy of the request. This greatly improves processing efficiency, especially for large-scale malicious requests.

[0033] In actual scenarios, the execution subject of the above method can be a user device, or a network device, or a device formed by integrating a user device and a network device through a network, or an application running on the above device. The user device includes but is not limited to various terminal devices such as computers, mobile phones, tablets, smart watches, and bracelets. The network device includes but is not limited to network hosts, single network servers, multiple network server sets, or computer sets based on cloud computing. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing (Cloud Computing), where cloud computing is a type of distributed computing, a virtual computer composed of a group of loosely coupled computer sets.

[0034] Figure 1 The processing flow 100 of an embodiment of the request processing method provided by the present application is shown, and the method at least includes the following processing steps:

[0035] Step S101, hashing the content of the original request to generate a first hash value.

[0036] In this embodiment, the execution subject of the request processing method may perform hash encryption on the content of the original request to generate a first hash value.

[0037] Among them, the original request can be a normal request initiated by the user through the client. The original request can include a request header and a request body. The request header can include parameter information. The request body can include the content information requested by the user. Therefore, the request body of the original request is usually hashed to generate a first hash value. Hash encryption can input a message of any length into the algorithm, and obtain a hash value of a fixed length after a series of calculations. The hash value can be regarded as the fingerprint of the message, which is unique and irreversible. For the same message, the hash value obtained by performing the same hash encryption is the same. For different messages, even if the message changes slightly, it will cause a huge change in the hash value. Therefore, the hash encryption algorithm can be used in scenarios such as verifying data integrity and digital signatures.

[0038] In some embodiments, hash encryption may use more advanced encryption technology, such as HMAC (Hash-based Message Authentication Code) to further improve security.

[0039] In some embodiments, a first hash value can be generated by hashing the content of the original request using a hash function. The hash function can be a function defined using a crypto library of JavaScript. The function can accept the content of the original request as input and output a hash value. The hash function can be pre-written into the application installation package of the client, or sent from the server to the client. The hash function pre-written into the application installation package of the client can immediately perform hash processing on the request without interacting with the server. The hash function sent from the server to the client can first interact with the server to obtain the hash function, and then perform hash processing on the request.

[0040] In some embodiments, the parameters of the hash function are usually configured on the server side. The parameters of the hash function are also updated on the server side. Therefore, in order to ensure that the client always uses the latest and most secure parameters for request processing, a request to obtain the latest parameters of the hash function can be sent to the server during client initialization or a specific update process to obtain the latest parameters of the hash function. For example, when the client is started, or when it detects that the configuration needs to be updated, a request to obtain the latest parameters of the hash function is sent to the server. The server can send the latest parameters of the hash function in response to the acquisition request. The client will then use the latest parameters for subsequent request hash processing.

[0041] Step S102: Add the first hash value to the original request to generate a target request.

[0042] In this embodiment, the execution subject may add the first hash value to the original request to generate a target request, so that the target request includes both the original request and the first hash value.

[0043] In some embodiments, the target request may be generated by adding the first hash value to the original request as part of a request header or a request body of the original request.

[0044] Step S103, sending the target request to the server.

[0045] In this embodiment, the execution subject may send the target request to the server. The server may verify the first hash value in the target request to determine the legitimacy of the target request.

[0046] The embodiment of the present application provides a request processing method, which generates a unique verification mark by hashing the request content on the client side. The server only needs to verify this mark to quickly determine the legitimacy of the request. Especially for large-scale malicious requests, the processing efficiency is greatly improved. On the one hand, the resource consumption of the server in processing malicious requests is reduced, and the overall performance and stability of the system are improved. On the other hand, the lightweight verification mechanism of the client simplifies the verification process on the server side and improves the processing speed. On the other hand, the security of the system is enhanced and the risk of malicious attacks is reduced.

[0047] Figure 2 A processing flow 200 of another embodiment of a request processing method provided by the present application is shown, and the method at least includes the following processing steps:

[0048] Step S201, generating unique data.

[0049] In this embodiment, the execution subject of the request processing method can generate unique data.

[0050] Among them, the unique data is unique in a short period of time and will not be reused, thereby preventing replay attacks. Unique data may include but is not limited to: random numbers, timestamps, etc. The random number may be generated by a random number generator. The timestamp may record the time when the client performs this hash encryption.

[0051] Step S202: input the unique data and the original request into a hash function to generate a first hash value.

[0052] In this embodiment, the execution entity may input the unique data and the original request into a hash function to generate a first hash value.

[0053] Among them, the original request can be a normal request initiated by the user through the client. The original request can include a request header and a request body. The request header can include parameter information. The request body can include the content information requested by the user. Therefore, the unique data and the request body of the original request are usually hashed to generate a first hash value. Hash encryption can input a message of any length into the algorithm, and obtain a hash value of a fixed length after a series of calculations. The hash value can be regarded as the fingerprint of the message, which is unique and irreversible. For the same message, the hash value obtained by performing the same hash encryption is the same. For different messages, even if the message changes slightly, it will cause a huge change in the hash value. Therefore, the hash encryption algorithm can be used in scenarios such as verifying data integrity and digital signatures.

[0054] In some embodiments, hash encryption may use more advanced encryption techniques, such as HMAC, to further improve security.

[0055] In some embodiments, the hash function may be a function defined using a crypto library of JavaScript. The function may accept unique data and an original request as input and output a hash value. The hash function may be pre-written into the application installation package of the client or sent from the server to the client. The hash function pre-written into the application installation package of the client may immediately perform hash processing on the request without interacting with the server. The hash function sent from the server to the client may first interact with the server to obtain the hash function and then perform hash processing on the request.

[0056] In some embodiments, the parameters of the hash function are usually configured on the server side. The parameters of the hash function are also updated on the server side. Therefore, in order to ensure that the client always uses the latest and most secure parameters for request processing, a request to obtain the latest parameters of the hash function can be sent to the server during client initialization or a specific update process to obtain the latest parameters of the hash function. For example, when the client is started, or when it detects that the configuration needs to be updated, a request to obtain the latest parameters of the hash function is sent to the server. The server can send the latest parameters of the hash function in response to the acquisition request. The client will then use the latest parameters for subsequent request hash processing.

[0057] Step S203: Add the first hash value to the original request to generate a target request.

[0058] In this embodiment, the execution subject may add the first hash value to the original request to generate a target request, so that the target request includes both the original request and the first hash value.

[0059] In some embodiments, the target request may be generated by adding the first hash value to the original request as part of a request header or a request body of the original request.

[0060] Step S204, sending the target request to the server.

[0061] In this embodiment, the execution subject may send the target request to the server. In addition to verifying the first hash value in the target request, the server also needs to check the validity of the unique data to prevent replay attacks.

[0062] from Figure 2 It can be seen that Figure 1 Compared with the corresponding embodiment, the request processing method in this embodiment highlights the hash encryption step. Therefore, the scheme described in this embodiment introduces unique data into the hash function to generate a more complex first hash value. When the server verifies, in addition to verifying the first hash value, it is also necessary to check the validity of the unique data to prevent replay attacks.

[0063] Figure 3 The processing flow 300 of an embodiment of the request verification method provided by the present application is shown, and the method at least includes the following processing steps:

[0064] Step S301, receiving a target request.

[0065] In this embodiment, the execution subject of the request verification method can receive the target request.

[0066] The target request includes both the original request and the first hash value. The original request can be a normal request initiated by the user through the client, or a malicious request initiated by attacking the server. When the original request is a normal request, since the client can obtain the parameters of the hash function sent by the server, it can use the same hash function as the server to encrypt the original request into the first hash value to generate the target request. When the original request is a malicious request, the malicious request cannot obtain the parameters of the hash function sent by the server, and can only encrypt the original request into the first hash value through its own hash function to generate the target request.

[0067] In some embodiments, the parameters of the hash function are usually configured on the server side. The parameters of the hash function are also updated on the server side. Therefore, in order to ensure that the client always uses the latest and most secure parameters for request processing, a request to obtain the latest parameters of the hash function can be sent to the server during client initialization or a specific update process to obtain the latest parameters of the hash function. For example, when the client is started, or when it detects that the configuration needs to be updated, a request to obtain the latest parameters of the hash function is sent to the server. The server can send the latest parameters of the hash function in response to the acquisition request. The client will then use the latest parameters for subsequent request hash processing.

[0068] Step S302: Perform the same hash encryption as the client's on the content of the original request in the target request to generate a second hash value.

[0069] In this embodiment, the execution entity may perform the same hash encryption as the client on the content of the original request in the target request to generate a second hash value.

[0070] Among them, the original request may include a request header and a request body. The request header may include parameter information. The request body may include the content information of the request. Therefore, the request body of the original request is usually hashed and encrypted in the same way as the client to generate a second hash value. Hash encryption can input messages of any length into the algorithm, and obtain a hash value of a fixed length after a series of calculations. The hash value can be regarded as the fingerprint of the message, which is unique and irreversible. For the same message, the hash value obtained by performing the same hash encryption is the same. For different messages, even if the message changes slightly, it will cause a huge change in the hash value. Therefore, the hash encryption algorithm can be used in scenarios such as verifying data integrity and digital signatures.

[0071] In some embodiments, hash encryption may use more advanced encryption techniques, such as HMAC, to further improve security.

[0072] In some embodiments, the content of the original request is hashed and encrypted using the same hash function as the client to generate a second hash value. The hash function may be a function defined using a crypto library of JavaScript. The function can accept the content of the original request as input and output a hash value.

[0073] Step S303: compare the second hash value with the first hash value in the target request, and generate a request verification result based on the hash value comparison result.

[0074] In this embodiment, the execution entity may compare the second hash value with the first hash value in the target request, and generate a request verification result based on the hash value comparison result.

[0075] In the case where the original request is a normal request, the client and the server use the same hash function to encrypt the original request to generate a first hash value and a second hash value. Therefore, the first hash value is the same as the second hash value. In the case where the original request is a malicious request, the attack server and the server use different hash functions to encrypt the original request to generate a first hash value and a second hash value. Therefore, the first hash value is different from the second hash value.

[0076] Therefore, the second hash value is compared with the first hash value. If the second hash value is the same as the first hash value, it means that the target request is a normal request, the request verification is passed, and the server processes the request; if the second hash value is different from the first hash value, it means that the target request is a malicious request, the request verification is not passed, and the server refuses to process the request.

[0077] It should be noted that the server that processes the request can implement the request verification method and can also provide an API (Application Programming Interface) to allow third-party services to integrate this verification mechanism and expand its application scope. In addition, SDKs and documentation can be developed to facilitate developers to implement and integrate the request verification method in different platforms and languages.

[0078] The embodiment of the present application provides a request verification method, which generates a unique verification identifier by hashing the request content on the client side. The server only needs to verify this identifier to quickly determine the legitimacy of the request. Especially for large-scale malicious requests, the processing efficiency is greatly improved. On the one hand, the resource consumption of the server in processing malicious requests is reduced, and the overall performance and stability of the system are improved. On the other hand, the lightweight verification mechanism of the client simplifies the verification process on the server side and improves the processing speed. On the other hand, the security of the system is enhanced and the risk of malicious attacks is reduced.

[0079] Figure 4 A processing flow 400 of another embodiment of a request verification method provided by the present application is shown, and the method at least includes the following processing steps:

[0080] Step S401, receiving a target request.

[0081] In this embodiment, the execution subject of the request verification method can receive the target request.

[0082] The target request includes both the original request and the first hash value. The original request can be a normal request initiated by the user through the client, or a malicious request initiated by attacking the server. When the original request is a normal request, since the client can obtain the parameters of the hash function sent by the server, it can use the same hash function as the server to encrypt the original request into the first hash value to generate the target request. When the original request is a malicious request, the malicious request cannot obtain the parameters of the hash function sent by the server, and can only encrypt the original request into the first hash value through its own hash function to generate the target request.

[0083] In some embodiments, the parameters of the hash function are usually configured on the server side. The parameters of the hash function are also updated on the server side. Therefore, in order to ensure that the client always uses the latest and most secure parameters for request processing, a request to obtain the latest parameters of the hash function can be sent to the server during client initialization or a specific update process to obtain the latest parameters of the hash function. For example, when the client is started, or when it detects that the configuration needs to be updated, a request to obtain the latest parameters of the hash function is sent to the server. The server can send the latest parameters of the hash function in response to the acquisition request. The client will then use the latest parameters for subsequent request hash processing.

[0084] Step S402: Perform hash decryption corresponding to the hash encryption on the first hash value to obtain unique data and the original request.

[0085] In this embodiment, the execution entity may perform hash decryption corresponding to the hash encryption on the first hash value to obtain unique data and the original request.

[0086] Among them, the unique data is unique in a short period of time and will not be reused, thereby preventing replay attacks. Unique data may include but is not limited to: random numbers, timestamps, etc. The random number may be generated by a random number generator. The timestamp may record the time when the client performs this hash encryption.

[0087] Step S403, verifying the uniqueness data.

[0088] In this embodiment, the above-mentioned execution entity can verify the uniqueness data. If the verification passes, step S404 is executed to continue the hash value verification; if the verification fails, it means that the target request is a duplicate request, then the request verification fails, and the server refuses to process the request.

[0089] In some embodiments, when the unique data is a random number, the uniqueness verification of the random number can be performed. The random number is compared with other random numbers in other target requests received within a preset time period. If there are other random numbers that are the same as the random number, it means that it is a repeated request, and the uniqueness verification fails, and the server refuses to process the request; if there are no other random numbers that are the same as the random number, the uniqueness verification passes.

[0090] In some embodiments, when the unique data is a timestamp, synchronization verification and uniqueness verification of the timestamp can be performed. Usually, no special synchronization mechanism is required between the client and the server, and the timestamp generated by the client will be roughly synchronized with the server time. Calculate the difference between the timestamp and the current time. If the difference is not greater than the preset threshold, the synchronization verification passes, and the uniqueness verification continues; if the difference is greater than the preset threshold, the synchronization verification fails, and the server refuses to process the request. For timestamps that pass the uniqueness verification, the timestamp is compared with other timestamps in other target requests received within the preset time period; if there are other timestamps that are the same as the timestamp, it means that it is a duplicate request, then the uniqueness verification fails, and the server refuses to process the request; if there are no other timestamps that are the same as the timestamp, the uniqueness verification passes.

[0091] Step S404: In response to determining that the verification is successful, the content of the original request is hashed to generate a second hash value.

[0092] In this embodiment, when the uniqueness data verification is passed, the execution entity may perform hash encryption on the content of the original request to generate a second hash value.

[0093] Among them, the original request may include a request header and a request body. The request header may include parameter information. The request body may include the content information of the request. Therefore, the request body of the original request is usually hashed and encrypted in the same way as the client to generate a second hash value. Hash encryption can input messages of any length into the algorithm, and obtain a hash value of a fixed length after a series of calculations. The hash value can be regarded as the fingerprint of the message, which is unique and irreversible. For the same message, the hash value obtained by performing the same hash encryption is the same. For different messages, even if the message changes slightly, it will cause a huge change in the hash value. Therefore, the hash encryption algorithm can be used in scenarios such as verifying data integrity and digital signatures.

[0094] In some embodiments, hash encryption may use more advanced encryption techniques, such as HMAC, to further improve security.

[0095] In some embodiments, the content of the original request is hashed and encrypted using the same hash function as the client to generate a second hash value. The hash function may be a function defined using a crypto library of JavaScript. The function can accept the content of the original request as input and output a hash value.

[0096] Step S405: compare the second hash value with the first hash value in the target request, and generate a request verification result based on the hash value comparison result.

[0097] In this embodiment, the execution entity may compare the second hash value with the first hash value in the target request, and generate a request verification result based on the hash value comparison result.

[0098] In the case where the original request is a normal request, the client and the server use the same hash function to encrypt the original request to generate a first hash value and a second hash value. Therefore, the first hash value is the same as the second hash value. In the case where the original request is a malicious request, the attack server and the server use different hash functions to encrypt the original request to generate a first hash value and a second hash value. Therefore, the first hash value is different from the second hash value.

[0099] Therefore, the second hash value is compared with the first hash value. If the second hash value is the same as the first hash value, it means that the target request is a normal request, the request verification is passed, and the server processes the request; if the second hash value is different from the first hash value, it means that the target request is a malicious request, the request verification is not passed, and the server refuses to process the request.

[0100] It should be noted that the server that handles the request can implement the request verification method, or provide an API to allow third-party services to integrate this verification mechanism and expand its application scope. In addition, SDKs and documentation can be developed to facilitate developers to implement and integrate the request verification method in different platforms and languages.

[0101] from Figure 4 It can be seen that Figure 3 Compared with the corresponding embodiment, the request verification method in this embodiment adds a unique data verification step. Therefore, when the server verifies the solution described in this embodiment, in addition to verifying the first hash value, it is also necessary to check the validity of the unique data to prevent replay attacks.

[0102] Figure 5 A schematic diagram of the web management interface provided by the present application is shown. The web management interface may include a hash configuration button and a log viewing button. The administrator clicks the hash configuration button to configure the parameters of the hash function, such as the key, the timestamp validity period, etc. The administrator clicks the log viewing button to monitor requests that fail verification and analyze possible security threats.

[0103] Figure 6 A schematic diagram of the structure of an embodiment of a request processing device provided by the present application is shown. Figure 1 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0104] like Figure 6As shown, the request processing device 600 of this embodiment may include: an encryption module 601, an adding module 602 and a first sending module 603. The encryption module 601 is configured to perform hash encryption on the content of the original request to generate a first hash value; the adding module 602 is configured to add the first hash value to the original request to generate a target request; and the sending module 603 is configured to send the target request to the server.

[0105] In this embodiment, in the request processing device 600, the specific processing of the encryption module 601, the adding module 602 and the sending module 603 and the technical effects thereof can be referred to in Figure 1 The relevant descriptions of steps S101 to S103 in the corresponding embodiment are not repeated here.

[0106] In some optional implementations of this embodiment, the encryption module 601 is further configured to: hash the request body of the original request to generate a first hash value; the adding module 602 is further configured to: add the first hash value as a part of the request header or request body of the original request to the original request to generate a target request.

[0107] In some optional implementations of this embodiment, the encryption module 601 is further configured to: use a hash function to hash the content of the original request to generate a first hash value, wherein the hash function is pre-written into the application installation package of the client, or sent from the server to the client.

[0108] In some optional implementations of this embodiment, the encryption module 601 is further configured to: generate unique data; input the unique data and the original request into a hash function to generate a first hash value.

[0109] In some optional implementations of this embodiment, the unique data is a random number and / or a timestamp, wherein the timestamp records the time when the client performs this hash encryption.

[0110] In some optional implementations of this embodiment, the request processing device 600 further includes a second sending module configured to send a request for obtaining the latest parameters of the hash function to the server.

[0111] Figure 7 A schematic diagram of the structure of an embodiment of a request verification device provided by the present application is shown. Figure 3 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0112] like Figure 7As shown, the request verification device 700 of this embodiment may include: a receiving module 701, an encryption module 702 and a verification module 703. The receiving module 701 is configured to receive a target request; the encryption module 702 is configured to perform the same hash encryption as the client on the content of the original request in the target request to generate a second hash value; the verification module 703 is configured to compare the second hash value with the first hash value in the target request, and generate a request verification result based on the hash value comparison result.

[0113] In this embodiment, in the request verification device 700, the specific processing of the receiving module 701, the encryption module 702 and the verification module 703 and the technical effects thereof can be referred to in Figure 3 The relevant descriptions of steps S301 to S303 in the corresponding embodiment are not repeated here.

[0114] In some optional implementations of this embodiment, the encryption module 702 is further configured to: use the same hash function as the client to hash the content of the original request to generate a second hash value.

[0115] In some optional implementations of this embodiment, the encryption module 702 includes: a decryption submodule, configured to perform hash decryption corresponding to the hash encryption on the first hash value to obtain unique data and the original request; a verification submodule, configured to verify the unique data; and an encryption submodule, configured to perform hash encryption on the content of the original request in response to determining that the verification is successful to generate a second hash value.

[0116] In some optional implementations of this embodiment, the uniqueness data includes a random number, and the verification submodule is further configured to: compare the random number with other random numbers in other target requests received within a preset time period; in response to determining that there are other random numbers that are identical to the random number, the verification fails; in response to determining that there are no other random numbers that are identical to the random number, the verification passes.

[0117] In some optional implementations of this embodiment, the uniqueness data includes a timestamp, and the verification submodule is further configured to: calculate the difference between the timestamp and the current time; in response to determining that the difference is not greater than a preset threshold, compare the timestamp with other timestamps in other target requests received within a preset time period; in response to determining that there is no other timestamp identical to the timestamp, the verification is passed. In response to determining that the difference is greater than the preset threshold, or there is another timestamp identical to the timestamp, the verification is not passed.

[0118] In some optional implementations of this embodiment, the request verification device 700 further includes a sending module configured to send the latest parameters of the hash function to the client in response to receiving a request for obtaining the latest parameters of the hash function sent by the client.

[0119] Figure 8 The interactive sequence 800 of an embodiment of the request verification system provided by the present application is shown. The system includes a client and a server, and performs at least the following interactive steps:

[0120] Step S801: The client performs hash encryption on the content of the original request to generate a first hash value, and adds the first hash value to the original request to generate a target request.

[0121] Step S802: The client sends a target request to the server.

[0122] In this embodiment, the specific operations of steps S801-S802 can be referred to Figure 1 The relevant descriptions of steps S101 to S103 in the corresponding embodiment are not repeated here.

[0123] Step S803, the server performs the same hash encryption as the client on the content of the original request in the target request, generates a second hash value, compares the second hash value with the first hash value in the target request, and generates a request verification result based on the hash value comparison result.

[0124] In this embodiment, the specific operation of step S803 can be referred to Figure 3 The relevant descriptions of steps S302-S303 in the corresponding embodiment are not repeated here.

[0125] Based on the same inventive concept, an electronic device is also provided in an embodiment of the present application, and the method corresponding to the electronic device may be the request processing method or request verification method in the aforementioned embodiment, and its principle of solving the problem is similar to that of the method. The electronic device provided in an embodiment of the present application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the methods and / or technical solutions of the aforementioned multiple embodiments of the present application.

[0126] The electronic device may be a user device, or a device formed by integrating a user device and a network device through a network, or may be an application running on the above device. The user device includes but is not limited to various terminal devices such as computers, mobile phones, tablet computers, smart watches, and bracelets. The network device includes but is not limited to network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, which can be used to implement some processing functions when setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, where cloud computing is a type of distributed computing, a virtual computer composed of a group of loosely coupled computer sets.

[0127] Fig. 9 The structure of a device suitable for implementing the method and / or technical solution in the embodiment of the present application is shown, and the device 900 includes a central processing unit (CPU, Central Processing Unit) 901, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM, Read Only Memory) 902 or the program loaded from the storage part 908 to the random access memory (RAM, Random Access Memory) 903. In RAM 903, various programs and data required for system operation are also stored. CPU 901, ROM 902 and RAM 903 are connected to each other through a bus 904. An input / output (I / O, Input / Output) interface 905 is also connected to the bus 904.

[0128] The following components are connected to the I / O interface 905: an input section 906 including a keyboard, a mouse, a touch screen, a microphone, an infrared sensor, etc.; an output section 907 including a cathode ray tube (CRT), a liquid crystal display (LCD), an LED display, an OLED display, etc., and a speaker, etc.; a storage section 908 including one or more computer-readable media such as a hard disk, an optical disk, a magnetic disk, a semiconductor memory, etc.; and a communication section 909 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 909 performs communication processing via a network such as the Internet.

[0129] In particular, the methods and / or embodiments in the embodiments of the present application may be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 901, the above functions defined in the method of the present application are executed.

[0130] Another embodiment of the present application further provides a computer-readable storage medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of the present application described above.

[0131] Specifically, the present embodiment may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device, or device.

[0132] Computer readable signal media may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer readable program code. Such propagated data signals may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than a computer readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0133] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0134] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0135] The flow chart or block diagram in the accompanying drawings shows the possible architecture, function and operation of the equipment, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0136] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0137] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or page components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0138] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0139] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0140] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store program codes.

[0141] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

[0142] In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in a device claim can also be implemented by one unit or device through software or hardware. The words first, second, etc. are used to indicate names, and do not indicate any particular order.

Claims

1. A request processing method, comprising: Hash the content of the original request to generate a first hash value; Adding the first hash value to the original request to generate a target request; The target request is sent to a server.

2. The method according to claim 1, wherein: The step of performing hash encryption on the content of the original request to generate a first hash value includes: Hash-encrypting the request body of the original request to generate the first hash value; and The step of adding the first hash value to the original request to generate a target request includes: The first hash value is added to the original request as a part of the request header or request body of the original request to generate the target request.

3. The method according to claim 1, wherein: The step of performing hash encryption on the content of the original request to generate a first hash value includes: The content of the original request is hashed and encrypted using a hash function to generate the first hash value, wherein the hash function is pre-written into the application installation package of the client or is sent from the server to the client.

4. The method according to claim 3, wherein: The step of using a hash function to hash the content of the original request to generate the first hash value includes: Generate unique data; The unique data and the original request are input into the hash function to generate the first hash value.

5. The method according to claim 4, wherein: The unique data is a random number and / or a timestamp, wherein the timestamp records the time when the client performs this hash encryption.

6. The method according to any one of claims 3 to 5, wherein: The method further comprises: A request for obtaining the latest parameters of the hash function is sent to the server.

7. A request verification method, comprising: receiving a target request; Performing the same hash encryption as the client on the content of the original request in the target request to generate a second hash value; The second hash value is compared with the first hash value in the target request, and a request verification result is generated based on the hash value comparison result.

8. The method according to claim 7, wherein: The step of performing the same hash encryption as that of the client on the content of the original request in the target request to generate a second hash value includes: The content of the original request is hashed and encrypted using the same hash function as that of the client to generate the second hash value.

9. The method according to claim 7, wherein: The step of performing the same hash encryption as that of the client on the content of the original request in the target request to generate a second hash value includes: Performing hash decryption corresponding to the hash encryption on the first hash value to obtain unique data and the original request; Verifying the unique data; In response to determining that the verification is successful, the content of the original request is hashed to generate the second hash value.

10. The method according to claim 9, wherein: The unique data includes a random number, and The verifying of the unique data includes: comparing the random number with other random numbers in other target requests received within a preset time period; In response to determining that there is another random number that is the same as the random number, the verification fails; In response to determining that there is no other random number that is the same as the random number, the verification is successful.

11. The method according to claim 9 or 10, wherein: The unique data includes a timestamp, and The verifying of the unique data includes: Calculate the difference between the timestamp and the current time; In response to determining that the difference is not greater than a preset threshold, comparing the timestamp with other timestamps in other target requests received within a preset time period; In response to determining that there is no other timestamp that is the same as the timestamp, the verification passes. In response to determining that the difference is greater than the preset threshold, or there is another timestamp that is the same as the timestamp, the verification fails.

12. The method according to claim 8, wherein: The method further comprises: In response to receiving a request for obtaining the latest parameters of the hash function sent by the client, the latest parameters of the hash function are sent to the client.

13. A request processing device, comprising: An encryption module, configured to perform hash encryption on the content of the original request to generate a first hash value; An adding module, configured to add the first hash value to the original request to generate a target request; The first sending module is configured to send the target request to the server.

14. A request verification device, comprising: A receiving module configured to receive a target request; An encryption module is configured to perform the same hash encryption as the client on the content of the original request in the target request to generate a second hash value; The verification module is configured to compare the second hash value with the first hash value in the target request, and generate a request verification result based on the hash value comparison result.

15. A request verification system, comprising a client and a server; The client is used to perform hash encryption on the content of the original request to generate a first hash value; Adding the first hash value to the original request to generate a target request; sending the target request to the server; The server is configured to perform the same hash encryption as that of the client on the content of the original request in the target request to generate a second hash value; The second hash value is compared with the first hash value in the target request, and a request verification result is generated based on the hash value comparison result.

16. An electronic device, comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 12.

17. A computer readable medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the method according to any one of claims 1 to 12.

18. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 12 is implemented.

Images