A method, device and medium for mimetic decision of HTTP service side

Abstract

The application discloses a paratransgenesis decision method and device on the HTTP service side, equipment and medium, relates to the paratransgenesis defense technical field, and includes: obtaining the request message based on HTTP protocol or HTTPS protocol sent by paratransgenesis executor, obtaining request message body by using proxy server to analyze request message, and extracting paratransgenesis identifier from request header;Request message body is stored in the decision maker based on paratransgenesis identifier, and when the request number of request message body with the same paratransgenesis identifier exceeds the preset threshold, the decision maker is used to make paratransgenesis decision on request message body;If the decision passes, the request message is forwarded to the back-end service, and the response message sent by the back-end service is replied to the paratransgenesis executor;If the decision does not pass, the paratransgenesis executor is replied to the decision failure status code, and the corresponding paratransgenesis executor information is reported to the feedback control dispatcher by using the decision maker to complete the cleaning of the paratransgenesis executor. The paratransgenesis decision efficiency is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of mimicry defense technology, and in particular to a mimicry adjudication method, apparatus, device, and medium for HTTP service side. Background Technology

[0002] The Dynamic Heterogeneous Redundancy (DHR) architecture, based on mimicry defense technology, aims to solve cyberspace security problems by enhancing the dynamism, uncertainty, heterogeneity, and non-persistence of application software systems to achieve intrinsic system security.

[0003] The existing mimicry defense DHR architecture diagram is as follows: Figure 1 As shown, the mimicry right bracket is a crucial component of the DHR architecture. As an output adjudicator and proxy component for user-executive applications, it can adjudicate data packets from multiple application layer protocols, such as HTTP, MySQL, and Redis, blocking tampered data and reporting it to feedback control to achieve dynamic cleanup of the execution body. It then forwards adjudicated data packets to backend services, thus achieving mimicry defense. However, the mimicry right bracket currently suffers from low adjudication efficiency. Furthermore, the HTTPS protocol, by adding a Transport Layer Security Protocol (TLS) on top of the HTTP protocol, increases the difficulty of parsing protocol messages for the mimicry right bracket.

[0004] In summary, how to conduct mimicry adjudication on the HTTP business side and improve the efficiency of mimicry adjudication are problems that need to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a mimicry adjudication method, apparatus, device, and medium for the HTTP service side, capable of performing mimicry adjudication on the HTTP service side and improving the efficiency of mimicry adjudication. The specific solution is as follows:

[0006] Firstly, this application discloses a mimicry adjudication method for the HTTP business side, applied to an HTTP mimicry proxy, wherein the HTTP mimicry proxy includes a proxy server, an adjudicator, and a proxy client, and the method includes:

[0007] The system obtains request messages sent by the mimicry executor based on the HTTP or HTTPS protocol, and uses a proxy server to parse the request messages to obtain the corresponding request message body, and extracts the mimicry identifier from the request header of the request message body.

[0008] The request message body is classified and stored in the arbiter based on the mimicry identifier, and the number of request message bodies with the same mimicry identifier in the arbiter is determined so that when the number of requests exceeds a preset threshold, the arbiter can be used to make a mimicry ruling on the request message body.

[0009] If the ruling is successful, the request message will be forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the response message will be sent back to the mimic executor through the proxy server.

[0010] If the ruling fails, the proxy server will send a ruling failure status code back to the mimic executor, and the ruling device will report the corresponding mimic executor information to the feedback control scheduler so that the feedback control scheduler can clean up the mimic executor.

[0011] Optionally, the step of using a proxy server to parse the request message to obtain the corresponding request message body includes:

[0012] If the request message is based on the HTTPS protocol, the request message is decrypted by the proxy server based on the pre-generated proxy server certificate to obtain the decrypted message.

[0013] The proxy server parses the decrypted message to obtain the corresponding request message body.

[0014] Optionally, before using the adjudicator to perform a pseudo-adjudication on the request message body, the method further includes:

[0015] Determine the pre-configured random number matching list in the arbitrator, and query whether there is a random number in the request message body that matches the random number matching list;

[0016] If it exists, the random number in the request message body is removed to output a request message body that does not include the random number.

[0017] Optionally, the step of using the adjudicator to perform a pseudo-adjudication on the request message body includes:

[0018] The system determines the first request message body sent by the first mimicking executor and the second request message body sent by the second mimicking executor, and then uses the adjudicator to make a mimicking adjudication on the first request message body and the second request message body; wherein, the first request message body is stored in the adjudicator before the second request message body;

[0019] Accordingly, if the ruling passes, the request message is forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the proxy server replies to the mimic executor with the response message, including:

[0020] If the ruling is successful, the request message corresponding to the first request message body will be forwarded to the backend service through the proxy client, and after obtaining the response message from the backend service, the response message will be replied to the first mimic executor and the second mimic executor through the proxy server.

[0021] After obtaining the third request message body sent by the third mimicking executor, the adjudicator is used to make a mimicking adjudication on the first request message body and the third request message body;

[0022] If the ruling passes, the proxy server replies with the response message to the third mimic executor. If the ruling fails, the proxy server replies with the ruling failure status code to the third mimic executor, and the adjudicator reports the corresponding third mimic executor information to the feedback control scheduler so that the feedback control scheduler can clean the third mimic executor.

[0023] Optionally, after performing a mimicry adjudication on the first request message body and the second request message body using the adjudicator, the method further includes:

[0024] If the adjudication fails, after receiving the third request message body sent by the third mimicking executor, the adjudicator will use the adjudicator to perform mimicking adjudication on the third request message body and the first request message body and the second request message body respectively.

[0025] If both decisions pass, the remaining target mimicking executor is determined to fail. Then, the proxy server sends a failure status code to the target mimicking executor and the arbiter reports the corresponding target mimicking executor information to the feedback control scheduler so that the feedback control scheduler can clean the target mimicking executor.

[0026] Optionally, after using the adjudicator to perform mimicry adjudication on the third request message body and the first request message body and the second request message body respectively, the method further includes:

[0027] If the third request message body fails to resolve the conflict with the first request message body, and the third request message body fails to resolve the conflict with the second request message body, then the proxy server will send a failure status code to the first mimic executor, the second mimic executor, and the third mimic executor.

[0028] The adjudicator reports the corresponding mimicry executor information to the feedback control scheduler so that the feedback control scheduler can clean up the first mimicry executor, the second mimicry executor, and the third mimicry executor.

[0029] Optionally, the mimicry adjudication method on the HTTP service side further includes:

[0030] After the arbitrator receives the first request message body, it starts a timing operation.

[0031] If the second request message body and the third request message body are not obtained within the timeout period specified in the timing operation, the decision timeout status code is replied to the first mimic executor.

[0032] If the third request message body is not obtained within the timeout period specified in the timing operation, and the first request message body and the second request message body fail to pass the adjudication, then the adjudication failure status code is replied to the first mimic executor and the second mimic executor.

[0033] If the number of current mimicking executors does not reach the preset number within the timeout period specified in the timing operation, a timeout information is reported to the feedback control scheduler.

[0034] Optionally, the process of extracting the mimicry identifier from the request header of the request message body further includes:

[0035] If the request header of the request message body does not contain a mimicry identifier, the request message is directly sent to the proxy client so that the proxy client can forward the request message to the backend service.

[0036] Secondly, this application discloses a mimicry adjudication device for the HTTP service side, applied to an HTTP mimicry proxy. The HTTP mimicry proxy includes a proxy server, an adjudicator, and a proxy client. The device includes:

[0037] The message processing module is used to obtain request messages sent by the mimicry executor based on the HTTP or HTTPS protocol, and to use the proxy server to parse the request messages to obtain the corresponding request message body, and to extract the mimicry identifier from the request header of the request message body.

[0038] The mimicry adjudication module is used to classify and store the request message body in the adjudicator based on the mimicry identifier, and to determine the number of request message bodies with the same mimicry identifier in the adjudicator, so that when the number of requests exceeds a preset threshold, the adjudicator can be used to make mimicry adjudication on the request message body.

[0039] The response module is used to forward the request message to the backend service through the proxy client if the ruling is passed, and after obtaining the response message from the backend service, reply to the mimic executor through the proxy server.

[0040] The execution body cleaning module is used to reply with an adjudication failure status code to the mimic execution body through the proxy server if the adjudication fails, and to report the corresponding mimic execution body information to the feedback control scheduler through the adjudicator, so that the feedback control scheduler can clean the mimic execution body.

[0041] Thirdly, this application discloses an electronic device, including:

[0042] Memory, used to store computer programs;

[0043] A processor is configured to execute the computer program to implement the steps of the aforementioned disclosed mimicry adjudication method for the HTTP service side.

[0044] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed mimicry adjudication method for the HTTP service side.

[0045] As can be seen, the HTTP mimicry proxy in this application obtains request messages based on HTTP or HTTPS protocols sent by the mimicry executor, parses the request messages using a proxy server to obtain the corresponding request message body, and extracts a mimicry identifier from the request header of the request message body. The request message body is categorized and stored in the arbitrator based on the mimicry identifier, and the number of requests with the same mimicry identifier in the arbitrator is determined. When the number of requests exceeds a preset threshold, the arbitrator performs mimicry adjudication on the request message body. If the adjudication passes, the request message is forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the proxy server replies to the mimicry executor with the response message. If the adjudication fails, the proxy server replies to the mimicry executor with an adjudication failure status code, and the arbitrator reports the corresponding mimicry executor information to the feedback control scheduler so that the feedback control scheduler can clean up the mimicry executor. Therefore, after obtaining the request message sent by the mimicry executor based on the HTTP or HTTPS protocol, this application uses a proxy server to parse the request message and extract the mimicry identifier in the request header. In other words, this application can support the parsing of request messages based on the HTTP or HTTPS protocol, thereby performing mimicry adjudication on the HTTP business side. Furthermore, after obtaining the mimicry identifier, the application stores the request message bodies from each mimicry executor in the adjudicator according to the mimicry identifier, thereby improving the efficiency of mimicry adjudication to cope with high concurrency and multi-threaded scenarios. In addition, when the mimicry adjudication fails, the information of the failed mimicry executor is reported to the feedback control scheduler so that the feedback control scheduler can complete the cleaning of the mimicry executor, thereby improving the security and reliability of mimicry defense. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0047] Figure 1 This application discloses a diagram of an existing mimicry defense DHR architecture.

[0048] Figure 2 This application discloses a flowchart of a mimicry adjudication method for the HTTP service side.

[0049] Figure 3 This is a schematic diagram of the architecture of an HTTP mimicry proxy disclosed in this application;

[0050] Figure 4 This application discloses a specific mimicry adjudication flowchart;

[0051] Figure 5 This is a schematic diagram of the structure of a mimicry adjudication device for the HTTP service side disclosed in this application;

[0052] Figure 6 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0054] The mimicry right bracket is a crucial component of the DHR architecture. As an output adjudicator and proxy component for user-executive applications, it can adjudicate data packets from multiple application layer protocols, such as HTTP, MySQL, and Redis, blocking tampered data and reporting it to feedback control for dynamic cleanup of the execution body. It then forwards adjudicated data packets to backend services, thus achieving mimicry defense. However, current mimicry right bracket adjudication remains inefficient. Furthermore, the HTTPS protocol, with its added security transport layer protocol on top of HTTP, increases the difficulty of parsing protocol messages for mimicry right brackets. Therefore, this application discloses a mimicry adjudication method, apparatus, device, and medium for HTTP services, capable of performing mimicry adjudication on the HTTP service side and improving its efficiency.

[0055] See Figure 2 As shown in the figure, this application discloses a mimicry adjudication method on the HTTP service side, applied to an HTTP mimicry proxy. The HTTP mimicry proxy includes a proxy server, an adjudicator, and a proxy client. The method includes:

[0056] Step S11: Obtain the request message sent by the mimicry executor based on the HTTP or HTTPS protocol, and use the proxy server to parse the request message to obtain the corresponding request message body, and extract the mimicry identifier from the request header of the request message body.

[0057] In this embodiment, the mimicking executor sends a request message based on the HTTP or HTTPS protocol to the proxy server. The proxy server uses its internal protocol parsing module to parse the request message, converting the request message data into a request message body, thereby obtaining the request header, message body, and request method. HTTP requests include eight request methods: GET, POST, HEAD, PUT, DELETE, CONNECT, OPTIONS, and TRACE. Then, the mimicking identifier is extracted from the parsed request header. In a specific implementation, this is achieved by extracting the Sw8-Correlation field from the request header, decoding it using base64, and obtaining the mimicking identifier (i.e., traceid). It should be noted that after a user accesses the HTTP mimicking proxy, the resulting traffic is equally distributed among several heterogeneous mimicking executors. Each mimicking executor outputs traffic to the HTTP mimicking proxy's listening port. In this way, the HTTP mimicking proxy will successively receive request messages sent by each mimicking executor. In this embodiment, the number of mimicking executors is at least three.

[0058] Furthermore, it should be noted that the process of using a proxy server to parse the request message to obtain the corresponding request message body includes: if the request message is based on the HTTPS protocol, then the proxy server decrypts the request message based on a pre-generated proxy server certificate to obtain a decrypted message; and the proxy server parses the decrypted message to obtain the corresponding request message body. It is understood that HTTP transmits in plaintext, while HTTPS transmits in encrypted form. Therefore, if the mimicry execution entity sends a request message based on the HTTPS protocol, the request message must also be decrypted. Specifically, the proxy server has an internal certificate management module. This module generates a proxy server certificate based on a pre-configured CA certificate and private key, then uses the RSA asymmetric encryption algorithm to decrypt the request message using the proxy server certificate to obtain a decrypted message, and finally parses the decrypted message to obtain the corresponding request message body. In other words, if it is an HTTPS request message, the protocol parsing module in the proxy server will combine the certificate provided by the certificate management module to first convert the HTTPS request message into a plaintext data structure, and then further convert it into a request message body.

[0059] In a specific implementation, the process of extracting the mimicry identifier from the request header of the request message body further includes: if the request header of the request message body does not contain a mimicry identifier, the request message is directly sent to the proxy client so that the proxy client can forward the request message to the backend service. It can be understood that if the request header of the request message body does not contain a mimicry identifier, the proxy server will directly pass the request message to the proxy client without performing a mimicry determination. That is, for request messages without a mimicry identifier, the proxy server will skip the determination step and directly pass the request message to the proxy client so that the proxy client can forward the request message to the backend service, completing the proxying of non-mimicry requests.

[0060] Step S12: The request message body is classified and stored in the arbiter based on the mimicry identifier, and the number of request message bodies with the same mimicry identifier in the arbiter is determined so that when the number of requests exceeds a preset threshold, the arbiter is used to make a mimicry ruling on the request message body.

[0061] In this embodiment, the proxy server sends data containing mimicry identifiers in the request header to the arbitrator. The arbitrator has a data caching module that stores request message bodies according to mimicry identifiers for aggregation and adjudication of requests from multiple execution bodies. Furthermore, when the number of request message bodies with the same mimicry identifier exceeds a preset threshold, the arbitrator will perform mimicry adjudication on the request message bodies. The preset threshold can be set to 2.

[0062] It should be noted that before performing the mimicry adjudication on the request message body using the adjudicator, the process further includes: determining a pre-configured random number matching list in the adjudicator, and querying whether there is a random number in the request message body that matches the random number matching list; if so, eliminating the random number in the request message body to output a request message body excluding the random number. That is, random number elimination needs to be performed on the request message body before mimicry adjudication to avoid random number interference with the adjudication result, thereby improving the accuracy of mimicry adjudication. In this embodiment, the adjudicator has a pre-configured random number matching list. By querying whether there is a random number in the request message body that matches the random number matching list, if so, the corresponding random number is eliminated to obtain a request message body after random number elimination. The random number matching list includes, but is not limited to, regular expressions for random number segments. Specifically, the rule is {URL path 1: [random number regular expression 1, random number regular expression 2, random number regular expression 3...], URL path 2: [random number regular expression 4, random number regular expression 5],...}. If the URL of the request message body contains the above-mentioned random number regular expressions, the random numbers in the request message body will be eliminated, and a request message body without random numbers will be output, which will then be used for mimicry adjudication. It should be noted that the process of comparing the consistency of the request message bodies of each mimicry executor after they arrive at the adjudicator is called mimicry adjudication. In a specific implementation, after the random numbers are eliminated, the request message body of the executor can be converted into an MD5 value. The consistency of the MD5 values ​​is compared pairwise to determine whether the adjudication passes.

[0063] Step S13: If the decision is successful, the request message is forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the response message is replied to the mimic executor through the proxy server.

[0064] In this embodiment, after the mimicry adjudication is completed, if the adjudication is successful, the proxy client will forward the request message to the backend service, and then send the response message from the backend service back to the mimicry executor through the proxy server, ultimately feeding it back to the user to complete the request event invocation process. It should be noted that if the backend service is an HTTPS service, the backend service will provide its CA certificate and private key to the HTTP mimicry proxy in advance, so that the certificate management module of the proxy server can generate a proxy client certificate based on the same CA certificate and private key as the backend service, and then forward the request message to the backend service using the proxy client certificate.

[0065] Step S14: If the adjudication fails, the proxy server replies with an adjudication failure status code to the mimic executor, and the adjudicator reports the corresponding mimic executor information to the feedback control scheduler so that the feedback control scheduler can clean the mimic executor.

[0066] In this embodiment, if the adjudication fails, the proxy server directly replies with an adjudication failure status code to the mimicking executor and uses the adjudicator to report the corresponding mimicking executor information to the feedback control scheduler via a message queue. This allows the feedback control scheduler to perform dynamic cleanup of the mimicking executor. The reported mimicking executor information may include, but is not limited to, the executor's IP address, request URL, and failure type information. In this embodiment, the adjudication failure status code is specifically 451. The aforementioned message queue method allows for rapid, real-time feedback of detailed information about the tampered executor to the feedback control scheduler for dynamic cleanup, improving the security and reliability of the mimicry defense system.

[0067] Figure 3 This is a schematic diagram of the architecture of an HTTP mimicry proxy disclosed in an embodiment of this application. The HTTP mimicry proxy includes a proxy server, an adjudicator, and a proxy client. The proxy server is mainly responsible for protocol parsing and certificate management, the adjudicator is mainly responsible for data caching, random number processing, feedback reporting, and mimicry adjudication, and the proxy client is responsible for forwarding packets to the backend service. It can be understood that the HTTP mimicry proxy in the DHR architecture can be referred to as the HTTP mimicry right bracket, which combines the functions of an adjudicator and an HTTP / HTTPS output proxy, and can be widely used in containerized and non-containerized scenarios, possessing good adaptability and compatibility. Furthermore, this invention implements HTTP / HTTPS proxy by separating the proxy server and the proxy client, and supports HTTP and HTTPS protocol packet parsing, effectively improving the efficiency of mimicry right bracket adjudication and proxying.

[0068] As can be seen, the HTTP mimicry proxy in this application obtains request messages based on HTTP or HTTPS protocols sent by the mimicry executor, parses the request messages using a proxy server to obtain the corresponding request message body, and extracts a mimicry identifier from the request header of the request message body. The request message body is categorized and stored in the arbitrator based on the mimicry identifier, and the number of requests with the same mimicry identifier in the arbitrator is determined. When the number of requests exceeds a preset threshold, the arbitrator performs mimicry adjudication on the request message body. If the adjudication passes, the request message is forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the proxy server replies to the mimicry executor with the response message. If the adjudication fails, the proxy server replies to the mimicry executor with an adjudication failure status code, and the arbitrator reports the corresponding mimicry executor information to the feedback control scheduler so that the feedback control scheduler can clean up the mimicry executor. Therefore, after obtaining the request message sent by the mimicry executor based on the HTTP or HTTPS protocol, this application uses a proxy server to parse the request message and extract the mimicry identifier in the request header. In other words, this application can support the parsing of request messages based on the HTTP or HTTPS protocol, thereby performing mimicry adjudication on the HTTP business side. Furthermore, after obtaining the mimicry identifier, the application stores the request message bodies from each mimicry executor in the adjudicator according to the mimicry identifier, thereby improving the efficiency of mimicry adjudication to cope with high concurrency and multi-threaded scenarios. In addition, when the mimicry adjudication fails, the information of the failed mimicry executor is reported to the feedback control scheduler so that the feedback control scheduler can complete the cleaning of the mimicry executor, thereby improving the security and reliability of mimicry defense.

[0069] See Figure 4 As shown in the illustration, this application embodiment uses three mimicking executors as an example to provide specific steps for mimicking the request message body using an adjudicator. Specifically, after a user accesses the HTTP mimicking proxy, the generated traffic is equally distributed to the three mimicking executors. Each mimicking executor outputs traffic to the HTTP mimicking proxy's listening port. In this way, the HTTP mimicking proxy successively obtains the request packets sent by the three mimicking executors, and then uses the proxy server to parse the obtained request packets to obtain their respective corresponding request message bodies. The three request message bodies have the same mimicking identifier. The adjudicator adopts a first-come, first-served strategy. After obtaining two of the request message bodies, it begins mimicking the request body, with the specific steps as follows:

[0070] Step S21: Determine the first request message body sent by the first mimicking executor and the second request message body sent by the second mimicking executor, and then use the adjudicator to make a mimicking adjudication on the first request message body and the second request message body; wherein, the first request message body is stored in the adjudicator before the second request message body.

[0071] In this embodiment, the arbitrator first determines the two arriving request message bodies: the first request message body sent by the first mimicking executor and the second request message body sent by the second mimicking executor. The first request message body is stored in the arbitrator before the second request message body; that is, the arbitrator receives the first request message body sent by the first mimicking executor beforehand. Then, the arbitrator performs a first mimicking decision on the first and second request message bodies through its internal mimicking decision module.

[0072] Step S22: If the decision is successful, the request message corresponding to the first request message body is forwarded to the backend service through the proxy client, and after obtaining the response message from the backend service, the response message is replied to the first mimic executor and the second mimic executor through the proxy server.

[0073] In one specific implementation, if the first request message body and the second request message body pass the adjudication, the request message corresponding to the first request message body is forwarded to the backend service through the proxy client, and after obtaining the response message from the backend service, the response message is sent back to the first mimic executor and the second mimic executor through the proxy server.

[0074] In another specific implementation, after the adjudicator performs mimicry adjudication on the first request message body and the second request message body, the method further includes: if the adjudication fails, after obtaining the third request message body sent by the third mimicry executor, the adjudicator performs mimicry adjudication on the third request message body sequentially with the first request message body and the second request message body; if two of the adjudications pass, the remaining target mimicry executor is determined to have failed the adjudication, and then the proxy server replies to the target mimicry executor with an adjudication failure status code, and the adjudicator reports the corresponding target mimicry executor information to the feedback control scheduler so that the feedback control scheduler can clean the target mimicry executor. That is, if the adjudication of the first request message body and the second request message body fails, after obtaining the corresponding third request message body sent by the third mimicry executor, the third request message body performs a second mimicry adjudication on the first request message body and the second request message body sequentially. Specifically, the third request message body and the first request message body are first subjected to a mimicry adjudication. If the adjudication passes, the request message corresponding to the first request message body is forwarded to the backend service through the proxy client. Then, the response message from the backend service is sent back to both the first and third request message bodies. The adjudication of the second mimicry executor is directly determined to have failed, without further mimicry adjudication with the second mimicry executor. The proxy server then sends an adjudication failure status code to the second mimicry executor, and the adjudicator reports the information of the second mimicry executor to the feedback control scheduler so that the feedback control scheduler can clean up the second mimicry executor. If the third request message body fails to pass the adjudication with the first request message body, then the third request message body and the second request message body are subjected to a mimic adjudication. If the adjudication passes, the request message corresponding to the second request message body is forwarded to the backend service through the proxy client. Then, the response message from the backend service is sent back to the second request message body and the third request message body. The adjudication of the first mimic executor is determined to have failed. Then, the adjudication failure status code is sent back to the first mimic executor through the proxy server. The adjudicator reports the information of the first mimic executor to the feedback control scheduler so that the feedback control scheduler can clean the first mimic executor.

[0075] Furthermore, after the aforementioned adjudicator performs mimicry adjudication on the third request message body against the first and second request message bodies respectively, the process further includes: if the adjudication between the third request message body and the first request message body fails, and the adjudication between the third request message body and the second request message body fails, then the proxy server replies with adjudication failure status codes to the first, second, and third mimicry executors; the adjudicator reports the corresponding mimicry executor information to the feedback control scheduler, so that the feedback control scheduler can clean the first, second, and third mimicry executors. It can be understood that if the mimicry adjudication between the third request message body and the first and second request message bodies fails, it indicates that the adjudication of the first, second, and third mimicry executors has failed. In this case, the proxy server will reply with adjudication failure status codes to all three mimicry executors and report the information of the three mimicry executors to the feedback control scheduler, so that the feedback control scheduler can clean the three mimicry executors.

[0076] Step S23: After obtaining the third request message body sent by the third mimicking executor, the adjudicator is used to make a mimicking adjudication on the first request message body and the third request message body.

[0077] In this embodiment, regardless of whether the adjudication of the first request message body and the second request message body passes, a second adjudication is required after obtaining the third request message body. Therefore, if the adjudication of the first request message body and the second request message body passes, after obtaining the third request message body sent by the third mimic executor, the adjudicator can perform a mimic adjudication on the first request message body and the third request message body.

[0078] Step S24: If the decision passes, the proxy server replies to the third mimic executor with the response message. If the decision fails, the proxy server replies to the third mimic executor with the decision failure status code, and the arbitrator reports the corresponding third mimic executor information to the feedback control scheduler so that the feedback control scheduler can clean the third mimic executor.

[0079] In this embodiment, if the first request message body and the third request message body pass the adjudication, the proxy server can directly reply to the third mimic executor with the response message corresponding to the first request message body. If the first request message body and the third request message body fail the adjudication, the third mimic executor is determined to have failed the adjudication. The proxy server then replies to the third mimic executor with an adjudication failure status code and uses the adjudicator to report the corresponding third mimic executor information to the feedback control scheduler so that the feedback control scheduler can clean the third mimic executor.

[0080] In addition, the above method further includes: initiating a timing operation after the arbitrator obtains the first request message body; if the second request message body and the third request message body are not obtained within the timeout period specified by the timing operation, a timeout status code is sent back to the first mimic executor; if the third request message body is not obtained within the timeout period specified by the timing operation, and the adjudication of the first request message body and the second request message body fails, a failure status code is sent back to the first mimic executor and the second mimic executor; if the number of mimic executors does not reach a preset number within the timeout period specified by the timing operation, timeout information is reported to the feedback control scheduler. It is understood that the arbitrator can be configured with an adjudication timeout period, and mimic executors with the same mimic identifier share the same timeout period. After the adjudication timeout, the data cache in the arbitrator will be cleared. Specifically, taking the three request message bodies mentioned above as an example, after the arbitrator obtains the first request message body, it starts a timer operation. If the arbitrator does not obtain the second and third request message bodies within the timeout period specified by the timer operation, the proxy server replies to the first mimic executor with an adjudication timeout status code, which can be set to 408. If only the first and second request message bodies are obtained within the timeout period specified by the timer operation, but the third request message body is not obtained, according to the first-come-first-served strategy in the arbitrator, the first and second request message bodies have completed mimic adjudication. If the adjudication of the first and second request message bodies passes, no processing is performed. If the adjudication of the first and second request message bodies fails, the proxy server replies to the first and second mimic executors with an adjudication failure status code 451. In addition, if the number of mimic executors does not reach the preset number of 3 within the timeout period specified by the timer operation, the arbitrator reports timeout information to the feedback control scheduler.

[0081] As can be seen, the embodiments of this application disclose detailed steps on how the adjudicator performs mimicry adjudication on the obtained request message body when the number of mimicry executors is three, and discloses the handling schemes under different circumstances when the adjudication times out.

[0082] See Figure 5 As shown in the figure, this application discloses a mimicry adjudication device for the HTTP service side, applied to an HTTP mimicry proxy. The HTTP mimicry proxy includes a proxy server, an adjudicator, and a proxy client. The device includes:

[0083] The message processing module 11 is used to obtain the request message sent by the mimicry executor based on the HTTP or HTTPS protocol, and use the proxy server to parse the request message to obtain the corresponding request message body, and extract the mimicry identifier from the request header of the request message body.

[0084] The mimicry adjudication module 12 is used to classify and store the request message body in the adjudicator based on the mimicry identifier, and determine the number of request message bodies with the same mimicry identifier in the adjudicator, so that when the number of requests exceeds a preset threshold, the adjudicator can be used to make mimicry adjudication on the request message body.

[0085] The response module 13 is used to forward the request message to the backend service through the proxy client if the decision is passed, and after obtaining the response message from the backend service, reply to the mimic execution body through the proxy server.

[0086] The execution body cleaning module 14 is used to reply with a failure status code to the mimic execution body through the proxy server if the adjudication fails, and to report the corresponding mimic execution body information to the feedback control scheduler through the adjudicator, so that the feedback control scheduler can clean the mimic execution body.

[0087] As can be seen, the HTTP mimicry proxy in this application obtains request messages based on HTTP or HTTPS protocols sent by the mimicry executor, parses the request messages using a proxy server to obtain the corresponding request message body, and extracts a mimicry identifier from the request header of the request message body. The request message body is categorized and stored in the arbitrator based on the mimicry identifier, and the number of requests with the same mimicry identifier in the arbitrator is determined. When the number of requests exceeds a preset threshold, the arbitrator performs mimicry adjudication on the request message body. If the adjudication passes, the request message is forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the proxy server replies to the mimicry executor with the response message. If the adjudication fails, the proxy server replies to the mimicry executor with an adjudication failure status code, and the arbitrator reports the corresponding mimicry executor information to the feedback control scheduler so that the feedback control scheduler can clean up the mimicry executor. Therefore, after obtaining the request message sent by the mimicry executor based on the HTTP or HTTPS protocol, this application uses a proxy server to parse the request message and extract the mimicry identifier in the request header. In other words, this application can support the parsing of request messages based on the HTTP or HTTPS protocol, thereby performing mimicry adjudication on the HTTP business side. Furthermore, after obtaining the mimicry identifier, the application stores the request message bodies from each mimicry executor in the adjudicator according to the mimicry identifier, thereby improving the efficiency of mimicry adjudication to cope with high concurrency and multi-threaded scenarios. In addition, when the mimicry adjudication fails, the information of the failed mimicry executor is reported to the feedback control scheduler so that the feedback control scheduler can complete the cleaning of the mimicry executor, thereby improving the security and reliability of mimicry defense.

[0088] Since the embodiments of the device part correspond to the embodiments described above, please refer to the embodiments described in the method part for the embodiments of the device part, and will not be repeated here.

[0089] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Specifically, it may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the mimicry adjudication method for the HTTP service side executed by the electronic device disclosed in any of the foregoing embodiments.

[0090] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0091] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0092] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored on it include operating system 221, computer program 222 and data 223, etc., and the storage method can be temporary storage or permanent storage.

[0093] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device 20 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system 221 can be Windows, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the mimicry adjudication method for the HTTP service side disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0094] Furthermore, embodiments of this application also disclose a computer-readable storage medium storing a computer program. When the computer program is loaded and executed by a processor, it implements the method steps executed during the mimicry adjudication process of the HTTP service side as disclosed in any of the foregoing embodiments.

[0095] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0096] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0097] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0098] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 a process, method, article, or apparatus. Without further limitations, 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 said element.

[0099] The foregoing provides a detailed description of the mimicry adjudication method, apparatus, device, and storage medium for the HTTP service side provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A mimicry adjudication method for the HTTP service side, characterized in that, Applied to an HTTP mimicry proxy, wherein the HTTP mimicry proxy includes a proxy server, an adjudicator, and a proxy client, the method includes: The system obtains request messages sent by the mimicry executor based on the HTTP or HTTPS protocol, and uses a proxy server to parse the request messages to obtain the corresponding request message body, and extracts the mimicry identifier from the request header of the request message body. The request message body is classified and stored in the arbiter based on the mimicry identifier, and the number of request message bodies with the same mimicry identifier in the arbiter is determined so that when the number of requests exceeds a preset threshold, the arbiter can be used to make a mimicry ruling on the request message body. If the ruling is successful, the request message will be forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the response message will be sent back to the mimic executor through the proxy server. If the adjudication fails, the proxy server will send an adjudication failure status code back to the mimic executor, and the adjudicator will report the corresponding mimic executor information to the feedback control scheduler so that the feedback control scheduler can clean up the mimic executor. The process of extracting the mimicry identifier from the request header of the request message body further includes: If the request header of the request message body does not contain a mimicry identifier, the request message is directly sent to the proxy client so that the proxy client can forward the request message to the backend service.

2. The mimicry adjudication method on the HTTP service side according to claim 1, characterized in that, The step of using a proxy server to parse the request message to obtain the corresponding request message body includes: If the request message is based on the HTTPS protocol, the request message is decrypted by the proxy server based on the pre-generated proxy server certificate to obtain the decrypted message. The proxy server parses the decrypted message to obtain the corresponding request message body.

3. The mimicry adjudication method on the HTTP service side according to claim 1, characterized in that, Before using the adjudicator to perform a pseudo-adjudication on the request message body, the method further includes: Determine the pre-configured random number matching list in the arbitrator, and query whether there is a random number in the request message body that matches the random number matching list; If it exists, the random number in the request message body is removed to output a request message body that does not include the random number.

4. The mimicry adjudication method on the HTTP service side according to claim 1, characterized in that, The step of using the adjudicator to perform a pseudo-adjudication on the request message body includes: The system determines the first request message body sent by the first mimicking executor and the second request message body sent by the second mimicking executor, and then uses the adjudicator to make a mimicking adjudication on the first request message body and the second request message body; wherein, the first request message body is stored in the adjudicator before the second request message body; Accordingly, if the ruling passes, the request message is forwarded to the backend service through the proxy client, and after receiving the response message from the backend service, the proxy server replies to the mimic executor with the response message, including: If the ruling is successful, the request message corresponding to the first request message body will be forwarded to the backend service through the proxy client, and after obtaining the response message from the backend service, the response message will be replied to the first mimic executor and the second mimic executor through the proxy server. After obtaining the third request message body sent by the third mimicking executor, the adjudicator is used to make a mimicking adjudication on the first request message body and the third request message body; If the ruling passes, the proxy server replies with the response message to the third mimic executor. If the ruling fails, the proxy server replies with the ruling failure status code to the third mimic executor, and the adjudicator reports the corresponding third mimic executor information to the feedback control scheduler so that the feedback control scheduler can clean the third mimic executor.

5. The mimicry adjudication method on the HTTP service side according to claim 4, characterized in that, After using the adjudicator to perform a pseudo-adjudication on the first request message body and the second request message body, the method further includes: If the adjudication fails, after receiving the third request message body sent by the third mimicking executor, the adjudicator will use the adjudicator to perform mimicking adjudication on the third request message body and the first request message body and the second request message body respectively. If both decisions pass, the remaining target mimicking executor is determined to fail. Then, the proxy server sends a failure status code to the target mimicking executor and the arbiter reports the corresponding target mimicking executor information to the feedback control scheduler so that the feedback control scheduler can clean the target mimicking executor.

6. The mimicry adjudication method for the HTTP service side according to claim 5, characterized in that, After the adjudicator performs pseudo-adjudication on the third request message body against the first request message body and the second request message body respectively, the process further includes: If the third request message body fails to resolve the conflict with the first request message body, and the third request message body fails to resolve the conflict with the second request message body, then the proxy server will send a failure status code to the first mimic executor, the second mimic executor, and the third mimic executor. The adjudicator reports the corresponding mimicry executor information to the feedback control scheduler so that the feedback control scheduler can clean up the first mimicry executor, the second mimicry executor, and the third mimicry executor.

7. The mimicry adjudication method on the HTTP service side according to claim 6, characterized in that, Also includes: After the arbitrator receives the first request message body, it starts a timing operation. If the second request message body and the third request message body are not obtained within the timeout period specified in the timing operation, the decision timeout status code is replied to the first mimic executor. If the third request message body is not obtained within the timeout period specified in the timing operation, and the first request message body and the second request message body fail to pass the adjudication, then the adjudication failure status code is replied to the first mimic executor and the second mimic executor. If the number of current mimicking executors does not reach the preset number within the timeout period specified in the timing operation, a timeout information is reported to the feedback control scheduler.

8. A mimicry adjudication device for the HTTP service side, characterized in that, An application for HTTP mimicry proxies, wherein the HTTP mimicry proxy includes a proxy server, an adjudicator, and a proxy client, the apparatus comprising: The message processing module is used to obtain request messages sent by the mimicry executor based on the HTTP or HTTPS protocol, and to use the proxy server to parse the request messages to obtain the corresponding request message body, and to extract the mimicry identifier from the request header of the request message body. The mimicry adjudication module is used to classify and store the request message body in the adjudicator based on the mimicry identifier, and to determine the number of request message bodies with the same mimicry identifier in the adjudicator, so that when the number of requests exceeds a preset threshold, the adjudicator can be used to make mimicry adjudication on the request message body. The response module is used to forward the request message to the backend service through the proxy client if the ruling is passed, and after obtaining the response message from the backend service, reply to the mimic executor through the proxy server. The execution body cleaning module is used to reply with a failure status code to the mimic execution body through the proxy server if the adjudication fails, and to report the corresponding mimic execution body information to the feedback control scheduler through the adjudicator, so that the feedback control scheduler can clean the mimic execution body. The mimicry adjudication device on the HTTP service side is also used to extract the mimicry identifier from the request header of the request message body. If the mimicry identifier is not present in the request header of the request message body, the request message is directly sent to the proxy client so that the proxy client can forward the request message to the backend service.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the mimicry adjudication method on the HTTP service side as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the mimicry adjudication method on the HTTP service side as described in any one of claims 1 to 7.

Images