Training Method and Device for Business Logic Vulnerability Attack Detection Model

Abstract

This application discloses a training method and apparatus for a business logic vulnerability attack detection model, belonging to the field of network security technology. The method includes: acquiring first business-related data recorded during the historical execution of business logic with different attack tags, where the attack tags include attacks that exhibit business logic vulnerabilities and attacks that do not; extracting attack feature data from the first business-related data to obtain training samples including attack tags and feature data, where the attack feature data represents features related to whether business logic vulnerability attacks exist; using the attack feature data as input to the business logic vulnerability attack detection model; and training the model with the output of corresponding attack tags as the target. This effectively improves the accuracy and efficiency of detecting business logic vulnerability attacks.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method and apparatus for training a business logic vulnerability attack detection model. Background Technology

[0002] Due to rapid business development and the continuous acceleration of application version iterations, coupled with varying levels of development skills among developers, there may be instances where insufficient consideration leads to flawed or overly complex program logic. This can result in some logic branches failing to process properly or processing errors, leading to business logic vulnerabilities.

[0003] In many cases, malicious actors will scan a website for vulnerabilities in its programs to attack it, exploiting existing business logic vulnerabilities to cause information leaks or significant business losses. Because these attacks often lack obvious characteristics or occur infrequently, existing security products or alerts are insufficient for effectively and promptly detecting potential business logic vulnerability attacks. Furthermore, current detection methods often rely on manual probing, which is not only wasteful of manpower and resources but also inaccurate and inefficient.

[0004] Therefore, improving the accuracy and efficiency of detecting attacks that exploit business logic vulnerabilities is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] This application provides a method and apparatus for training a business logic vulnerability attack detection model, which improves the accuracy and efficiency of detecting business logic vulnerability attack behaviors.

[0006] In a first aspect, embodiments of this application provide a method for training a business logic vulnerability attack detection model, including:

[0007] Acquire the first business-related data recorded during the historical execution of business logic with different attack tags, wherein the attack tags include attack behaviors with business logic vulnerabilities and attack behaviors without business logic vulnerabilities;

[0008] Attack feature data is extracted from the first business-related data to obtain training samples including attack tags and feature data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business.

[0009] The attack feature data is used as input to the business logic vulnerability attack detection model, and the model is trained with the goal of outputting the corresponding attack labels.

[0010] In some embodiments, the first business-related data includes business request messages and business response messages recorded during the execution of business logic, session data recorded in the database, personal information data in the return packet, and the URL address of the access interface.

[0011] In some embodiments, the attack feature data includes static feature data, and before extracting the attack feature data from the first business-related data, it further includes:

[0012] The data source type of each first business-related data is parsed to determine whether the data source type of the parsed first business-related data meets the sample requirements.

[0013] Attack feature data is extracted from the data related to the first business, including:

[0014] The first business-related data whose data source type meets the sample requirements is determined as the first data. Static features are extracted from the first data according to the static feature extraction rules corresponding to the data source type. The static features are the basic attribute information in the first data used to characterize whether there are vulnerability attack behaviors in the business.

[0015] The first business-related data whose data source type does not meet the sample requirements is identified as the second data, and the second data is discarded.

[0016] In some embodiments, the data source type includes at least traffic log classes, access record classes of web application protection systems, and alarm output classes of security products used to identify sensitive data.

[0017] In some embodiments, static feature extraction is performed on the first data according to the static feature extraction rules corresponding to the data source type, including:

[0018] Based on the predefined basic attribute information corresponding to different data source types, traverse the first data and mark the static features belonging to the basic attribute information during the traversal process;

[0019] The static features of the tag are matched with the basic attribute information corresponding to the data source type to perform quality verification on the static features of the tag;

[0020] If the quality verification is successful, the marked static features are used as attack feature data; otherwise, the marked static features are corrected, and the corrected static features are used as attack feature data.

[0021] In some embodiments, the static features of the tag are matched with the basic attribute information corresponding to the data source type to perform quality verification of the static features of the tag, including:

[0022] By matching the marked static features with the basic attribute information corresponding to the data source type, it is determined whether the extracted static features are complete and whether the data structure of the static features is correct.

[0023] Correcting the static features of the marker includes:

[0024] Complete the missing static features in the static features of the marked item;

[0025] Incorrect data structures in the static features of the marked item are filled with default feature values.

[0026] In some embodiments, the attack signature data further includes statistical signature data;

[0027] After performing static feature extraction on the first data according to the static feature extraction rules corresponding to the data source type, the method further includes:

[0028] The statistical features are extracted from the first data, wherein the statistical features are obtained by statistically analyzing the abnormal static features that appear in the first data during the historical business logic operation.

[0029] In some embodiments, the attack feature data is used as input to a business logic vulnerability attack detection model, and model training is performed with the goal of outputting corresponding attack labels, including:

[0030] The training samples are used as a preset ratio as the training set, and the attack feature data in the training set are used as the input of the business logic vulnerability attack detection model. The model is trained with the goal of outputting the corresponding attack labels.

[0031] The remaining training samples other than the training set are used as the validation set. The attack feature data in the validation set are input into the business logic vulnerability attack detection model. The training effect is determined by comparing the output label of the business logic vulnerability attack detection model with the attack label in the validation set.

[0032] Once the preset convergence conditions are met, the current business logic vulnerability attack detection model will be determined as the initial detection model.

[0033] In some embodiments, after determining the current business logic vulnerability attack detection model as the initial detection model, the method further includes:

[0034] Retrieve second business-related data recorded during the execution of unlabeled business logic;

[0035] Attack feature data is extracted from the data related to the second business to obtain detection samples;

[0036] Input the detection sample into the initial detection model to obtain the attack tags corresponding to each second business-related data output;

[0037] The attack tags obtained by the user from the analysis of the data related to each of the second services are compared with the output attack tags. If the comparison results are inconsistent, the rules for extracting attack feature data are redefined.

[0038] In some embodiments, redefining the extraction rules for attack feature data when inconsistent comparison results are determined includes:

[0039] When the comparison results are found to be inconsistent, the feature data representing whether there is a vulnerability attack behavior in the second business-related data parsed by the user is compared with the attack feature data extracted from the second business-related data.

[0040] Based on the comparison results, the extraction rules for the attack feature data are updated.

[0041] In some embodiments, after updating the extraction rules for the attack feature data, the method further includes:

[0042] According to the updated attack feature data extraction rules, the updated attack feature data is extracted from the third business-related data to obtain training samples including attack tags and the updated attack feature data.

[0043] The updated attack feature data is used as the input to the initial detection model, and the model is trained with the goal of outputting the corresponding attack label.

[0044] Until the preset convergence conditions are met, the current initial detection model is determined as the final business logic vulnerability detection model.

[0045] In some embodiments, the business logic vulnerability attack detection model is the XGBoost model.

[0046] Secondly, embodiments of this application provide a detection method for business logic vulnerability attacks, including:

[0047] Acquire the fourth business-related data recorded during the process of obtaining the business logic to be tested;

[0048] Attack feature data is extracted from the fourth business-related data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business.

[0049] The attack feature data is input into the business logic vulnerability detection model obtained based on any of the business logic vulnerability attack detection model training methods described in the first aspect.

[0050] Based on the output of the business logic vulnerability detection model, it is determined whether the fourth business-related data contains any attack behavior targeting business logic vulnerabilities.

[0051] Thirdly, embodiments of this application provide a training apparatus for a business logic vulnerability attack detection model, comprising:

[0052] The first acquisition module is used to acquire first business-related data recorded during the historical execution of business logic with different attack tags. The attack tags include attack behaviors with business logic vulnerabilities and attack behaviors without business logic vulnerabilities.

[0053] The extraction module is used to extract attack feature data from the first business-related data to obtain training samples including attack tags and feature data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business.

[0054] The training module is used to take the attack feature data as input to the business logic vulnerability attack detection model and train the model with the goal of outputting the corresponding attack labels.

[0055] Fourthly, embodiments of this application provide a detection device for business logic vulnerability attacks, comprising:

[0056] The acquisition module is used to acquire the fourth business-related data recorded during the business logic process to be detected;

[0057] The extraction module is used to extract attack feature data from the fourth business-related data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business.

[0058] The input module is used to input the attack feature data into the business logic vulnerability detection model obtained based on any of the business logic vulnerability attack detection model training methods described in the first aspect.

[0059] The determination module is used to determine whether the fourth business-related data contains any attack behavior targeting business logic vulnerabilities, based on the output of the business logic vulnerability detection model.

[0060] Fifthly, embodiments of this application provide an electronic device, including:

[0061] Memory, used to store program instructions;

[0062] A processor is configured to invoke program instructions stored in the memory and execute the steps included in the method described in any one of the first or second aspects above, according to the obtained program instructions.

[0063] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a computer, cause the computer to perform the method described in any one of the first or second aspects.

[0064] In a seventh aspect, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first or second aspects.

[0065] In this embodiment, first business-related data recorded during the historical execution of business logic with different attack tags is obtained. Attack tags include attack behaviors that exhibit business logic vulnerabilities and those that do not. Attack feature data is extracted from the first business-related data to obtain training samples including attack tags and feature data. The attack feature data represents the characteristics related to whether business logic vulnerabilities exist. This attack feature data is used as input to a business logic vulnerability attack detection model, and the model is trained with the corresponding attack tags as the output. Thus, by extracting attack feature data from business data labeled with attack tags and using this attack feature data to train the business logic vulnerability attack detection model, the accuracy and efficiency of detecting business logic vulnerability attacks can be effectively improved. Attached Figure Description

[0066] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0067] Figure 1 A flowchart illustrating a method for training a business logic vulnerability attack detection model, as provided in this application embodiment;

[0068] Figure 2 A flowchart illustrating a detection method for business logic vulnerability attacks provided in this application embodiment;

[0069] Figure 3 A flowchart for attack feature extraction provided in an embodiment of this application;

[0070] Figure 4 A model training flowchart provided for an embodiment of this application;

[0071] Figure 5 A flowchart of the testing and calibration process for a model provided in this application embodiment;

[0072] Figure 6A schematic diagram of the structure of a business logic vulnerability attack detection model training device provided in this application embodiment;

[0073] Figure 7 A schematic diagram of the structure of a detection device for business logic vulnerability attacks provided in an embodiment of this application;

[0074] Figure 8 This is a schematic diagram of the hardware structure of an electronic device for implementing a training method for a business logic vulnerability attack detection model, provided in an embodiment of this application. Detailed Implementation

[0075] To improve the accuracy and efficiency of detecting attacks that exploit business logic vulnerabilities, this application provides a method and apparatus for training a business logic vulnerability attack detection model.

[0076] 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 a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0077] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0078] The data collection, dissemination, and use in this application all comply with relevant national laws and regulations.

[0079] For ease of understanding, the technical terms used in this application are as follows:

[0080] XGBoost is an optimized distributed gradient boosting library. It implements machine learning algorithms within the Gradient Boosting framework. XGBoost provides a parallel tree boosting approach that can quickly and accurately solve many data science problems.

[0081] Business logic vulnerabilities are caused by flawed or overly complex program logic, which leads to some logical branches not being processed correctly or processing errors. Such vulnerabilities are collectively referred to as business logic vulnerabilities.

[0082] The business logic vulnerability attack detection model training method and the detection method for business logic vulnerability attacks provided in this application can be applied to electronic devices, which may include terminals and servers. Specifically, the terminal may be a smartphone, tablet computer, computer, personal digital assistant (PDA), etc.; the server may be an application server or a web server. Furthermore, the business logic vulnerability attack detection model training method and the detection method for business logic vulnerability attacks can be executed on the same electronic device or on different electronic devices.

[0083] Figure 1 The flowchart illustrates a method for training a business logic vulnerability attack detection model, which includes the following steps, as provided in this application embodiment.

[0084] In step 101, the first business-related data recorded during the historical execution of business logic with different attack tags is obtained. The attack tags include attack behaviors with business logic vulnerabilities and attack behaviors without business logic vulnerabilities.

[0085] In practice, the first business-related data may include business request messages and business response messages recorded during the execution of business logic, session data recorded in the database, personal information data in the return packet, and URL addresses of access interfaces.

[0086] In specific implementation, it is possible to analyze in advance whether there is any attack behavior in each first business-related data, and to label each first business-related data according to the actual attack behavior. First business data with business logic vulnerability attack behavior is marked with an attack label, and first business data without business logic vulnerability attack behavior is marked with a non-attack label. Alternatively, "1" can be used to represent an attack label and "0" can be used to represent a non-attack label. Other identifiers can also be used to label the first business data. This application embodiment does not make specific limitations on this.

[0087] In step 102, attack feature data is extracted from the first business-related data to obtain training samples including attack tags and feature data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business.

[0088] In practice, attack feature data includes static feature data and statistical feature data. Static features represent the basic attribute information of whether a business has vulnerability attack behavior, while statistical features are obtained by statistically analyzing abnormal static features that appear in business-related data during the historical business logic operation. These features can provide a basis for judging whether a business has vulnerability attack behavior.

[0089] In practice, the data source type for the first business-related data may include traffic logs, access records from web application protection systems, alarm outputs from security products used to identify sensitive data, or business-related data from other data source types, without any limitation.

[0090] In practice, before extracting attack feature data from the first business-related data, the data source type of each first business-related data can be parsed to determine whether the data source type of each parsed first business-related data meets the sample requirements. The first business-related data whose data source type meets the sample requirements is designated as the first data. Then, when extracting attack feature data from the first business-related data, static feature extraction can be performed on the first data according to the static feature extraction rules corresponding to the data source type. The first business-related data whose data source type does not meet the sample requirements is designated as the second data and discarded. This screening of the data source type of the business-related data beforehand helps improve the quality of the samples, thereby improving the training effect of the model.

[0091] In practice, static feature extraction of the first data can be performed according to the following steps;

[0092] Step 1: Based on the predefined basic attribute information corresponding to different data source types, traverse the first data and mark the static features belonging to the basic attribute information during the traversal process.

[0093] Step 2: Perform quality verification on the static features of the tag by matching them with the basic attribute information corresponding to the data source type.

[0094] For example, by matching the static features of the marker with the basic attribute information corresponding to the data source type, it can be determined whether the extracted static features are complete and whether the data structure of the static features is correct. If the quality check fails, the static features of the marker are corrected. Specifically, this can be done by supplementing missing static features or by filling in default feature values ​​for incorrect data structures in the static features of the marker.

[0095] Step 3: After confirming that the quality verification has passed, use the marked static features as attack feature data.

[0096] In practice, after extracting static features from the first data, it is also necessary to extract statistical features. The extraction of statistical features can also be done by labeling, such as labeling statistical feature fields for the first data.

[0097] In step 103, the attack feature data is used as input to the business logic vulnerability attack detection model, and the model is trained with the goal of outputting the corresponding attack labels.

[0098] In practice, a predetermined proportion of the training samples can be used as the training set, for example, 80%. Attack feature data from the training set is used as input to the business logic vulnerability attack detection model, with the goal of outputting corresponding attack labels. The remaining training samples (excluding the training set) are used as the validation set, for example, the remaining 20%. Attack feature data from the validation set is input to the business logic vulnerability attack detection model, and the output labels of the business logic vulnerability attack detection model are compared with the attack labels in the validation set to determine the training effect. This process continues until a predetermined convergence condition is met, at which point the current business logic vulnerability attack detection model is determined as the initial detection model. The predetermined convergence condition could be, for example, the accuracy of the trained model exceeding a predetermined threshold (e.g., an accuracy threshold of 95%), or the model iteration count reaching a predetermined number. These conditions can be specifically set by technical personnel based on actual circumstances, and this application does not impose any limitations on them.

[0099] After obtaining the initial detection model, further verification can be performed to ensure the accuracy of the model.

[0100] In practice, the system can acquire second business-related data recorded during the execution of unlabeled business logic, extract attack feature data from the second business-related data to obtain detection samples, input the detection samples into the initial detection model, obtain the attack labels corresponding to each second business-related data output, and then obtain the attack labels obtained by the user from the analysis of each second business-related data and compare them with the output attack labels to verify the training effect of the model. If the comparison results are inconsistent, the rules for extracting attack feature data can be redefined.

[0101] Inconsistent comparison results may occur, for example, when detecting any second business-related data, the model outputs an attack label, while the user analysis yields a non-attack label; or, the model outputs a non-attack label, while the user analysis yields an attack label.

[0102] Therefore, in order to improve the accuracy of the model, when the comparison results are inconsistent, the feature data representing whether there is a vulnerability attack behavior in the second business-related data parsed by the user can be compared with the attack feature data extracted from the second business-related data. Based on the comparison results, the extraction rules of the attack feature data can be updated, such as adding attack feature data to the original attack feature data or deleting a certain attack feature data.

[0103] In practice, after updating the rules for extracting attack feature data, the updated attack feature data can be extracted from the third business-related data according to the updated rules. This yields training samples including attack tags and the updated attack feature data. Then, the updated attack feature data is used as input to the initial detection model, and the model is trained with the corresponding attack tags as the target, until a preset convergence condition is met. At this point, the current initial detection model is determined as the final business logic vulnerability detection model. The third business-related data here can be the first business-related data, the second business-related data, or a combination of both. It can also be other business-related data recorded during the historical execution of business logic with different attack tags that was not used as training samples; no limitation is made here.

[0104] In practical implementation, the business logic vulnerability detection model can use the XGBoost model, an optimized distributed gradient boosting library. It implements machine learning algorithms within the Gradient Boosting framework. XGBoost provides a parallel tree boosting approach that can quickly and accurately solve many data science problems. Machine learning is a multidisciplinary field encompassing probability theory, statistics, approximation theory, and complex algorithms. It uses computers as tools and aims to realistically simulate human learning, effectively improving learning efficiency by partitioning existing content into knowledge structures. This can further enhance the model's training speed.

[0105] In addition, after training is complete, the model file corresponding to the business logic vulnerability detection model can be saved in the database for the system to call when performing detection.

[0106] The embodiments of this application obtain a business logic vulnerability detection model through model training. Using this business logic vulnerability detection model can effectively improve the detection accuracy and efficiency of attack behaviors caused by business logic vulnerabilities.

[0107] Figure 2 The flowchart of a detection method for business logic vulnerability attacks provided in this application embodiment includes the following steps.

[0108] In step 201, the fourth business-related data recorded in the business logic process to be detected is obtained.

[0109] In step 202, attack feature data is extracted from the fourth business-related data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business.

[0110] In step 203, the attack feature data is input into the pre-trained business logic vulnerability attack detection model for detection.

[0111] In step 204, based on the output of the business logic vulnerability detection model, it is determined whether there are any attack behaviors targeting business logic vulnerabilities in the fourth business-related data.

[0112] By inputting the business-related data to be detected into a pre-trained business logic vulnerability attack detection model, the accuracy and efficiency of detecting business logic vulnerability attacks can be improved.

[0113] The following section uses the XGBoost model as an example to illustrate the implementation of this application, describing the model generation process through three stages: the preparation of training samples, the model training stage, and the model testing and calibration stage.

[0114] Phase 1: Preparation of training samples.

[0115] In practice, the first business-related data required for training the model can be labeled using existing labeling systems. This involves adding labels to specific types of data sources, indicating whether they target business logic vulnerabilities, based on their actual impact. Simultaneously, before model training, it's necessary to parse the corresponding logs from different data sources and extract attack characteristic data.

[0116] Attack feature data can be divided into non-statistical feature data (static feature data) and statistical feature data.

[0117] I. Non-statistical characteristics, as follows:

[0118] 1) Access source "s_real_ip" field;

[0119] 2) Access the source device identifier "s_device_id" field;

[0120] 3) The logged-in user "request_user" is confirmed by querying the database based on the session ID;

[0121] 4) Access the target URL "url" field;

[0122] 5) Whether login is required for accessing the target URL (tag 1): the "url_islogin" field;

[0123] 6) Check if the second tag of the target URL is a path accessible only to administrators: "url_isadmin"

[0124] Fields;

[0125] 7) Whether accessing the target URL's tag 3 will return personal or sensitive information: the "url_ispii" field;

[0126] 8) The fourth tag for accessing the target URL is the login page tag: the "url_login" field;

[0127] 9) Access status code (to check if data was actually accessed) 200 404 etc.: "response_code" field.

[0128] II. Statistical features, as follows:

[0129] 1) Abnormal device usage: Frequent switching of IP address "s_real_ip" for the same device "s_device_id" (such as using a proxy address pool);

[0130] 2) Abnormal device usage: Frequent switching between multiple devices with the same IP address "s_real_ip" and "s_device_id" was detected;

[0131] 3) Same origin (source address "s_real_ip", source device "s_device_id"), and also detected targeting "url_islogin (requires login), url_isadmin (administrator page), and url_ispii (sensitive information page)".

[0132] With a large number of accesses, the "response_code" has a high failure rate;

[0133] 4) If the IP address or device is the same as the user's, and there is no session-id or "request_user", accessing the pages that require login, such as "url_islogin", "url_isadmin", or "url_ispii";

[0134] 5) For IP addresses or devices with the same origin, accessing "url_islogin" and "url_isadmin" without having accessed "url_login" before.

[0135] The “url_ispii” page;

[0136] 6) Accessing different "response_user" information with the same "request_user";

[0137] 7) A large number of short-term accesses to a single page such as "url_islogin", "url_isadmin", or "url_ispii".

[0138] In practice, after determining the statistical and non-statistical features, attack feature extraction can be performed according to the following process: Figure 3 As shown, Figure 3 An attack feature extraction flowchart provided for an embodiment of this application includes the following steps.

[0139] In step 301, the first business-related data recorded during the historical execution of business logic with different attack tags is analyzed to determine the data source type. The attack tags include attack behaviors with business logic vulnerabilities and attack behaviors without business logic vulnerabilities.

[0140] For example, extracting the feature values ​​corresponding to the data source type fields.

[0141] In step 302, it is determined whether the data source type of the first business-related data meets the sample requirements. If yes, proceed to step 303; otherwise, proceed to step 306.

[0142] In step 303, non-statistical features are extracted from the first business-related data that meets the sample requirements according to the pre-set non-statistical feature extraction rules corresponding to the data source type.

[0143] In practice, the corresponding non-statistical feature extraction rules can be loaded according to the data source type, and then the first business-related data can be parsed according to the non-statistical feature extraction rules, such as JSON parsing or regular expression parsing.

[0144] In step 304, the extracted non-statistical features are subjected to quality verification.

[0145] For example, determining whether the extracted non-statistical features are complete and whether the data structure is correct, supplementing missing non-statistical features in the extracted non-statistical features, or filling in default feature values ​​for incorrect data structures in the extracted non-statistical features.

[0146] In step 305, after the quality verification is confirmed to be passed, statistical features are extracted from the first business-related data from which non-statistical features have been extracted, resulting in training samples including attack labels and feature data.

[0147] In practice, the first business-related data from which non-statistical and statistical features have been extracted can also be encoded to meet the input format of the model.

[0148] In step 306, the first business-related data whose data source type does not meet the sample requirements is discarded.

[0149] The second stage: model training stage.

[0150] In practice, after determining the training samples, the model can be trained according to the following process: Figure 4 As shown, Figure 4 A model training flowchart provided for an embodiment of this application includes the following steps.

[0151] In step 401, a preset proportion of training samples is used as the training set, and the attack feature data in the training set is used as the input of the XGBoost model. The model is trained with the goal of outputting the corresponding attack label.

[0152] In practice, for example, the parameters of the XGBoost algorithm are read, including the tree depth and the number of training rounds, and then the model is trained using the training set based on the algorithm parameters.

[0153] In step 402, the remaining training samples other than the training set are used as the validation set. The attack feature data in the validation set are input into the XGBoost model, and the output labels of the XGBoost model and the attack labels in the validation set are compared to determine the training effect.

[0154] In step 403, when the preset convergence condition is met, the current XGBoost model is determined as the initial detection model.

[0155] In practice, if the accuracy rate is higher than a preset threshold, such as 95%, the current XGBoost model is determined as the initial detection model, and the model file corresponding to the initial detection model is saved in the database for the system to call when performing detection.

[0156] Phase 3: Model testing and calibration phase.

[0157] In practice, after determining the initial detection model, the model can be tested and calibrated according to the following process: Figure 5 As shown, Figure 5 A flowchart for testing and calibration of a model provided in this application includes the following steps.

[0158] In step 501, the second business-related data recorded during the execution of unlabeled business logic is obtained.

[0159] In step 502, attack feature data is extracted from the second business-related data to obtain detection samples.

[0160] In step 503, the detection sample is input into the initial detection model to obtain the attack tags corresponding to each of the second business-related data output.

[0161] In step 504, the attack tags obtained by the user from the analysis of the data related to each second business are acquired and compared with the attack tags output by the initial detection model.

[0162] In step 505, it is determined whether the comparison results are consistent. If yes, proceed to step 506; otherwise, proceed to step 510.

[0163] In step 506, the feature data representing whether there is a vulnerability attack behavior in the second business-related data parsed by the user is compared with the attack feature data extracted from the second business-related data, and the extraction rules of the attack feature data are updated according to the comparison results.

[0164] In practice, the TOP-N output of the model can be analyzed to see if there are any attack behaviors that need attention, analyze the attack targets and methods, and assess the potential impact.

[0165] In step 507, according to the updated attack feature data extraction rules, the updated attack feature data is extracted from the third business-related data to obtain training samples including attack labels and updated attack feature data.

[0166] In step 508, the updated attack feature data is used as the input to the initial detection model, and the model is trained with the goal of outputting the corresponding attack label.

[0167] In step 509, the current initial detection model is determined as the final XGBoost model until the preset convergence condition is met.

[0168] In step 510, the current initial detection model is determined as the final XGBoost model.

[0169] In this way, by combining multi-dimensional features from both statistical and non-statistical perspectives, the accuracy of data analysis is improved. Effective training of the model obtained through these three stages increases the detection rate of such business logic vulnerability attacks, preventing greater business impact caused by these attacks being overlooked.

[0170] Based on the same technical concept, this application also provides a business logic vulnerability attack detection model training device. The principle of the business logic vulnerability attack detection model training device in solving the problem is similar to the above-mentioned business logic vulnerability attack detection model training method. Therefore, the implementation of the business logic vulnerability attack detection model training device can refer to the implementation of the business logic vulnerability attack detection model training method, and the repeated parts will not be described again.

[0171] Figure 6 This is a schematic diagram of the structure of a business logic vulnerability attack detection model training device provided in an embodiment of this application, including a first acquisition module 601, an extraction module 602, and a training module 603.

[0172] The first acquisition module 601 is used to acquire first business-related data recorded during the historical execution of business logic with different attack tags. The attack tags include attack behaviors with business logic vulnerabilities and attack behaviors without business logic vulnerabilities.

[0173] Extraction module 602 is used to extract attack feature data from the first business-related data to obtain training samples including attack tags and feature data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business.

[0174] The training module 603 is used to take the attack feature data as input to the business logic vulnerability attack detection model and train the model with the goal of outputting the corresponding attack labels.

[0175] In some embodiments, the first business-related data includes business request messages and business response messages recorded during the execution of business logic, session data recorded in the database, personal information data in the return packet, and the URL address of the access interface.

[0176] In some embodiments, the attack feature data includes static feature data, and before the extraction module 602 extracts the attack feature data from the first service-related data, it further includes:

[0177] The determination module 604 is used to parse the data source type of each first business-related data and determine whether the data source type of the parsed first business-related data meets the sample requirements.

[0178] The extraction module 602 is specifically used for:

[0179] The first business-related data whose data source type meets the sample requirements is determined as the first data. Static features are extracted from the first data according to the static feature extraction rules corresponding to the data source type. The static features are the basic attribute information in the first data used to characterize whether there are vulnerability attack behaviors in the business.

[0180] The first business-related data whose data source type does not meet the sample requirements is identified as the second data, and the second data is discarded.

[0181] In some embodiments, the data source type includes at least traffic log classes, access record classes of web application protection systems, and alarm output classes of security products used to identify sensitive data.

[0182] In some embodiments, the extraction module 602 is specifically used for:

[0183] Based on the predefined basic attribute information corresponding to different data source types, traverse the first data and mark the static features belonging to the basic attribute information during the traversal process;

[0184] The static features of the tag are matched with the basic attribute information corresponding to the data source type to perform quality verification on the static features of the tag;

[0185] If the quality verification is successful, the marked static features are used as attack feature data; otherwise, the marked static features are corrected, and the corrected static features are used as attack feature data.

[0186] In some embodiments, the extraction module 602 is specifically used for:

[0187] By matching the marked static features with the basic attribute information corresponding to the data source type, it is determined whether the extracted static features are complete and whether the data structure of the static features is correct.

[0188] Correcting the static features of the marker includes:

[0189] Complete the missing static features in the static features of the marked item;

[0190] Incorrect data structures in the static features of the marked item are filled with default feature values.

[0191] In some embodiments, the attack feature data further includes statistical feature data, and the extraction module 602 is further configured to:

[0192] The statistical features are extracted from the first data, wherein the statistical features are obtained by statistically analyzing the abnormal static features that appear in the first data during the historical business logic operation.

[0193] In some embodiments, the training module 603 is specifically used for:

[0194] The training samples are used as a preset ratio as the training set, and the attack feature data in the training set are used as the input of the business logic vulnerability attack detection model. The model is trained with the goal of outputting the corresponding attack labels.

[0195] The remaining training samples other than the training set are used as the validation set. The attack feature data in the validation set are input into the business logic vulnerability attack detection model. The training effect is determined by comparing the output label of the business logic vulnerability attack detection model with the attack label in the validation set.

[0196] Once the preset convergence conditions are met, the current business logic vulnerability attack detection model will be determined as the initial detection model.

[0197] In some embodiments, it also includes:

[0198] The second acquisition module 605 is used to acquire second business-related data recorded during the execution of unlabeled business logic after the training module 603 determines the current business logic vulnerability attack detection model as the initial detection model.

[0199] Attack feature data is extracted from the data related to the second business to obtain detection samples;

[0200] Input the detection sample into the initial detection model to obtain the attack tags corresponding to each second business-related data output;

[0201] The attack tags obtained by the user from the analysis of the data related to each of the second services are compared with the output attack tags. If the comparison results are inconsistent, the rules for extracting attack feature data are redefined.

[0202] In some embodiments, the second acquisition module 605 is specifically used for:

[0203] When the comparison results are found to be inconsistent, the feature data representing whether there is a vulnerability attack behavior in the second business-related data parsed by the user is compared with the attack feature data extracted from the second business-related data.

[0204] Based on the comparison results, the extraction rules for the attack feature data are updated.

[0205] In some embodiments, the training module 603 is further configured to:

[0206] According to the updated attack feature data extraction rules, the updated attack feature data is extracted from the third business-related data to obtain training samples including attack tags and the updated attack feature data.

[0207] The updated attack feature data is used as the input to the initial detection model, and the model is trained with the goal of outputting the corresponding attack label.

[0208] Until the preset convergence conditions are met, the current initial detection model is determined as the final business logic vulnerability detection model.

[0209] In some embodiments, the business logic vulnerability attack detection model is the XGBoost model.

[0210] Based on the same technical concept, this application also provides a detection device for business logic vulnerability attacks. The principle of the detection device for business logic vulnerability attacks is similar to that of the above-mentioned detection method for business logic vulnerability attacks. Therefore, the implementation of the detection device for business logic vulnerability attacks can refer to the implementation of the detection method for business logic vulnerability attacks, and the repeated parts will not be described again.

[0211] Figure 7 The present application provides a schematic diagram of a detection device for business logic vulnerability attacks, including an acquisition module 701, an extraction module 702, an input module 703, and a determination module 704.

[0212] The acquisition module 701 is used to acquire the fourth business-related data recorded during the business logic process to be detected;

[0213] Extraction module 702 is used to extract attack feature data from the fourth business-related data, wherein the attack feature data is feature data that characterizes whether there is a business logic vulnerability attack behavior in the business.

[0214] Input module 703 is used to input the attack feature data into the business logic vulnerability detection model obtained based on any of the above-mentioned business logic vulnerability attack detection model training methods;

[0215] The determination module 704 is used to determine whether the fourth business-related data contains any attack behavior targeting business logic vulnerabilities based on the output of the business logic vulnerability detection model.

[0216] The module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, other division methods are possible. Furthermore, the functional modules in each embodiment of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. Coupling between modules can be achieved through interfaces, typically electrical communication interfaces, but mechanical interfaces or other types of interfaces are also possible. Therefore, modules described as separate components may or may not be physically separate; they can be located in one place or distributed across different locations on the same or different devices. The integrated modules described above can be implemented in hardware or as software functional modules.

[0217] Having described any of the methods and apparatuses of the exemplary embodiments of this application, we will now describe an electronic device according to another exemplary embodiment of this application.

[0218] The following reference Figure 8 To describe an electronic device 130 implemented according to this embodiment of the present application. Figure 8 The electronic device 130 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0219] like Figure 8 As shown, the electronic device 130 is presented in the form of a general-purpose electronic device. The components of the electronic device 130 may include, but are not limited to: at least one processor 131, at least one memory 132, and a bus 133 connecting different system components (including memory 132 and processor 131).

[0220] Bus 133 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus structures.

[0221] The memory 132 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1321 and / or cache memory 1322, and may further include read-only memory (ROM) 1323.

[0222] The memory 132 may also include a program / utility 1325 having a set (at least one) of program modules 1324, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0223] Electronic device 130 can also communicate with one or more external devices 134 (e.g., keyboard, pointing device, etc.), and with one or more devices that enable a user to interact with electronic device 130, and / or with any device that enables electronic device 130 to communicate with one or more other electronic devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 135. Furthermore, electronic device 130 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 136. As shown, network adapter 136 communicates with other modules used in electronic device 130 via bus 133. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0224] In an exemplary embodiment, a storage medium is also provided, which enables the electronic device to perform any of the methods described above when a computer program in the storage medium is executed by a processor of the electronic device. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0225] In an exemplary embodiment, the electronic device of this application may include at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program executable by the at least one processor, and when the computer program is executed by the at least one processor, it enables the at least one processor to perform the steps of any method provided in the embodiments of this application.

[0226] In an exemplary embodiment, a computer program product is also provided, which, when executed by an electronic device, enables the electronic device to implement any of the exemplary methods provided in this application.

[0227] Furthermore, computer program products may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM), flash memory, optical fiber, compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0228] The program product for data querying in this application embodiment may be a CD-ROM and include program code, and may run on a computing device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program, which may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0229] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0230] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, radio frequency (RF), or any suitable combination thereof.

[0231] Program code for performing the operations of this application can be written using any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0232] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0233] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

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

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

[0236] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0237] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0238] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0239] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for training a business logic vulnerability attack detection model, characterized in that, include: Acquire the first business-related data recorded during the historical execution of business logic with different attack tags, wherein the attack tags include attack behaviors with business logic vulnerabilities and attack behaviors without business logic vulnerabilities; Attack feature data is extracted from the first business-related data to obtain training samples including attack tags and feature data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business. The attack feature data is used as input to the business logic vulnerability attack detection model, and the model is trained with the goal of outputting the corresponding attack labels. The attack feature data is used as input to the business logic vulnerability attack detection model, and the model is trained with the goal of outputting the corresponding attack labels, including: The training samples are used as a preset ratio as the training set, and the attack feature data in the training set are used as the input of the business logic vulnerability attack detection model. The model is trained with the goal of outputting the corresponding attack labels. The remaining training samples other than the training set are used as the validation set. The attack feature data in the validation set are input into the business logic vulnerability attack detection model. The training effect is determined by comparing the output label of the business logic vulnerability attack detection model with the attack label in the validation set. Until the preset convergence condition is met, the current business logic vulnerability attack detection model is determined as the initial detection model; After determining the current business logic vulnerability attack detection model as the initial detection model, it also includes: Retrieve second business-related data recorded during the execution of unlabeled business logic; Attack feature data is extracted from the data related to the second business to obtain detection samples; Input the detection sample into the initial detection model to obtain the attack tags corresponding to each second business-related data output; The attack tags obtained by the user from the analysis of the data related to each of the second services are compared with the output attack tags. If the comparison results are inconsistent, the rules for extracting attack feature data are redefined. When discrepancies are found in the comparison results, the rules for extracting attack feature data should be redefined, including: When the comparison results are found to be inconsistent, the feature data representing whether there is a vulnerability attack behavior in the second business-related data parsed by the user is compared with the attack feature data extracted from the second business-related data. Based on the comparison results, update the extraction rules for the attack feature data; After updating the extraction rules for the attack feature data, it also includes: According to the updated attack feature data extraction rules, the updated attack feature data is extracted from the third business-related data to obtain training samples including attack tags and the updated attack feature data. The updated attack feature data is used as the input to the initial detection model, and the model is trained with the goal of outputting the corresponding attack labels. Once the preset convergence conditions are met, the current initial detection model will be determined as the final business logic vulnerability detection model.

2. The method as described in claim 1, characterized in that, The first business-related data includes business request messages and business response messages recorded during the execution of business logic, session data recorded in the database, personal information data in the return packet, and URL addresses of access interfaces.

3. The method as described in claim 1, characterized in that, The attack feature data includes static feature data. Before extracting attack feature data from the first service-related data, it also includes: The data source type of each first business-related data is parsed to determine whether the data source type of the parsed first business-related data meets the sample requirements. Attack feature data is extracted from the data related to the first business, including: The first business-related data whose data source type meets the sample requirements is determined as the first data. Static features are extracted from the first data according to the static feature extraction rules corresponding to the data source type. The static features are the basic attribute information in the first data used to characterize whether there are vulnerability attack behaviors in the business. The first business-related data whose data source type does not meet the sample requirements is identified as the second data, and the second data is discarded.

4. The method as described in claim 3, characterized in that, The data source types include at least traffic logs, access records from web application protection systems, and alarm outputs from security products used to identify sensitive data.

5. The method as described in claim 3, characterized in that, According to the static feature extraction rules corresponding to the data source type, static feature extraction is performed on the first data, including: Based on the predefined basic attribute information corresponding to different data source types, traverse the first data and mark the static features belonging to the basic attribute information during the traversal process; The static features of the tag are matched with the basic attribute information corresponding to the data source type to perform quality verification on the static features of the tag; If the quality verification is successful, the marked static features are used as attack feature data; otherwise, the marked static features are corrected, and the corrected static features are used as attack feature data.

6. The method as described in claim 5, characterized in that, The static features of the tag are matched with the basic attribute information corresponding to the data source type to perform quality verification, including: By matching the marked static features with the basic attribute information corresponding to the data source type, it is determined whether the extracted static features are complete and whether the data structure of the static features is correct. Correcting the static features of the marker includes: Complete the missing static features in the static features of the marked item; Incorrect data structures in the static features of the marked item are filled with default feature values.

7. The method as described in claim 3, characterized in that, The attack signature data also includes statistical signature data; After performing static feature extraction on the first data according to the static feature extraction rules corresponding to the data source type, the method further includes: The statistical features are extracted from the first data, wherein the statistical features are obtained by statistically analyzing the abnormal static features that appear in the first data during the historical business logic operation.

8. The method according to any one of claims 1-7, characterized in that, The business logic vulnerability attack detection model is the XGBoost model.

9. A detection method for business logic vulnerability attacks, characterized in that, include: Acquire the fourth business-related data recorded during the process of obtaining the business logic to be tested; Attack feature data is extracted from the fourth business-related data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business. The attack feature data is input into the business logic vulnerability detection model obtained based on the business logic vulnerability attack detection model training method according to any one of claims 1 to 8; Based on the output of the business logic vulnerability detection model, it is determined whether the fourth business-related data contains any attack behavior targeting business logic vulnerabilities.

10. A training device for a business logic vulnerability attack detection model, characterized in that, include: The first acquisition module is used to acquire first business-related data recorded during the historical execution of business logic with different attack tags. The attack tags include attack behaviors with business logic vulnerabilities and attack behaviors without business logic vulnerabilities. The extraction module is used to extract attack feature data from the first business-related data to obtain training samples including attack tags and feature data. The attack feature data is feature data that characterizes whether the business has business logic vulnerability attack behavior. The training module is used to take the attack feature data as input to the business logic vulnerability attack detection model and train the model with the goal of outputting the corresponding attack labels. The training module is specifically used for: The training samples are used as a preset ratio as the training set, and the attack feature data in the training set are used as the input of the business logic vulnerability attack detection model. The model is trained with the goal of outputting the corresponding attack labels. The remaining training samples other than the training set are used as the validation set. The attack feature data in the validation set are input into the business logic vulnerability attack detection model. The training effect is determined by comparing the output label of the business logic vulnerability attack detection model with the attack label in the validation set. Until the preset convergence condition is met, the current business logic vulnerability attack detection model is determined as the initial detection model; The second acquisition module is used to acquire second business-related data recorded during the execution of unlabeled business logic after the training module determines the current business logic vulnerability attack detection model as the initial detection model. Attack feature data is extracted from the data related to the second business to obtain detection samples; Input the detection sample into the initial detection model to obtain the attack tags corresponding to each second business-related data output; The attack tags obtained by the user from the analysis of the data related to each of the second services are compared with the output attack tags. If the comparison results are inconsistent, the rules for extracting attack feature data are redefined. The second acquisition module is specifically used for: When the comparison results are found to be inconsistent, the feature data representing whether there is a vulnerability attack behavior in the second business-related data parsed by the user is compared with the attack feature data extracted from the second business-related data. Based on the comparison results, update the extraction rules for the attack feature data; The training module is also used for: According to the updated attack feature data extraction rules, the updated attack feature data is extracted from the third business-related data to obtain training samples including attack tags and the updated attack feature data. The updated attack feature data is used as the input to the initial detection model, and the model is trained with the goal of outputting the corresponding attack labels. Once the preset convergence conditions are met, the current initial detection model will be determined as the final business logic vulnerability detection model.

11. A detection device for business logic vulnerability attacks, characterized in that, include: The acquisition module is used to acquire the fourth business-related data recorded during the business logic process to be detected; The extraction module is used to extract attack feature data from the fourth business-related data. The attack feature data is feature data that characterizes whether there are business logic vulnerability attack behaviors in the business. The input module is used to input the attack feature data into the business logic vulnerability detection model obtained based on the business logic vulnerability attack detection model training method according to any one of claims 1 to 8. The determination module is used to determine whether the fourth business-related data contains any attack behavior targeting business logic vulnerabilities, based on the output of the business logic vulnerability detection model.

12. An electronic device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method according to any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1-9.

14. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the method according to any one of claims 1-9.

Images