Label determination method and device of IP address, electronic equipment and storage medium

Abstract

The application discloses a label determination method and device of an IP address, electronic equipment and a storage medium, and relates to the technical field of IP addresses. The method comprises the following steps: receiving a service request, wherein the service request carries target traffic sent by a client to a destination IP address; querying whether a traffic element in a preset mapping set exists in the target traffic; in the case where the traffic element in the preset mapping set exists in the target traffic, rewriting the service request based on a verification test case, and sending a new service request obtained after rewriting to the destination IP address; the case data of the verification test case does not attack the destination IP address; the verification test case corresponds to a case calculation value; receiving a request response associated with the new service request; and in the case where the case calculation value appears in the request response, determining that the label of the destination IP address is a vulnerability label. The application solves the technical problem in the related art that, when a vulnerability is detected, only sensitive keywords are targeted, and whether an IP address to be accessed has a vulnerability cannot be accurately determined.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and more specifically, to a method and apparatus for determining the label of an IP address, an electronic device, and a storage medium. Background Technology

[0002] As the demand for information security increases, the requirements for taint analysis in network traffic are also increasing. Taint analysis refers to analyzing whether data introduced by taint sources in a software program can be directly propagated to the taint convergence point without harmless processing. If not, it indicates that the system's information flow is secure; otherwise, it indicates that the system has security issues such as privacy data leakage or dangerous data operations.

[0003] The taint analysis methods used in related technologies include: The first method provides a vulnerability analysis approach based on precise behavior. It detects taints and sensitive code by calling functions with triples, such as `sys_call = {ret, arginput, argoutput}`, where `ret` represents the function call's return value, `arginput` represents the function call's input parameters, and `argoutput` represents the function call's output parameters. In taint propagation analysis, the state of each taint can be represented by a quintuple `Taint = {add, len, sta, type, p_info}`. Here, `add` represents the taint's starting address, `len` represents the taint's length, `sta` represents the taint's state, `type` represents the taint type, and `p_info` represents the data's context access path. When checking sensitive code, not all functions have sensitive behavior. For example, the introduced source information might be keystrokes used in the operating system login process or user input in a web form. Therefore, the taint source `Source` is preprocessed to exclude input with non-sensitive behavior. By constructing a source blacklist to filter out functions outside the blacklist, sources that are not sensitive inputs are filtered out, saving storage space while improving detection efficiency.

[0004] However, the first analysis method described above has significant drawbacks: Taint propagation analysis requires obtaining the program source code, function stack, and various register information from a white-box testing perspective. This approach is only suitable for server-side self-inspection and cannot perform dynamic taint analysis directly from a black-box perspective. When undetected vulnerabilities exist in the server program, attackers can exploit them. The determination of the source only selects dangerous / sensitive functions, without classifying the possible scenarios in which the source might appear, and also misses harmless echo functions. When the volume of business requests is large, it is necessary to judge and filter all requests that contain sources, which is performance-intensive and may filter out normal requests while missing echo test requests.

[0005] The second analysis method provides a web attack detection method and device. It detects the target vector according to the detection model and determines whether the web request to be detected is an attack request. When the detection result is abnormal, the web request to be detected is determined to be an attack request, the web request to be detected is recorded, and an early warning is issued. When the detection result is normal, the web request to be detected is determined to be a non-attack request, and no early warning is issued.

[0006] However, this analysis method also has significant drawbacks: it uniformly processes request data as strings and tokens for web requests, failing to identify vulnerable scenarios that could trigger vulnerabilities. It requires a full data scan of request traffic, which is performance-intensive. The generated string sample set is not updated or sorted; each detection of the target vector requires scanning the entire sample set. Tokenization techniques commonly used in vulnerability scanning tools, such as random number calculations and DNS connection echoes, frequently appear in normal traffic and are easily mistaken for legitimate results. If attackers use such attack data for vulnerability scanning, the model may fail to detect it, leading to false negatives.

[0007] In existing technologies, tainted vulnerability detection on terminal devices requires analyzing and auditing the server-side code to summarize tainted sources and sensitive functions, outputting a dynamic blacklist. When input is received, vulnerabilities are detected by analyzing the program stack call structure and checking for matches with the blacklist. This method is only suitable for server-side self-checks and requires continuous manual adjustments to the blacklist based on code updates, making automation impossible. Furthermore, this method of setting up blacklists is only applicable to specific server-side source code, lacks universality, and cannot be used for detection on intermediate devices.

[0008] Meanwhile, traditional web detection only targets sensitive keywords and does not involve contextual analysis. When attack data consists of random numerical calculations or DNS echoes that are easily confused with normal business traffic, web detection is prone to false positives and false negatives. Furthermore, web rules need to be added manually and cannot be automated. In actual traffic matching, there is no rule priority matching, which can easily lead to a situation where a single request needs to match all web rules.

[0009] Meanwhile, existing technologies cannot block vulnerability scanning requests, resulting in a low accuracy rate in identifying vulnerable IP addresses.

[0010] There is currently no effective solution to the above problems. Summary of the Invention

[0011] This invention provides a method, apparatus, electronic device, and storage medium for determining the label of an IP address, in order to at least solve the technical problem in related technologies that, when performing vulnerability detection, only sensitive keywords are considered, making it impossible to accurately determine whether an IP address to be accessed has a vulnerability.

[0012] According to one aspect of the present invention, a method for determining the label of an IP address is provided, applied to an intermediate device, comprising: receiving a service request, wherein the service request carries target traffic sent by a client to a destination IP address; querying whether the target traffic contains traffic elements in a preset mapping set, wherein the preset mapping set contains multiple element groups, each element group including: vulnerable scenarios, fuzz test cases, and element scores, wherein the vulnerable scenarios are scenarios that trigger security vulnerabilities in a historical process, and the fuzz test cases are test cases used to detect security vulnerabilities in a system through automatically generated random data; if the target traffic contains traffic elements in the preset mapping set, rewriting the service request based on verification test cases, and sending the rewritten new service request to the destination IP address, wherein the test case data of the verification test cases does not attack the destination IP address, and the verification test cases correspond to test case calculation values; receiving a request response associated with the new service request, and if the test case calculation value appears in the request response, determining that the security label of the destination IP address is a vulnerability label.

[0013] Optionally, the step of receiving a service request includes: obtaining request data from the service request; querying whether the request data contains the fuzz test case; and if the request data contains the fuzz test case, intercepting the service request.

[0014] Optionally, the step of querying whether there is a traffic element in the preset mapping set in the target traffic includes: sorting all the element groups according to the score of the element value to obtain a sorting result; matching the element information carried by the target traffic with multiple element groups contained in the preset mapping set according to the sorting result, wherein the element information includes: fuzz test cases and / or vulnerable scenarios; if the matching result indicates that the element information carried by the target traffic is successfully matched with any of the element groups, confirming that there is a traffic element in the mapping set in the target traffic.

[0015] Optionally, the step of matching the element information carried by the target traffic with multiple element groups contained in the preset mapping set includes: obtaining the location where the fuzz test case appears in the target traffic; determining the vulnerable scenario based on the scenario type indicated by the location, wherein the scenario type includes at least one of the following: form parameter value / URL parameter value, programming language tag, document type; and matching whether the fuzz test case and the vulnerable scenario exist simultaneously in the element group in the preset mapping set.

[0016] Optionally, the step of determining vulnerable scenarios based on the scenario type indicated by the location includes: if the location where the fuzzy test case appears indicates that the scenario type is a form parameter value or a URL parameter value, determining the form parameter or URL parameter in the target traffic as the vulnerable scenario; if the location where the fuzzy test case appears indicates that the scenario type is a programming language tag, determining the parent object or tag attribute of the fuzzy test case as the vulnerable scenario based on the tag attribute of the programming language tag and a preset genetic algorithm; if the location where the fuzzy test case appears indicates that the scenario type is a document type and the document type is a Hypertext Markup Language (HTML) file, determining the tag of the fuzzy test case as the vulnerable scenario.

[0017] Optionally, before rewriting the service request based on the verification test cases, the method further includes: parsing the traffic format associated with the target traffic in the service request; and replacing the fuzz test cases carried in the target traffic with the verification test cases according to the traffic format.

[0018] Optionally, after querying whether there are traffic elements in the preset mapping set in the target traffic, the method further includes: if it is determined that there are traffic elements in the preset mapping set in the target traffic, adding a first value to the element scores in the element group where the traffic element appears; or, counting the number of times the vulnerable scenario that successfully triggers a threat attack appears in the element group; and subtracting a second value from the element scores in the element group where the number of occurrences is less than a preset threshold during the preset period query time.

[0019] According to another aspect of the present invention, an IP address label determination device is also provided, applied to an intermediate device, comprising: a receiving unit for receiving a service request, wherein the service request carries target traffic sent by a client to a destination IP address; a query unit for querying whether the target traffic contains traffic elements in a preset mapping set, wherein the preset mapping set contains multiple element groups, each element group including: vulnerable scenarios, fuzz test cases, and element scores, wherein the vulnerable scenarios are scenarios that trigger security vulnerabilities in the historical process, and the fuzz test cases are test cases used to detect security vulnerabilities in the system through automatically generated random data; a rewriting unit for rewriting the service request based on verification test cases when the target traffic contains traffic elements in the preset mapping set, and sending the rewritten new service request to the destination IP address, wherein the test case data of the verification test cases does not attack the destination IP address, and the verification test cases correspond to test case calculation values; and a label determination unit for receiving a request response associated with the new service request, and determining that the security label of the destination IP address is a vulnerability label when the test case calculation value appears in the request response.

[0020] Optionally, the receiving unit includes: a first acquisition module, configured to acquire request data in the service request; a first query module, configured to query whether the request data contains the fuzz test case; and a first interception module, configured to intercept the service request if the request data contains the fuzz test case.

[0021] Optionally, the query unit includes: a first sorting module, used to sort all the element groups according to the score of the element value to obtain a sorting result; a first matching module, used to match the element information carried by the target traffic with multiple element groups contained in the preset mapping set according to the sorting result, wherein the element information includes: fuzzy test cases and / or vulnerable scenarios; and a first confirmation module, used to confirm that there is a traffic element in the mapping set in the target traffic if the matching result indicates that the element information carried by the target traffic is successfully matched with any of the element groups.

[0022] Optionally, the first matching module includes: a first acquisition submodule, configured to acquire the location where the fuzz test case appears in the target traffic; a first determination submodule, configured to determine a vulnerable scenario based on the scenario type indicated by the location, wherein the scenario type includes at least one of the following: form parameter value / URL parameter value, programming language tag, document type; and a matching submodule, configured to match whether the fuzz test case and the vulnerable scenario exist simultaneously in the element group in the preset mapping set.

[0023] Optionally, the first determining submodule includes: a second determining submodule, configured to determine the form parameters or URL parameters in the target traffic as the vulnerable scenario when the location where the fuzz test case appears indicates that the scenario type is a form parameter value or a URL parameter value; a third determining submodule, configured to determine the parent object or tag attribute of the fuzz test case as the vulnerable scenario based on the tag attribute of the programming language tag and a preset genetic algorithm when the location where the fuzz test case appears indicates that the scenario type is a programming language tag; and a fourth determining submodule, configured to determine the tag of the fuzz test case as the vulnerable scenario when the location where the fuzz test case appears indicates that the scenario type is a document type and the document type is a Hypertext Markup Language (HTML) file.

[0024] Optionally, the IP address label determination device further includes: a parsing unit, configured to parse the traffic format associated with the target traffic in the service request before rewriting the service request based on the verification test cases; and a replacement unit, configured to replace the fuzzy test cases carried in the target traffic with the verification test cases according to the traffic format.

[0025] Optionally, the IP address labeling device further includes: an accumulation module, used to, after querying whether there is a traffic element in the preset mapping set in the target traffic, add a first value to the element score of the element group in which the traffic element appears if it is determined that there is a traffic element in the preset mapping set in the target traffic; or, a statistics module, used to count the number of times a vulnerable scenario that successfully triggers a threat attack occurs in the element group; and a deduction module, used to subtract a second value from the element score of the element group in which the number of occurrences is less than a preset threshold during a preset period query time.

[0026] According to another aspect of the present invention, an electronic device is also provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the IP address tag determination method described in any one of the preceding embodiments via executing the executable instructions.

[0027] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the IP address tag determination method described in any one of the above embodiments.

[0028] In this invention, a service request is received via an intermediate device. The service request carries target traffic sent by the client to a destination IP address. The system queries whether traffic elements in a preset mapping set exist in the target traffic. The preset mapping set contains multiple element groups, each including: vulnerable scenarios, fuzz test cases, and element scores. Vulnerable scenarios are scenarios that trigger security vulnerabilities in the historical process. Fuzz test cases are test cases used to detect security vulnerabilities in the system using automatically generated random data. If traffic elements in the preset mapping set exist in the target traffic, the service request is rewritten based on the verification test cases, and the rewritten new service request is sent to the destination IP address. The test case data of the verification test cases does not attack the destination IP address, and the verification test cases have corresponding test case calculation values. The system receives a request response associated with the new service request, and if the test case calculation value appears in the request response, the security label of the destination IP address is determined to be a vulnerability label.

[0029] Based on the above disclosure, this invention can detect whether the intermediate traffic sent from the client to the destination IP address contains vulnerable scenarios and specified fuzzy test cases through an intermediate device. If so, the service request is rewritten (the test cases in the rewritten service request are harmless), and the existence of vulnerabilities in the destination IP address is confirmed by verifying whether the test case calculation value appears in the response sent to the destination IP address. This not only ensures the security of the server indicated by the destination IP address, but also accurately detects whether the destination IP address has security vulnerabilities. This solves the technical problem in related technologies that, when performing vulnerability detection, only target sensitive keywords and cannot accurately determine whether the IP address to be accessed has vulnerabilities. Attached Figure Description

[0030] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0031] Figure 1 This is a flowchart of an optional IP address tag determination method according to an embodiment of the present invention;

[0032] Figure 2 This is a flowchart of a single traffic detection of a service request according to an embodiment of the present invention;

[0033] Figure 3 This is an overall detection flowchart of an optional service request according to an embodiment of the present invention;

[0034] Figure 4 This is a schematic diagram of an optional IP address label determination device according to an embodiment of the present invention;

[0035] Figure 5 This is a hardware structure block diagram of an electronic device (or mobile device) according to an embodiment of the present invention. Detailed Implementation

[0036] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0037] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0038] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0039] Taint analysis refers to whether data introduced by taint sources in an analysis program can be directly propagated to the taint confluence point without harmless processing. If not, it indicates that the system's information flow is secure; otherwise, it indicates that the system has security issues such as privacy data leakage or dangerous data manipulation. In this embodiment, taint analysis is abstracted into a triple.<sources,sinks,sanitizers> In this context, "sources" refers to vulnerable scenarios (or sources of taint), representing the direct introduction of untrusted or confidential data into the system. "Sink" refers to taint points, representing the direct generation of security-sensitive operations or the leakage of private data to the outside world. "Sanitizer" refers to harmless treatment, representing the use of data encryption or removal of harmful operations to prevent data propagation from jeopardizing the information security of the software system.

[0040] Dynamic taint analysis refers to detecting whether taint data can spread from the taint source to the taint convergence point by monitoring the propagation of taint data in the system program in real time during program execution.

[0041] Fuzz testing, or simply "fuzz" in this invention, is a software testing strategy that generates random data and inputs it into a program, monitoring for abnormal states such as crashes and assertion failures to discover potential program errors, such as memory leaks. Fuzz testing is frequently used to detect security vulnerabilities in software or computer systems.

[0042] Vulnerability scanning tools collect Proof-of-Concept (POCs) of vulnerabilities (incomplete code snippets used to detect vulnerabilities on target hosts) and perform fuzz tests. They also send requests that allow remote code execution and determine whether the target host has vulnerabilities by checking whether pre-defined keywords appear in the request and response.

[0043] Snort rules are used to detect different parts of data packets. Most intrusion behaviors have certain characteristics, and Snort rules are constructed using information about these characteristics.

[0044] XML, Extensible Markup Language.

[0045] HTML, Hypertext Markup Language.

[0046] It should be noted that the IP address labeling method and apparatus in this disclosure can be used in the field of information security. When determining whether there are vulnerabilities in the IP address accessing communication traffic, it can also be used in any field other than information security. The application field of the IP address labeling method and apparatus in this disclosure is not limited.

[0047] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving consent information from the aforementioned user or organization.

[0048] This disclosure can be applied to various vulnerability analysis systems / devices / apparatus, especially for vendors with security service needs. In this embodiment, the detection information from traffic detection devices used by security service vendors can block vulnerability scanning requests and determine vulnerable IP addresses. By summarizing potential vulnerability scenarios in current web services and compiling commonly used fuzz test cases in current vulnerability scanning tools, it has strong versatility. An intermediate device is deployed between the client and the server to detect intermediate traffic. It detects whether the traffic simultaneously contains vulnerable source scenarios and test case fuzzing. If so, the fuzz test case is replaced with a harmless one. By checking whether the response contains the calculated value of the fuzz test case, if so, the score of the current source-fuzz is increased in the source-fuzz-score table, and the updated source-fuzz-score table is used as input for the next traffic detection. By continuously detecting traffic, effective source-fuzzing can be dynamically adjusted without manual adjustment, automatically adjusting rule priorities throughout the process and avoiding the need for a single traffic flow to match all rules. Simultaneously, rules are automatically generated based on source-fuzzing.

[0049] Furthermore, this disclosure overcomes the shortcomings of existing technologies, such as inability to be applied to intermediate devices, low applicability, and the need for manual adjustment of the configuration blacklist. It can be directly applied to intermediate devices and has higher applicability.

[0050] The present invention will now be described in detail with reference to various embodiments.

[0051] Example 1

[0052] According to an embodiment of the present invention, an embodiment of a method for determining the label of an IP address is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0053] According to one aspect of the present invention, a method for determining the label of an IP address is provided, which is applied to an intermediate device. The intermediate device refers to a device set between a client and a server indicating a destination IP address. The intermediate device can be a virtual device, capable of intercepting traffic sent from the client to the destination IP address and verifying whether the traffic is secure.

[0054] Figure 1 This is a flowchart of an optional IP address label determination method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0055] Step S102: Receive a service request, wherein the service request carries the target traffic sent by the client to the destination IP address;

[0056] Step S104: Query whether there are traffic elements in the preset mapping set in the target traffic. The preset mapping set contains multiple element groups. Each element group includes: vulnerable scenarios, fuzz test cases and element scores. Vulnerable scenarios are scenarios that trigger security vulnerabilities in the historical process. Fuzz test cases are test cases used to detect security vulnerabilities in the system through automatically generated random data.

[0057] Step S106: If there are traffic elements in the preset mapping set in the target traffic, rewrite the service request based on the verification test case and send the rewritten new service request to the destination IP address. The test case data of the verification test case does not attack the destination IP address, and the verification test case has a corresponding test case calculation value.

[0058] Step S108: Receive the request response to the request for the associated new service, and if the use case calculation value appears in the request response, determine that the security label of the destination IP address is a vulnerability label.

[0059] Through the above steps, a service request can be received via an intermediate device. The service request carries the target traffic sent by the client to the destination IP address. It checks whether the target traffic contains traffic elements from a preset mapping set. The preset mapping set contains multiple element groups, each of which includes: vulnerable scenarios, fuzz test cases, and element scores. Vulnerable scenarios are scenarios that have triggered security vulnerabilities in the past. Fuzz test cases are test cases used to detect security vulnerabilities in the system using automatically generated random data. If the target traffic contains traffic elements from the preset mapping set, the service request is rewritten based on the verification test cases, and the rewritten new service request is sent to the destination IP address. The test case data of the verification test cases does not attack the destination IP address. The verification test cases have corresponding test case calculation values. The request response associated with the new service request is received, and if the test case calculation value appears in the request response, the security label of the destination IP address is determined to be a vulnerability label. In this embodiment, an intermediate device can detect whether the intermediate traffic sent from the client to the destination IP address contains vulnerable scenarios and specified fuzzy test cases. If so, the service request is rewritten (the test cases in the rewritten service request are harmless). By verifying whether the test case calculation value appears in the response sent to the destination IP address, it can be confirmed whether the destination IP address has a vulnerability. This not only ensures the security of the server indicated by the destination IP address, but also accurately detects whether the destination IP address has a security vulnerability. This solves the technical problem in related technologies where vulnerability detection only targets sensitive keywords and cannot accurately determine whether the IP address to be accessed has a vulnerability.

[0060] The embodiments of the present invention will be described in detail below with reference to the above implementation steps.

[0061] In this embodiment, before determining the label of the destination IP address in the service request, it is necessary to determine an alternative and secure fuzz test case (used to access the server indicated by the destination IP address and confirm whether the destination IP address has a security vulnerability). In this embodiment, such a fuzz test case is characterized as a verification test case.

[0062] When determining verification test cases, traffic can be extracted from multiple service requests initiated in historical time periods to obtain traffic monitoring and detection records. The corresponding data of a complete request / response can then be used as a sample for testing.

[0063] Optionally, the echo scenarios for fuzz test cases include: random number calculation echo; domain log echo; response to custom request header echo; and sensitive file access information keyword echo.

[0064] For the Proof of Concept (POC) used by currently popular vulnerability scanning tools, we summarize the available fuzz test cases. The echo scenarios of these test cases can be summarized as follows:

[0065] 1. Random number calculation and display, for example, using: ^\d[*-+]\d$;

[0066] 2. DNS log echo (corresponding to the domain log echo mentioned above), connecting back to a well-known vulnerability scanning tool's dedicated DNS platform, such as ^https?: / / interact\.sh$;

[0067] 3. Response with custom header echo (corresponding to the above response with custom request header echo), for example, using: getResponse[\s\S]{0,246}setHeader;

[0068] 4. Keyword echoing for sensitive file access information, for example: (\x2e\x2f)? (passwd|user|config|setting|backend)$;

[0069] 5. In the file upload scenario, the area is divided by --boundary and contains a string of simply randomly generated characters.

[0070] In this embodiment, by summarizing the attack proof-of-concept (POC) of vulnerability scanning tools into fuzz test cases and summarizing the scenarios where web services are prone to vulnerabilities, the two are combined as test cases and applied to the traffic detection device. The fuzz test cases are replaced with non-aggressive verification test cases, and the playback is replayed for verification. Based on the replay response results, it can be determined whether the destination IP of the traffic has a vulnerability, avoiding false positives and false negatives.

[0071] Simultaneously, based on the input detection traffic, effective damaged scenarios and fuzz test cases (source-fuzz) are summarized, and the vulnerable scenario and test case mapping table (source-fuzz-score table) is continuously updated. The updated results are used as input for the next detection.

[0072] This invention can be applied to traffic detection in intermediate devices, protecting the server by replacing the attack behavior with harmless test cases.

[0073] After confirming the fuzz test cases, identify vulnerable scenarios where fuzzing may occur, including: form parameter values ​​(URLs or HTTP data packets), file upload values, JS tags, XXE (XML External Entity Injection, where the program parses external entities forged by the attacker when parsing input XML data), and DTD (Document Type Definition, which is a set of syntactic rules for tags established for data exchange between programs).

[0074] Based on the confirmed fuzz test cases and vulnerable scenarios, a preset mapping set is defined. The preset mapping set contains multiple element groups, each of which includes: vulnerable scenario, fuzz test case, and element score. In this embodiment, a triplet: source-fuzz-score can be used for illustration.

[0075] The following is a schematic illustration of a single traffic detection process in a real-world scenario.

[0076] Step S102: Receive a service request, wherein the service request carries the target traffic sent by the client to the destination IP address.

[0077] The aforementioned service request refers to a request sent by the client to the server where the destination IP address is located. In order to ensure the security of information transmission and detect whether there are security vulnerabilities in the destination IP address in a timely manner, but without intruding into the server where the destination IP address is located, this embodiment uses an intermediate device to intercept the server request.

[0078] Optionally, step S102 includes: obtaining request data from the service request; querying whether the request data contains fuzz test cases; and intercepting the service request if the request data contains fuzz test cases.

[0079] In this embodiment, when determining whether to block the aforementioned service request, the vulnerable scenario source can be determined based on the location of the fuzz test case appearing in the request. Only when both the fuzz test case and the vulnerable scenario source exist simultaneously will the subsequent traffic element query and IP label determination process proceed.

[0080] Step S104: Query whether there are traffic elements in the preset mapping set in the target traffic.

[0081] Optionally, step S104 includes: sorting all element groups according to the score of the element to obtain a sorting result; matching the element information carried by the target traffic with multiple element groups contained in the preset mapping set according to the sorting result, wherein the element information includes: fuzz test cases and / or vulnerable scenarios; if the matching result indicates that the element information carried by the target traffic is successfully matched with any element group, confirming that there is a traffic element in the mapping set in the target traffic.

[0082] In this embodiment, by matching whether the source-fuzz in the triplet of the above mapping set appears in the traffic, the matching can be performed according to the size of the element score, such as prioritizing the matching of element information with larger element scores (because a larger element score indicates a higher probability of the element appearing).

[0083] Optionally, in this embodiment, the step of matching the element information carried by the target traffic with multiple element groups contained in the preset mapping set includes: obtaining the location where the fuzz test case appears in the target traffic; determining the vulnerable scenario based on the scenario type indicated by the location, wherein the scenario type includes at least one of the following: form parameter value / URL parameter value, programming language tag, document type; and matching whether the fuzz test case and the vulnerable scenario exist simultaneously in the element group of the preset mapping set.

[0084] By confirming the location of fuzz test cases in the target traffic, we can determine the type of scenario that may be vulnerable to fuzzing, including: form parameter values ​​(URL or HTTP data packets), file upload values, programming language JS tags, and document types (such as those identified by the DTD entity identifiers mentioned above).

[0085] Optionally, the step of determining vulnerable scenarios based on the scenario type indicated by the location includes: when the scenario type indicated by the location of the fuzzy test case is a form parameter value or a URL parameter value, identifying the form parameters or URL parameters in the target traffic as vulnerable scenarios; when the scenario type indicated by the location of the fuzzy test case is a programming language tag, identifying the parent object or tag attribute of the fuzzy test case as a vulnerable scenario based on the tag attribute of the programming language tag and a preset genetic algorithm; when the scenario type indicated by the location of the fuzzy test case is a document type and the document type is a Hypertext Markup Language (HTML) file, identifying the tag of the fuzzy test case as a vulnerable scenario.

[0086] The following illustrations illustrate vulnerable scenarios for various scenario types.

[0087] The first type is for scenarios where the parameter value is a form parameter or a URL parameter.

[0088] That is, when a fuzz test case appears as a form parameter value or a URL parameter value, the corresponding form parameter or URL parameter is set to source, in the following form:

[0089] parameter = {{fuzz}};

[0090] In this case, when detecting form parameter data or URL data, an example of using Snort rules is as follows:

[0091] alert http any any-->any any(msg:"URL Fuzz Detected";flow:to_sevrer;content:"parameter=";pcre:" / parameter="(\d[*-+]\d$|https?: / / [0-9a-z]{0,64}\.[0-9a-z] {0,32}$|getResponse[\s\S]{0,246}setHeader|(\x2e\x2f)? (passwd|user|config|setting|backend)$|([0-9a-z])+) / i";).

[0092] The second type is for scenarios where the value is uploaded as a file.

[0093] If the fuzz test case appears in the uploaded file data section, then the range of the boundary is set to the source, using the HTTP file upload data separator --boundary as the boundary; the specific form is as follows:

[0094] --boundary

[0095] Content-Disposition:form-data; name="xxx"; filename="xxx"Content-Type:xxx

[0096] {{fuzz}}

[0097] --boundary

[0098] In this case, the uploaded file data is detected. An example of using Snort rules is shown below:

[0099] alert http any any-->any any(msg:"File Upload Fuzz Detected"; flow:to_sevrer; content: "--"; content: "Content-Disposition|3a|form-data|3b|"; distance: 0; within: 300; pcre: "(\d[*-+]\d$|https?: / / [0-9a-z]{0,64}\.[0-9a-z]{0,64}$|getResponse[\s\S]{0,246}setHeader|(\x2e\x2f)? (passwd|user|config|setting|backend)$|([0-9a-z])+) / Ri";).

[0100] The third type is for scenarios tagged with programming languages.

[0101] For example, if a fuzz test case appears in JavaScript data, the parent tag that can trigger the fuzz test case in JavaScript is enumerated through a genetic algorithm. The first generation uses all feasible JavaScript tags, and the tag attribute is set to the parent object or attribute of the fuzz test case as source through the genetic algorithm (corresponding to the above-mentioned determination of the parent object or tag attribute of the fuzz test case as a vulnerable scenario based on the tag attribute of the programming language tag and the preset genetic algorithm). The specific form is as follows:

[0102] <script>alert({{fuzz}})< / script>

[0103] <img src onerror＝alert({{fuzz}})>

[0104] img / src / onerror=alert({{fuzz}})

[0105] For this type of situation, which involves detecting data from JavaScript tags, an example of using Snort rules is shown below:

[0106] alert http any any-->any any(msg:"JavaScript Tag Fuzz Detected";flow:to_sevrer;pcre:"alert\(((\d[*-+]\d$|https?: / / [0-9a-z]{0,64}\.[0-9a-z]{0,64}$|getRes ponse[\s\S]{0,246}setHeader|(\x2e\x2f)? (passwd|user|config|setting|backend)$|([0-9a-z])+) / URi";).

[0107] The fourth type is for scenario types that are document types and document types that are Hypertext Markup Language (HTML) files.

[0108] If fuzz test cases appear in the HTML file, the tag containing the fuzz test cases (corresponding to the tags mentioned above) will be set as the source, in the following form:

[0109] <?xml version="1.0"?>

[0110] <! DOCTYPE{{fuzz}}SYSTEM{{fuzz}}>

[0111] <{{fuzz}}>{{fuzz}}< / {{fuzz}}>

[0112] For this type of situation, where partial data in an HTML file is detected, an example of using Snort rules is shown below:

[0113] alert http any any-->any any(msg:"Html Content Fuzz Detected";flow:to_sevrer;content:"<?xml;

[0114] version=|22|1.0|22|? >"content:"<! DOCTYPE";distance:0;within:64;pcre:"(\d[*-+]\d$|https?: / / [0-9a-z]{0,64}\.[0-9a-z]{0,64}$|getRes ponse[\s\S]{0,246}setHeader|(\x2e\x2f)? (passwd|user|config|setting|backend)$|([0-9a-z])+) / Ri";).

[0115] After identifying the vulnerable scenarios for traffic in the current service request through the various scenario types described above, we can analyze the request data to replace the fuzz test cases.

[0116] Step S106: If traffic elements in the preset mapping set exist in the target traffic, the service request is rewritten based on the verification test case, and the rewritten new service request is sent to the destination IP address. The test case data of the verification test case does not attack the destination IP address, and the verification test case has a corresponding test case calculation value.

[0117] Optionally, before rewriting the service request based on the verification test cases, the process may also include: parsing the traffic format of the target traffic associated with the service request; and replacing the fuzz test cases carried in the target traffic with verification test cases according to the traffic format.

[0118] In practical implementation scenarios, partial data from service requests can be analyzed to check for fuzz test cases. If fuzz test cases are found, the service request is intercepted, and the obtained fuzz test cases are replaced with the aforementioned replaceable and secure verification test cases, such as ^\d[*-+]\d$. The request data is then rewritten and replayed. Since the verification test cases do not pose an actual attack threat to the target IP address, if the response to the replayed service request contains a calculated value associated with the verification test case (e.g., ^\d[*-+]\d$), the target IP address of the service request is labeled as vulnerable.

[0119] Step S108: Receive the request response to the request for the associated new service, and if the use case calculation value appears in the request response, determine that the security label of the destination IP address is a vulnerability label.

[0120] Steps S102 to S108 above describe the method for determining the IP address label of a single service request. The following section explains the situation when there are many service requests or traffic in a large volume of traffic.

[0121] Optionally, after querying whether there are traffic elements in the preset mapping set in the target traffic, the method further includes: if it is determined that there are traffic elements in the preset mapping set in the target traffic, adding the element scores of the element groups in which the traffic elements appear to a first value; or, counting the number of times the vulnerable scenarios that successfully trigger threat attacks occur in the element groups; and subtracting the second value from the element scores of the element groups in which the number of occurrences within the preset period query time is less than a preset number threshold.

[0122] In actual inspection scenarios, for high traffic, vulnerable scenarios (vulnerability trigger domains) are divided, each traffic request undergoing inspection is recorded, and the successful and failed fuzzes and corresponding sources of the attack are statistically analyzed. The source that successfully triggers the attack is set as the key, and its fuzz is set as the value. Each fuzz is initially given a score of 0, and a source-fuzz-score mapping table is established.

[0123] If the same source triggers the same fuzzing multiple times, the score of that fuzzing will be increased. A periodic source-fuzzing check time is set; if the number of times a key appears in a source is less than a preset threshold / expected value, or if the number of occurrences remains constant over a long period, the score of that source-fuzzing will be decreased.

[0124] Each time traffic in a service request is checked, the input is the mapping table source-fuzz-score, which is processed by the traffic of the previous request. Fuzz with high element scores is prioritized as the fuzz test case to be matched.

[0125] Compared to existing technologies that cannot be applied to intermediate devices, have low applicability, and require manual adjustment of blacklist configuration, this embodiment can be directly applied to intermediate devices, has higher applicability, and can automatically adjust and update the preset mapping table (source-fuzz-score table) of vulnerable scenarios and test cases as input based on each traffic detection. It automatically adjusts the mapping table and generation rules, and can block attack requests and replace attack behaviors with non-aggressive verification test cases, without causing actual attacks to the server. It will also not falsely report or miss attacks when the attack data is random number calculation or DNS echo, which is easily confused with normal business traffic.

[0126] The following is an illustrative explanation of another specific determination method.

[0127] Figure 2 This is a flowchart illustrating a single-transaction traffic detection for a service request according to an embodiment of the present invention, such as... Figure 2 As shown, it includes:

[0128] 021. When performing traffic detection, a preset mapping set is invoked, wherein the preset mapping set is source-fuzz-score;

[0129] 022, Perform traffic checks on a certain service request; when performing traffic checks, the main focus is on matching whether the traffic contains source-fuzz from each element group in the preset mapping set, prioritizing elements with higher element scores.

[0130] 023, intercept service requests. If a match is successful, and it is confirmed that an element from a certain element group in a preset mapping set appears in the service request, the service request will be intercepted.

[0131] 024, Test Case Replacement, which replaces the fuzz in the service request with verification test cases;

[0132] For popular vulnerability scanning tools, the PoC (Proof of Concept) is used to summarize fuzzy test cases. These test cases can be broadly categorized into the following types:

[0133] ① Random number calculation and display: ^\d[*-+]\d$;

[0134] ② DNS log echoes back to a well-known vulnerability scanning tool's dedicated DNS platform, such as ^https?: / / interact\.sh$;

[0135] ③ To respond with a custom header, use getResponse[\s\S]{0,246}setHeader;

[0136] ④ Keyword echoing for sensitive file access information, (\x2e\x2f)? (passwd|user|config|setting|backend)$;

[0137] ⑤ In the file upload scenario, the area is divided by --boundary and contains a string of simply randomly generated characters.

[0138] 025, Request Rewrite: After replacing the test case, the service request is rewritten to obtain a new service request;

[0139] 026, Request Replay: A new service request is sent to the destination IP address indicated by the traffic in the service request, and a response is obtained. For example, the obtained fuzz test case is replaced with ^\d[*-+]\d$ and part of the request data is rewritten, and the request is replayed. Fuzz test cases of ^\d[*-+]\d$ do not pose an actual attack threat to the destination IP address. If the response contains a calculated value of ^\d[*-+]\d$, the destination IP address of the request is labeled as vulnerable.

[0140] 027, Determine whether the calculated value of the replacement verification test case appears in the request response;

[0141] 028, IP determination: If the calculated value of the replacement verification test case appears in the request response, it is confirmed that the destination IP has a security vulnerability; if the calculated value of the replacement verification test case does not appear, the destination IP does not have a security vulnerability.

[0142] 029. After a single detection is completed, the source-fuzz in this traffic is recorded in the preset mapping set. If the element group already exists in the preset mapping set, the score of the source-fuzz element is increased.

[0143] Figure 3 This is an overall detection flowchart of an optional service request according to an embodiment of the present invention, such as... Figure 3 As shown, it includes:

[0144] 031, Traffic Flow Detection.

[0145] 032, Result Recording. After enabling traffic detection, record the results of each traffic detection.

[0146] 033, Bonus points for valid elements. This means that valid source-fuzzing will be added to increase the score.

[0147] In actual inspections, for high-traffic scenarios, after dividing them into vulnerable scenarios (vulnerability trigger domains), each traffic request undergoing inspection is recorded, and the successful and failed fuzzes and corresponding sources are statistically analyzed. The source that successfully triggers the attack is set as the key, and its fuzz is the value, with each fuzz initially assigned a score of 0. A source-fuzz-score mapping table is established. If the same source triggers the same fuzz multiple times, the score of that fuzz is increased.

[0148] 034. Update the mapping set. Based on the scoring results of valid elements, update the preset mapping set to ensure that the input mapping set for the next traffic detection is the updated mapping set.

[0149] 035, Periodic check of the mapping set.

[0150] 036, Deduction for Aging Elements. This checks for elements that appear infrequently or with a consistently low frequency within a given period. These elements are considered less effective or less likely to appear, resulting in a deduction in the source-fuzz score. The periodic source-fuzz check time is set; if the key in a source appears less frequently than expected or its frequency remains constant over a long period, the score for that source-fuzz check is reduced.

[0151] 037, synchronize the results after deduction to the mapping set.

[0152] 038. Use the updated mapping set as input for the next traffic inspection. Each time a traffic inspection is requested, the input is the source-fuzz-score table after the previous traffic inspection, prioritizing fuzzes with high scores as the next match.

[0153] 039, continue traffic monitoring.

[0154] Compared to existing technologies that perform IP vulnerability detection on terminal devices, which require analyzing and auditing server-side code to summarize tainted sources and sensitive functions to output a dynamic blacklist, traditional web detection only targets sensitive keywords and does not involve contextual analysis. When attack data consists of random numerical calculations or DNS echoes that are easily confused with normal business traffic, web detection is prone to false positives and false negatives. Furthermore, web rules need to be added manually and cannot be automated, and in the actual traffic matching process, there is no rule priority matching for traffic, which can easily lead to a situation where a single request needs to match all web rules.

[0155] This invention summarizes potential vulnerability scenarios in current web services and commonly used fuzzing test cases in current vulnerability scanning tools, demonstrating strong general applicability. An intermediate device is deployed between the client and server to detect intermediate traffic. It checks whether the traffic simultaneously contains vulnerable source scenarios and fuzzing test cases. If so, the fuzzing test cases are replaced with harmless ones. The response is checked for the calculated values ​​of the fuzzing test cases; if present, the score of this source-fuzzing instance is increased in the source-fuzz-score table, and the updated source-fuzz-score table is used as input for the next traffic detection. Through continuous traffic detection, effective source-fuzzing can be dynamically adjusted, eliminating the need for manual adjustments and automating rule priority adjustments throughout the process, avoiding the need for a single traffic instance to match all rules. Simultaneously, rules are automatically generated based on source-fuzzing.

[0156] This invention overcomes the shortcomings of existing technologies, such as limited applicability to intermediate devices and the need for manual adjustment of blacklist configurations. It can be directly applied to intermediate devices, has higher applicability, and can automatically adjust and update the vulnerable scenario and test case mapping table (source-fuzz-score table) based on each traffic detection. It automatically adjusts the mapping table and generation rules, blocks attack requests, and replaces attack behaviors with harmless fuzzy test cases, without causing actual attacks to the server. It also avoids false alarms and missed alarms when attack data is random number calculations or DNS echoes, which are easily confused with normal business traffic.

[0157] The invention will now be described in conjunction with another alternative embodiment.

[0158] Example 2

[0159] This embodiment provides an IP address label determination device applied to an intermediate device. The label determination device includes multiple implementation units, each of which corresponds to a specific implementation step in the above embodiment one.

[0160] Figure 4 This is a schematic diagram of an optional IP address label determination device according to an embodiment of the present invention, such as... Figure 4 As shown, it includes: a receiving unit 41, a query unit 42, a rewriting unit 43, and a tag determination unit 44, wherein,

[0161] Receiving unit 41 is used to receive a service request, wherein the service request carries the target traffic sent by the client to the destination IP address;

[0162] The query unit 42 is used to query whether there are traffic elements in the preset mapping set in the target traffic. The preset mapping set contains multiple element groups. Each element group includes: vulnerable scenarios, fuzz test cases and element scores. Vulnerable scenarios are scenarios that trigger security vulnerabilities in the historical process. Fuzz test cases are test cases used to detect security vulnerabilities in the system through automatically generated random data.

[0163] The rewrite unit 43 is used to rewrite the service request based on the verification test case when there are traffic elements in the preset mapping set in the target traffic, and send the rewritten new service request to the destination IP address. The test case data of the verification test case does not attack the destination IP address, and the verification test case has a corresponding test case calculation value.

[0164] The tag determination unit 44 is used to receive the request response of the associated new service request, and determine the security tag of the destination IP address as a vulnerability tag if the use case calculation value appears in the request response.

[0165] The aforementioned IP address label determination device can receive service requests via receiving unit 41. The service request carries target traffic sent by the client to the destination IP address. The query unit 42 queries whether there are traffic elements in the target traffic within a preset mapping set. The preset mapping set contains multiple element groups, each including: vulnerable scenarios, fuzz test cases, and element scores. Vulnerable scenarios are scenarios that trigger security vulnerabilities in the historical process. Fuzz test cases are test cases used to detect security vulnerabilities in the system using automatically generated random data. If traffic elements in the preset mapping set exist in the target traffic, the rewriting unit 43 rewrites the service request based on the verification test cases and sends the rewritten new service request to the destination IP address. The test case data of the verification test cases does not attack the destination IP address, and the verification test cases correspond to test case calculation values. The label determination unit 44 receives the request response associated with the new service request, and if the test case calculation value appears in the request response, the security label of the destination IP address is determined to be a vulnerability label. In this embodiment, an intermediate device can detect whether the intermediate traffic sent from the client to the destination IP address contains vulnerable scenarios and specified fuzzy test cases. If so, the service request is rewritten (the test cases in the rewritten service request are harmless). By verifying whether the test case calculation value appears in the response sent to the destination IP address, it can be confirmed whether the destination IP address has a vulnerability. This not only ensures the security of the server indicated by the destination IP address, but also accurately detects whether the destination IP address has a security vulnerability. This solves the technical problem in related technologies where vulnerability detection only targets sensitive keywords and cannot accurately determine whether the IP address to be accessed has a vulnerability.

[0166] Optionally, the receiving unit includes: a first acquisition module, used to acquire request data in the service request; a first query module, used to query whether the request data contains fuzz test cases; and a first interception module, used to intercept the service request if the request data contains fuzz test cases.

[0167] Optionally, the query unit includes: a first sorting module, used to sort all element groups according to the score of the element, and obtain a sorting result; a first matching module, used to match the element information carried by the target traffic with multiple element groups contained in a preset mapping set according to the sorting result, wherein the element information includes: fuzz test cases and / or vulnerable scenarios; and a first confirmation module, used to confirm that there are traffic elements in the mapping set in the target traffic if the matching result indicates that the element information carried by the target traffic is successfully matched with any element group.

[0168] Optionally, the first matching module includes: a first acquisition submodule, used to acquire the location where the fuzz test case appears in the target traffic; a first determination submodule, used to determine the vulnerable scenario based on the scenario type indicated by the location, wherein the scenario type includes at least one of the following: form parameter value / URL parameter value, programming language tag, document type; and a matching submodule, used to match whether the fuzz test case and the vulnerable scenario exist simultaneously in the element group of the preset mapping set.

[0169] Optionally, the first determining submodule includes: a second determining submodule, used to determine the form parameters or URL parameters in the target traffic as vulnerable scenarios when the location of the fuzzy test case indicates that the scenario type is a form parameter value or a URL parameter value; a third determining submodule, used to determine the parent object or tag attribute of the fuzzy test case as a vulnerable scenario when the location of the fuzzy test case indicates that the scenario type is a programming language tag, based on the tag attribute of the programming language tag and a preset genetic algorithm; and a fourth determining submodule, used to determine the tag of the fuzzy test case as a vulnerable scenario when the location of the fuzzy test case indicates that the scenario type is a document type and the document type is a Hypertext Markup Language (HTML) file.

[0170] Optionally, the IP address label determination device further includes: a parsing unit, used to parse the traffic format of the target traffic associated in the service request before rewriting the service request based on the verification test cases; and a replacement unit, used to replace the fuzz test cases carried in the target traffic with verification test cases according to the traffic format.

[0171] Optionally, the IP address labeling device further includes: an accumulation module, used to accumulate the element scores in the element group of the traffic element by a first value after querying whether there is a traffic element in the preset mapping set in the target traffic, and if it is determined that there is a traffic element in the preset mapping set in the target traffic; or, a statistics module, used to count the number of times the vulnerable scenario that successfully triggers a threat attack occurs in the element group; and a deduction module, used to subtract a second value from the element scores in the element group of the element group whose occurrence frequency is less than a preset threshold frequency within a preset period query time.

[0172] Optionally, the echo scenarios for fuzz test cases include: random number calculation echo; domain log echo; response to custom request header echo; and sensitive file access information keyword echo.

[0173] The aforementioned IP address tag determination device may also include a processor and a memory. The aforementioned receiving unit 41, query unit 42, rewrite unit 43, tag determination unit 44, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0174] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured to receive request responses to associated new service requests by adjusting kernel parameters. If a test case calculation value appears in the request response, the security label of the destination IP address is determined to be a vulnerability label.

[0175] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0176] According to another aspect of the present invention, an electronic device is also provided, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the tag determination method for the IP address of any of the above-mentioned items by executing the executable instructions.

[0177] Figure 5 This is a hardware structure block diagram of an electronic device (or mobile device) according to an embodiment of the present invention. Figure 5 As shown, the electronic device may include one or more processors 502 (shown as 502a, 502b, ..., 502n in the figure) 502 (processor 502 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 504 for storing data. In addition, it may include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 5 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device may also include... Figure 5 The more or fewer components shown, or having the same Figure 5 The different configurations shown.

[0178] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute the IP address tag determination method of any of the above.

[0179] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: receiving a service request, wherein the service request carries target traffic sent by a client to a destination IP address; querying whether the target traffic contains traffic elements in a preset mapping set, wherein the preset mapping set contains multiple element groups, each element group including: vulnerable scenarios, fuzz test cases, and element scores, wherein vulnerable scenarios are scenarios that trigger security vulnerabilities in the historical process, and fuzz test cases are test cases used to detect security vulnerabilities in the system through automatically generated random data; if the target traffic contains traffic elements in the preset mapping set, rewriting the service request based on the verification test cases, and sending the rewritten new service request to the destination IP address, wherein the test case data of the verification test cases does not attack the destination IP address, and the verification test cases correspond to test case calculation values; receiving a request response associated with the new service request, and if the test case calculation value appears in the request response, determining that the security label of the destination IP address is a vulnerability label.

[0180] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0181] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0182] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0183] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0184] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0185] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0186] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method of label determination of an IP address, characterized by, The application is applied to an intermediate device, comprising: receiving a service request, wherein the service request carries target traffic sent by a client to a destination IP address; querying whether a traffic element in the preset mapping set exists in the target traffic, wherein the preset mapping set comprises multiple element groups, and each element group comprises a vulnerable scenario, a fuzzing test case, and an element score, the vulnerable scenario is a scenario triggering a security vulnerability in a historical process, and the fuzzing test case is a test case for detecting a security vulnerability of a system through automatically generated random data; wherein, in a case where a position where the fuzzing test case appears indicates that a scenario type is a form parameter value or a URL parameter value, a form parameter or a URL parameter in the target traffic is determined as the vulnerable scenario, wherein the position where the fuzzing test case appears refers to a position where the fuzzing test case carried by the target traffic appears in the target traffic; in a case where the position where the fuzzing test case appears indicates that the scenario type is a programming language tag, a parent object or a tag attribute where the fuzzing test case appears is determined as the vulnerable scenario according to a tag attribute of the programming language tag and a preset genetic algorithm; in a case where the position where the fuzzing test case appears indicates that the scenario type is a document type and the document type is a HyperText Markup Language (HTML) file, a tag where the fuzzing test case appears is determined as the vulnerable scenario; in a case where the traffic element in the preset mapping set exists in the target traffic, rewriting the service request based on a verification test case, and sending a new service request obtained after rewriting to the destination IP address, wherein case data of the verification test case does not attack the destination IP address, and the verification test case corresponds to a case calculation value; receiving a request response associated with the new service request, and in a case where the case calculation value appears in the request response, determining that a security label of the destination IP address is a vulnerability label.

2. The label determination method according to claim 1, characterized by, The step of receiving a service request comprises: obtaining request data in the service request; querying whether the fuzzing test case is included in the request data; in a case where the fuzzing test case is included in the request data, intercepting the service request.

3. The label determination method according to claim 1, characterized by, The step of querying whether a traffic element in a preset mapping set exists in the target traffic comprises: sorting all the element groups according to the score size of the element score to obtain a sorting result; according to the sorting result, matching element information carried by the target traffic with the multiple element groups included in the preset mapping set, wherein the element information comprises a fuzzing test case and / or a vulnerable scenario; in a case where a matching result indicates that the element information carried by the target traffic matches any element group successfully, confirming that the traffic element in the mapping set exists in the target traffic.

4. The label determination method according to claim 3, characterized by The step of matching the element information carried by the target traffic with the multiple element groups included in the preset mapping set comprises: obtaining a position where the fuzzing test case appears in the target traffic; determine a vulnerable scene based on the position-indicated scene type, wherein the scene type comprises at least one of the following: form parameter value / URL parameter value, programming language label, document type; determine whether the fuzzy test case and the vulnerable scene coexist in the element group in the preset mapping set.

5. The label determination method according to claim 1, characterized by, before rewriting the service request based on the verification test case, further comprising: parsing a traffic format associated with the target traffic in the service request; replacing a fuzzy test case carried in the target traffic with the verification test case according to the traffic format.

6. The label determination method according to claim 1, characterized by, after querying whether the traffic element in the preset mapping set exists in the target traffic, further comprising: in a case where it is determined that the traffic element in the preset mapping set exists in the target traffic, add a first numerical value to the element score of the element in the element group where the traffic element appears; or count the number of times of appearance of the vulnerable scene that successfully triggers a threat attack in the element group; and subtract a second numerical value from the element score of the element group in a case where the number of times of appearance is less than a preset number threshold within a preset period of query time.

7. An IP address label determination apparatus characterized by comprising: applied to an intermediate device, comprising: a receiving unit configured to receive a service request, wherein the service request carries target traffic sent by a client to a destination IP address; a querying unit configured to query whether a traffic element in a preset mapping set exists in the target traffic, wherein the preset mapping set contains multiple element groups, and each element group comprises a vulnerable scene, a fuzzy test case, and an element score, the vulnerable scene is a scene that triggers a security vulnerability in a historical process, and the fuzzy test case is a test case for detecting a security vulnerability of a system by automatically generating random data; the querying unit comprises: a second determination submodule configured to, in a case where a position where the fuzzy test case appears indicates that a scene type is a form parameter value or a URL parameter value, determine a form parameter or a URL parameter in the target traffic as the vulnerable scene, wherein the position where the fuzzy test case appears refers to a position where the fuzzy test case carried in the target traffic appears in the target traffic; a third determination submodule configured to, in a case where the position where the fuzzy test case appears indicates that the scene type is a programming language label, determine a parent object or a label attribute where the fuzzy test case appears as the vulnerable scene according to a label attribute of the programming language label and a preset genetic algorithm; and a fourth determination submodule configured to, in a case where the position where the fuzzy test case appears indicates that the scene type is a document type and the document type is a HyperText Markup Language (HTML) file, determine a label where the fuzzy test case appears as the vulnerable scene; a rewriting unit configured to, in a case where the traffic element in the preset mapping set exists in the target traffic, rewrite the service request based on a verification test case, and send a new service request obtained after the rewriting to the destination IP address, wherein case data of the verification test case does not attack the destination IP address, and the verification test case corresponds to a case calculation value. A label determining unit is configured to receive a request response associated with the new service request, and determine a security label of the destination IP address as a vulnerability label if the use case calculation value appears in the request response.

8. An electronic device, comprising: The method comprises: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the IP address label determining method of any one of claims 1 to 6 by executing the executable instructions.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium comprises a stored computer program, wherein the computer readable storage medium controls a device where the computer readable storage medium is located to perform the IP address label determining method of any one of claims 1 to 6 when the computer program is running.

Images