API injection attack identification method and device

Abstract

The invention provides an API injection attack identification method and device, and relates to the technical field of information security. The method comprises the following steps: performing character filtering and pattern matching on user input data to obtain an XPath injection feature recognition result; performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data to obtain a legality verification result of the content of the user input data; monitoring the user request behavior to obtain an abnormal operation detection result; monitoring node access depth and frequency of XPath query in the API request to obtain a suspicious behavior recognition result; and performing context consistency check on the current user request to obtain a suspicious request identification result. The device executes the method. According to the API injection attack identification method and device provided by the embodiment of the invention, the API injection attack can be accurately identified.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to an API injection attack identification method and device. Background Art

[0002] XPath injection is an attack method that manipulates and accesses XML data that should be protected by manipulating XPath queries generated by applications. XPath is a language used to query XML documents, similar to the role of SQL in relational databases. Attackers can bypass authentication, obtain sensitive data, or even modify data in XML documents by submitting malicious XPath expressions to APIs or web applications.

[0003] XPath injection is similar to SQL injection in that it manipulates data queries and results by constructing malicious input, but it has some unique characteristics due to the different structures of XML and XPath:

[0004] 1. XPath queries do not distinguish between data types, and all query contents are treated as strings. This means that in XPath injection, attackers do not need to worry about data types like SQL, and all injections can be completed simply by constructing strings.

[0005] 2. XPath allows arbitrary traversal of data through expressions. Attackers can access different parts of XML documents through parent nodes, child nodes, sibling nodes, etc. in the XPath query structure. Attackers can construct specific queries to traverse the entire XML document structure and even access the contents of different nodes.

[0006] 3. Similar to SQL injection, attackers can use Boolean conditions (such as or, and) to manipulate XPath queries so that the query conditions are always met, thus returning specific results. Through Boolean logic combinations, attackers can gradually approach the correct data.

[0007] 4. In XPath injection, attackers can use XPath expressions to access different node types, not only element nodes, but also attributes, text, parent nodes or child nodes, etc. For example, a query can be constructed to access the parent node or sibling node of a specific node to obtain more information.

[0008] Attackers can manipulate queries to bypass system authentication, enter protected areas or impersonate other users. By manipulating XPath queries, attackers can access sensitive data that should not be made public (such as usernames, passwords, etc.). In some cases, attackers can also use XPath injection to modify or delete XML data, causing greater damage. Summary of the invention

[0009] In view of the problems in the prior art, an embodiment of the present invention provides an API injection attack identification method and device, which can at least partially solve the problems in the prior art.

[0010] On the one hand, the present invention provides an API injection attack identification method, comprising:

[0011] Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results;

[0012] Performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data, to obtain a legality verification result of the user input data content;

[0013] Monitor user request behaviors and obtain abnormal operation detection results;

[0014] Monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results;

[0015] Perform context consistency check on the current user request to obtain suspicious request identification results.

[0016] The character filtering of the user input data includes:

[0017] Apply the filter function built based on the predefined filter rules to perform character filtering on the user input data;

[0018] The predefined filtering rules include quotation marks, logical operators, path navigation symbols and preset potentially dangerous characters that need to be filtered.

[0019] The pattern matching of the user input data after character filtering is performed includes:

[0020] Applying a matching function built based on a predefined regular expression pattern to perform pattern matching on the user input data that has completed character filtering;

[0021] The predefined regular expression pattern includes Boolean logic, path navigation symbol combination logic, preset characters and preset injection mode.

[0022] The step of performing type constraint detection on each input field of the user input data includes:

[0023] Applying a type checking function constructed by predefined expected input types to perform type constraint detection on each input field of the user input data;

[0024] The predefined expected input types include a character string input type corresponding to user login information, an integer input type corresponding to a user ID and a page number, and a Boolean value input type corresponding to a status flag.

[0025] The performing semantic analysis on the user input data includes:

[0026] Performing semantic analysis on the user input data using a semantic analysis model constructed using a predefined legality standard;

[0027] The predefined legality standard includes preset input content corresponding to a preset input field type.

[0028] The monitoring of the node access depth and frequency of the XPath query in the API request includes:

[0029] Obtaining a first suspicious behavior identification result according to a first comparison result of the calculated node depth and a preset node depth threshold;

[0030] A second suspicious behavior identification result is obtained according to a second comparison result between the number of visits to the same node type within a preset time period and a preset number of visits threshold.

[0031] The performing of context consistency check on the current user request includes:

[0032] Performing a context consistency check on the current user request based on a predefined context consistency standard;

[0033] The predefined context consistency criteria include that a request from a logged-in user should not require login information again, and that the user's request in a target page is consistent with a function of the target page.

[0034] On the one hand, the present invention provides an API injection attack identification device, comprising:

[0035] The first acquisition unit is used to perform character filtering and pattern matching on the user input data to obtain an XPath injection feature recognition result;

[0036] A second acquisition unit is used to perform type constraint detection on each input field of the user input data, and to perform semantic analysis on the user input data to obtain a legality verification result of the user input data content;

[0037] The third acquisition unit is used to monitor the user request behavior and obtain abnormal operation detection results;

[0038] The first identification unit is used to monitor the node access depth and frequency of the XPath query in the API request to obtain a suspicious behavior identification result;

[0039] The second identification unit is used to perform a context consistency check on the current user request to obtain a suspicious request identification result.

[0040] In another aspect, an embodiment of the present invention provides an electronic device, including: a processor, a memory, and a bus, wherein:

[0041] The processor and the memory communicate with each other via the bus;

[0042] The memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the following method:

[0043] Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results;

[0044] Performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data, to obtain a legality verification result of the user input data content;

[0045] Monitor user request behaviors and obtain abnormal operation detection results;

[0046] Monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results;

[0047] Perform context consistency check on the current user request to obtain suspicious request identification results.

[0048] An embodiment of the present invention provides a non-transitory computer-readable storage medium, including:

[0049] The non-transitory computer-readable storage medium stores computer instructions, which cause the computer to execute the following method:

[0050] Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results;

[0051] Performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data, to obtain a legality verification result of the user input data content;

[0052] Monitor user request behaviors and obtain abnormal operation detection results;

[0053] Monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results;

[0054] Perform context consistency check on the current user request to obtain suspicious request identification results.

[0055] The API injection attack identification method and device provided by the embodiment of the present invention perform character filtering and pattern matching on user input data to obtain XPath injection feature identification results; perform type constraint detection on each input field of the user input data, and perform semantic analysis on the user input data to obtain the legality verification result of the user input data content; monitor user request behavior to obtain abnormal operation detection results; monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results; perform context consistency check on the current user request to obtain suspicious request identification results, and identify potential XPath injection attacks through multi-level technical means, especially based on the characteristics of XPath injection, and can accurately identify API injection attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0057] Figure 1 It is a flowchart of an API injection attack identification method provided by an embodiment of the present invention.

[0058] Figure 2 It is a structural diagram of an API injection attack identification device provided by an embodiment of the present invention.

[0059] Figure 3 A schematic diagram of the physical structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical scheme and advantages of the embodiments of the present invention more clear, the embodiments of the present invention are further described in detail below in conjunction with the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention. It should be noted that, in the absence of conflict, the embodiments in this application and the features in the embodiments can be combined with each other arbitrarily.

[0061] Explanation of related terms:

[0062] XPath injection: XPath injection is an attack technique against applications that use XPath for data query. XPath (XML Path Language) is a language used to address specific nodes in XML documents. It is similar to the role of SQL in relational databases and is used to select specific elements, attributes, or text content from XML documents.

[0063] Figure 1 FIG. 1 is a flow chart of an API injection attack identification method provided by an embodiment of the present invention. Figure 1 As shown, the API injection attack identification method provided by the embodiment of the present invention includes:

[0064] Step S1: Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results.

[0065] Step S2: Perform type constraint detection on each input field of the user input data, and perform semantic analysis on the user input data to obtain a legality verification result of the user input data content.

[0066] Step S3: Monitor the user request behavior and obtain abnormal operation detection results.

[0067] Step S4: monitor the node access depth and frequency of the XPath query in the API request to obtain suspicious behavior identification results.

[0068] Step S5: Perform a context consistency check on the current user request to obtain a suspicious request identification result.

[0069] In the above step S1, the device performs character filtering and pattern matching on the user input data to obtain the XPath injection feature recognition result. The device can be a computer device that executes the method, for example, a server. It should be noted that the acquisition and analysis of data involved in the embodiment of the present invention is authorized by the user. The character filtering of the user input data includes:

[0070] Apply the filter function built based on the predefined filter rules to perform character filtering on the user input data;

[0071] The predefined filtering rules include quotation marks, logical operators, path navigation symbols and preset potentially dangerous characters that need to be filtered.

[0072] Before all user requests enter the API, the input data submitted by the user is first preprocessed and a preliminary pattern analysis is performed based on the common features of XPath injection.

[0073] The character filtering is described as follows:

[0074] Perform basic character filtering on user input data, especially preliminary detection and filtering of XPath injection symbols (such as ',',or,and, / / , / *,.. / , etc.). The filtering at this stage is to capture special symbol combinations contained in the input that may be related to injection.

[0075] Character filtering can be implemented by following the steps below, aiming to identify and handle special characters and patterns related to XPath injection to reduce potential security risks:

[0076] Step 1: Define filtering rules:

[0077] First, identify the characters that need to be filtered. XPath injection symbols include:

[0078] quotation marks:',"

[0079] Logical operators: or, and

[0080] Path navigation symbols: / / , / *,.. /

[0081] Other potentially dangerous characters: ;,|,@

[0082] Step 2: Build the filter function:

[0083] Write a filtering function that uses regular expressions to match and replace dangerous characters. The function code is as follows:

[0084]

[0085]

[0086] Step 3: Apply the filter function:

[0087] Anywhere your API receives user input, call the above filter function to clean the input data, for example:

[0088] user_input = request.args.get('input') gets user input from the request

[0089] cleaned_input = filter_input (user_input) to filter characters

[0090] Step 4: Logging and warning:

[0091] Record the filtered input and trigger a security warning when necessary. The above "when necessary" may specifically include the same filtered character appearing more than a preset number of times, such as @ appears more than three times.

[0092] If potentially dangerous characters are detected to be filtered, the security team should be notified for further analysis, for example:

[0093] ifuser_input! =cleaned_input:

[0094] log_security_event(user_input) records the original input

[0095] alert_security_team() sends an alert

[0096] Perform pattern matching on user input data that completes character filtering, including:

[0097] Applying a matching function built based on a predefined regular expression pattern to perform pattern matching on the user input data that has completed character filtering;

[0098] The predefined regular expression pattern includes Boolean logic, path navigation symbol combination logic, preset characters and preset injection mode.

[0099] The pattern matching is described as follows:

[0100] Use predefined regular expressions to match the parts of user input that may constitute injection. Focus on checking those conditions that use Boolean logic (such as or and and) or involve unnecessary data traversal and node access symbols (such as .., / , @, etc.). The above "unnecessary data" includes user names and user passwords. At the same time, capture combined conditional expressions, such as 'or'1'='1' and other common injection attack features.

[0101] The implementation steps of pattern matching are as follows, which aims to capture the characteristics of user input that may constitute XPath injection through regular expressions.

[0102] Step 1: Define the regular expression pattern:

[0103] First, we need to identify the injection features and combinations that need to be matched. The following is the regular expression pattern:

[0104] Boolean logic: detect occurrences of or and and.

[0105] Path navigation symbol combination logic: detects combinations of symbols such as .., / , / / , etc.

[0106] Special characters (i.e. preset characters): capture symbols such as quotation marks and semicolons.

[0107] Common injection mode (ie, default injection mode): for example, 'or'1'='1'.

[0108] Step 2: Write the regular expression:

[0109] Write multiple regular expressions to match different injection patterns. The example patterns are as follows:

[0110] import re

[0111] Boolean logic mode

[0112] bool_logic_pattern=r"\b(or|and)\b"

[0113] Path navigation mode

[0114] path_navigation_pattern=r"(\.\. / | / / | / |\*)"

[0115] Special Character Mode

[0116] special_characters_pattern=r"[;'\"]"

[0117] Combined conditional pattern

[0118] injection_pattern=r"'[\t]*or[\t]*'[^']*'='1'"

[0119] Step 3: Build the matching function:

[0120] Write a function that uses the above regular expression to check user input to determine whether there are potential injection features. The sample pattern is as follows:

[0121] defdetect_injection(user_input):

[0122] Checking Boolean Logic

[0123] ifre.search(bool_logic_pattern,user_input,re.IGNORECASE):

[0124] return True

[0125] Check path navigation symbols

[0126] ifre.search(path_navigation_pattern,user_input):

[0127] returnTrue

[0128] Check for special characters

[0129] ifre.search(special_characters_pattern,user_input):

[0130] return True

[0131] Checking combined conditions

[0132] ifre.search(injection_pattern,user_input):

[0133] returnTrue

[0134] returnFalse

[0135] Step 4: Apply the matching function:

[0136] Where the API receives user input, call the detection function to evaluate the safety of the input. The sample mode is as follows:

[0137] user_input = request.args.get('input') gets user input from the request

[0138] ifdetect_injection(user_input):

[0139] log_security_event(user_input) records suspicious input

[0140] return "Potential injection detected",400 returns warning information

[0141] Step 5: Logging and subsequent processing:

[0142] When a potential injection pattern is detected, log the event and implement appropriate response measures, such as blocking the IP or notifying the security team.

[0143] In the above step S2, the device performs type constraint detection on each input field of the user input data, and performs semantic analysis on the user input data to obtain a legality verification result of the user input data content. The type constraint detection on each input field of the user input data includes:

[0144] Applying a type checking function constructed by predefined expected input types to perform type constraint detection on each input field of the user input data;

[0145] The predefined expected input types include a character string input type corresponding to user login information, an integer input type corresponding to a user ID and a page number, and a Boolean value input type corresponding to a status flag.

[0146] The type constraint detection is described as follows:

[0147] Make explicit type constraints on each API request parameter. Even if XPath itself does not distinguish between data types, the API needs to limit the input type in advance. For each input field, make sure they conform to the type expected by the system (such as string, integer, Boolean value, etc.). If Boolean operators (such as or, and) are detected in places where strings or numbers are expected, they should be immediately identified as potential injections.

[0148] The implementation steps of type constraints are as follows, which aim to ensure that each API request parameter conforms to the expected type and effectively prevent potential XPath injection.

[0149] Step 1: Define the expected input types:

[0150] First, clarify the expected type of each API request parameter, including but not limited to:

[0151] String: such as username, password, etc.

[0152] Integer: such as user ID, page number, etc.

[0153] Boolean values: such as status flags, etc.

[0154] Step 2: Write a type checking function:

[0155] Create a function to check whether the user input is of the expected type. This can be achieved by using Python's type checking mechanism. The example pattern is as follows:

[0156]

[0157] Step 3: Implement type constraint checking:

[0158] When processing an API request, call the type checking function for each input parameter to ensure that it conforms to the expected type. The example pattern is as follows:

[0159] user_input = request.args.get('username') gets user input from the request

[0160] iffnotis_valid_type(user_input,'string'):

[0161] return "Invalid input type for username", 400 returns error information

[0162] Step 4: Detect illegal characters and operators:

[0163] Combined with the previous character filtering and pattern matching, we further check whether the input contains Boolean operators and other potential injection characters. If the input parameter type is a string or a number and contains operators such as or and, it is determined to be a potential injection.

[0164] Step 5: Record and Feedback:

[0165] For input that does not conform to type constraints, the event is logged and detailed error information is returned to the user to help them understand the input format requirements.

[0166] The performing semantic analysis on the user input data includes:

[0167] Performing semantic analysis on the user input data using a semantic analysis model constructed using a predefined legality standard;

[0168] The predefined legality standard includes preset input content corresponding to a preset input field type.

[0169] The semantic analysis is described as follows:

[0170] Through semantic analysis based on natural language processing (NLP) technology, the logical structure of user input is parsed to check whether the logic of the input content meets the expectations of the application. For example, if the input is a username and password, analyze whether the input content attempts to construct a certain conditional branch to implement multi-condition traversal or Boolean logic attack. The input should not contain operators unrelated to the database or XML structure.

[0171] The implementation steps of content parsing and validity checking are as follows, which aim to ensure that the logical structure of user input meets the expectations of the application through semantic analysis, thereby effectively preventing potential XPath injection.

[0172] Step 1: Define legality criteria:

[0173] First, clarify the legitimacy standards for each input field. For username and password, define the following standards:

[0174] Username: can only contain letters, numbers, and underscores, and should not contain spaces or special characters.

[0175] Password: Should contain at least one letter, one number, and one special character and should be between 8 and 16 characters long.

[0176] Step 2: Build an NLP model or use existing tools:

[0177] You can use existing natural language processing libraries (such as spaCy, NLTK, or Transformers) to help parse the input. If conditions permit, you can train a simple model to identify inputs that do not conform to the expected logic. The example pattern is as follows:

[0178]

[0179]

[0180] Step 3: Parsing user input:

[0181] When the user submits data, the above criteria are applied for parsing. The following is an example of a parsing function:

[0182]

[0183] Step 4: Check for illegal logic in the input:

[0184] During parsing, check whether the input attempts to construct multi-conditional logic or use operators that are not related to the database / XML structure. For example, check whether it contains operators such as or and. The sample pattern is as follows:

[0185]

[0186] Step 5: Implement legality check:

[0187] In API request processing, call parsing and checking functions to verify the legitimacy of user input. The sample mode is as follows:

[0188]

[0189]

[0190] Step 6: Record and feedback:

[0191] For input that does not meet legality standards, log the event and provide a user-friendly error message so that the user understands the problem.

[0192] In the above step S3, the device monitors the user request behavior and obtains abnormal operation detection results. This can be achieved by building a user behavior baseline, as described below:

[0193] Establish a behavioral baseline for each user or user group, and record their request patterns when they normally access the API. For example, under normal circumstances, a user's login request usually only submits a valid username and password, and does not frequently access data using Boolean logic or path traversal. If a user suddenly sends an unusually complex query, especially one with unreasonable traversal requests or a large number of Boolean conditions, the system should consider this to be a potential injection attack.

[0194] The implementation steps for building a user behavior baseline are as follows, which aims to identify abnormal behaviors by recording the user's normal request patterns, thereby detecting potential XPath injection attacks.

[0195] Step 1: Identify key behavioral indicators:

[0196] First, identify the key behavioral indicators to monitor, including:

[0197] The frequency and type of login requests (such as username and password);

[0198] The frequency of API requests (e.g., number of requests per minute);

[0199] The complexity of the request content (such as the number of operators used, path navigation, etc.);

[0200] The user's operation history (such as recent API calls).

[0201] Step 2: Log User Activities:

[0202] Create a database table or logging mechanism for each user or user group to record their normal API requests. Each time a user sends a request, save the relevant information, such as:

[0203]

[0204]

[0205] Step 3: Analyze normal behavior patterns:

[0206] Regularly analyze the collected user activity data to establish a baseline of normal behavior. For example, you can calculate the average, maximum, and minimum number of requests for each user over a specific time period, as well as the complexity of the operators and paths used in the requests.

[0207] defanalyze_user_behavior(user_id):

[0208] activities = database.query (user_id = user_id) to obtain the activity records of the user

[0209] Analyze request types, frequency, etc.

[0210] request_types=[activity['request_type']for activity inactivities]

[0211] Further analysis of the complexity of the request content, etc.

[0212] Record statistical results

[0213] Step 4: Define a behavioral baseline:

[0214] Based on the analysis results, define a behavioral baseline for each user. For example, a user's normal login request may only contain a specific set of characters and will not contain Boolean logic or path traversal.

[0215]

[0216] Step 5: Real-time monitoring and comparison:

[0217] When a user sends a request, the deviation from the request's baseline is monitored in real time. If the complexity or frequency of the request exceeds a preset threshold, or contains Boolean operators and path navigation symbols, the request is marked as suspicious.

[0218]

[0219]

[0220] Another way to achieve this is as follows:

[0221] Identify behavioral anomalies by comparing the current request with the user's historical behavior. Focus on checking whether the request attempts to access different nodes in an unconventional way, use Boolean logic to bypass verification, or use special symbols to construct an attack path for data traversal. If a user suddenly changes his behavior pattern (such as from a simple single query to a complex condition combination query), further in-depth analysis should be conducted.

[0222] The implementation steps of historical behavior comparison and anomaly detection are as follows. The purpose is to identify potential abnormal behaviors by comparing the current request with the user's historical behavior, so as to timely discover and prevent XPath injection attacks.

[0223] Step 1: Collect and store user history:

[0224] Ensure that the system can effectively collect and store historical user behavior data, including detailed information of each API request. You can establish a user activity log database to record the following information:

[0225] User ID;

[0226] Request timestamp;

[0227] Request type;

[0228] Content of the request;

[0229] Request frequency;

[0230]

[0231] Step 2: Extract user behavior features:

[0232] Analyze user historical behavior and extract feature data to establish a behavior baseline, including:

[0233] The frequency and time patterns of requests (e.g., peak hours);

[0234] The complexity of the request (e.g., number of Boolean conditions, type of nodes accessed);

[0235] Type of request (e.g. login, data query);

[0236]

[0237]

[0238] Step 3: Calculate the characteristics of the current request:

[0239] When a user sends a new API request, the characteristics of the request are calculated, including the request type, complexity score, and comparison with historical behavior characteristics. The example mode is as follows:

[0240]

[0241] Step 4: Compare historical behavior:

[0242] Compare the characteristics of the current request with the historical behavior characteristics of the user to identify potential abnormal patterns. For example, if the complexity of the current request is significantly higher than the average complexity of the user, or the request type is not in the historical record, it can be marked as an anomaly. The example pattern is as follows:

[0243]

[0244] Step 5: Implement anomaly detection logic:

[0245] In API request processing, anomaly detection logic is executed in real time. Once an abnormal request is identified, the event should be recorded and corresponding measures should be taken, such as warning or blocking the request. The example mode is as follows:

[0246] user_id=request.args.get('user_id')

[0247] request_data=request.args.get('data')

[0248] current_features=calculate_current_request_features(request_data)

[0249] iffcompare_with_history(user_id,current_features):

[0250] log_security_event(request_data) records suspicious requests

[0251] return "Anomalous behavior detected", 400 returns a warning message

[0252] In the above step S4, the device monitors the node access depth and frequency of the XPath query in the API request to obtain suspicious behavior identification results. The monitoring of the node access depth and frequency of the XPath query in the API request includes:

[0253] Obtaining a first suspicious behavior identification result according to a first comparison result of the calculated node depth and a preset node depth threshold;

[0254] A second suspicious behavior identification result is obtained according to a second comparison result between the number of visits to the same node type within a preset time period and a preset number of visits threshold.

[0255] The in-depth monitoring of nodes is described as follows:

[0256] Analyze the XPath query structure involved in the API request and limit the node depth that can be accessed in a single request. If it is detected that the user request contains node traversal operations across multiple levels, especially attempting to access the parent node through the .. / operator, or using a large number of wildcards (such as / / ) to access multiple nodes, it should be immediately identified as suspicious behavior.

[0257] The implementation steps of node depth and level restrictions are as follows, which aim to analyze the XPath query structure in the API request and effectively limit the accessible node depth to prevent potential XPath injection attacks.

[0258] Step 1: Define the depth limit criteria:

[0259] First, set the acceptable node depth limit. This can be adjusted according to the application needs and data structure. For example, the maximum allowed depth can be set to 5 levels.

[0260] Step 2: Parse the XPath query in the request:

[0261] When a user submits a request, the XPath query structure contained in the request is parsed to extract the node access path and depth information. This can be achieved using regular expressions or parsing libraries.

[0262] import re

[0263] defextract_node_paths(xpath_query):

[0264] Extract node path using regular expression

[0265] returnre.findall(r'( / [^ / ]+)',xpath_query) extracts each node

[0266] Step 3: Calculate the node depth:

[0267] The depth of the node is calculated based on the extracted node path, and a check is made as to whether the depth exceeds the set maximum depth.

[0268] defcalculate_depth(node_paths):

[0269] returnlen(node_paths) depth is the number of nodes

[0270] Step 4: Detect illegal node operations:

[0271] Analyze the node access operations in the request to detect whether they contain cross-layer access or illegal wildcard usage. Pay special attention to the following situations:

[0272] Use the .. / operator to try to access the parent node.

[0273] Use lots of / / wildcards for fuzzy matching.

[0274]

[0275] Step 5: Implement depth and manipulation detection:

[0276] In the process of API request processing, the above steps are combined to detect the node depth and illegal operations of the request in real time. Once the depth limit or illegal operation is detected, it is marked as suspicious behavior and corresponding measures are taken.

[0277]

[0278] Step 6: Record and feedback:

[0279] For each suspicious request, detailed information is recorded and warning information is fed back to the user to help the user understand the restrictions and specifications of the request.

[0280] log_security_event(xpath_query) logs the original query

[0281] return "Request rejected: depth limit exceeded or illegal operations detected", 400 returns detailed error information.

[0282] The description of node access frequency monitoring is as follows:

[0283] Detect injection attempts by monitoring the frequency of users' access to specific node types. Normally, users' API requests are usually concentrated on a specific data level, but injection attackers may try to detect system vulnerabilities by repeatedly querying different nodes. If a user frequently accesses nodes at multiple levels in a short period of time or attempts to obtain the properties of different nodes, the system should mark this behavior as a potential attack.

[0284] The implementation steps of node access frequency monitoring are as follows, which aims to identify potential XPath injection attacks by monitoring the frequency of users accessing specific node types.

[0285] Step 1: Define monitoring indicators:

[0286] First, set key indicators for monitoring, including:

[0287] Node access frequency: the number of times a user visits a node within a specific time period.

[0288] Node type: the type of node being accessed, such as user information, product details, etc.

[0289] Step 2: Establish an access record mechanism:

[0290] Create an access record for each user, recording the user's access information to each node type, including access time, node path, and access frequency.

[0291] fromcollections import defaultdict

[0292] importtime

[0293] #Assume that memory or database is used to store access records

[0294] access_log=defaultdict(lambda:defaultdict(list))#{user_id:{node_type:[timestamps]}}

[0295] deflog_node_access(user_id,node_type):

[0296] timestamp = time.time()

[0297] access_log[user_id][node_type].append(timestamp)

[0298] Step 3: Set the access frequency threshold:

[0299] Define the threshold of access frequency, for example, the number of accesses to the same node type within one minute shall not exceed 5 times. The threshold can be adjusted according to the specific situation.

[0300] FREQUENCY_THRESHOLD = 5 # Maximum number of visits per minute

[0301] TIME_WINDOW=60#Time window, unit: seconds

[0302] Step 4: Monitor user access behavior:

[0303] When a user visits a node, record their visit behavior and check the access frequency. Ensure that only the visits within the current time period are counted by removing old records that are out of the time window.

[0304] defcheck_access_frequency(user_id,node_type):

[0305] current_time = time.time()

[0306] #Remove old records that exceed the time window

[0307] access_log[user_id][node_type]=[t for t inaccess_log[user_id][node_type]ift>current_time TIME_WINDOW]

[0308] # Calculate the current number of visits

[0309] returnlen(access_log[user_id][node_type])

[0310] Step 5: Implement monitoring and early warning mechanisms:

[0311] During API request processing, the user's access frequency is monitored in real time. Once the number of accesses exceeds the set threshold, the behavior is marked as suspicious and corresponding measures are taken.

[0312]

[0313] Step 6: Record and feedback:

[0314] For each request marked as suspicious, detailed information is recorded and a warning message is fed back to the user to help the user understand the access restrictions.

[0315] log_security_event(node_type)#Record node access information

[0316] return"Request rejected:excessive access frequency detected",400#Return detailed error information.

[0317] In the above step S5, the device performs a context consistency check on the current user request to obtain a suspicious request identification result. The context consistency check on the current user request includes:

[0318] Performing a context consistency check on the current user request based on a predefined context consistency standard;

[0319] The predefined context consistency criteria include that a request from a logged-in user should not require login information again, and that the user's request in a target page is consistent with a function of the target page.

[0320] The instructions are as follows:

[0321] Check that the data requested by the current user is consistent with their session state, logged-in identity, or the page being visited. For example, if the user has successfully logged in, their subsequent requests should not contain complex conditional expressions that attempt to obtain authentication information again. If context inconsistencies are detected, the system should further check to determine if there is an injection attempt.

[0322] The implementation steps of the request context consistency check are as follows, which aims to identify potential XPath injection attacks by checking the consistency of the user request with its session state, logged-in identity or currently visited page.

[0323] Step 1: Define contextual consistency criteria:

[0324] Make it clear when a user's request should be consistent with its context, for example:

[0325] Requests from logged in users should not require login information again;

[0326] On a particular page, the user's request should match the functionality of that page.

[0327] Step 2: Get user context information:

[0328] When a user logs in or visits a specific page, relevant contextual information is recorded, including user identity, current page state, and session data.

[0329]

[0330] Step 3: Analyze the request content:

[0331] When a user submits a request, the request content is analyzed to check whether there is any inconsistency with the context information, with special attention paid to whether the request contains sensitive information or complex expressions that are inconsistent with the current status.

[0332]

[0333]

[0334] Step 4: Implement consistency check:

[0335] In API request processing, we implement a request context consistency check. Once we find that a request is inconsistent with the context, we mark the request as suspicious and take appropriate measures.

[0336]

[0337] Step 5: Record and feedback:

[0338] For each request marked as suspicious, detailed information is recorded and warning information is fed back to the user to help them understand the restrictions and context requirements of the request.

[0339] log_security_event(request_data)#Record the original request

[0340] return "Requestrejected:" + message, 400 # Return detailed error information

[0341] Through these steps, the request context consistency check can effectively identify potential injection attacks and enhance the security of the system.

[0342] Further, the log and feedback mechanism can be implemented as follows:

[0343] Whenever a suspicious request is detected, the system will immediately generate detailed logs to record the user's input, matching injection patterns, and related context information. By integrating with security experts or automated system feedback mechanisms, suspicious requests can be manually reviewed or automatically blocked in a timely manner.

[0344] The implementation steps of the real-time log and feedback mechanism are as follows, which aims to ensure that whenever a suspicious request is detected, the system can generate detailed logs and take corresponding measures in a timely manner.

[0345] Step 1: Define logging criteria:

[0346] Determine the log information that needs to be recorded, including:

[0347] User ID;

[0348] Request timestamp;

[0349] Content of the request;

[0350] Suspicious patterns detected;

[0351] Contextual information (such as user status, current page);

[0352] Step 2: Create a logging system:

[0353] Design and implement a logging system to record information about suspicious requests in a database or log file to ensure the traceability and security of the logs.

[0354]

[0355] Step 3: Integrate suspicious request detection logic:

[0356] During the API request processing, when a suspicious request is detected, the logging function is called to record relevant information.

[0357]

[0358]

[0359] Step 4: Implement feedback mechanism:

[0360] Establish a feedback mechanism, which can be automated or manual, to ensure that suspicious requests are handled promptly. This can be integrated into the security monitoring system, or use a message queue system to notify the security team for manual review.

[0361]

[0362] Step 5: Automatically block suspicious requests:

[0363] After detecting a suspicious request, the system can choose to automatically block the request to avoid potential attacks.

[0364]

[0365] Through these steps, the real-time log and feedback mechanism can effectively record suspicious requests and handle them in a timely manner, thereby enhancing the security of the system.

[0366] After obtaining the suspicious request identification result, the following steps may be performed: marking the attack source and taking subsequent measures to protect the system security.

[0367] Once a request is identified as an XPath injection attack, the system will quickly take emergency measures to block further execution of the request to the API and notify the administrator.

[0368] The following are instructions for request blocking:

[0369] Immediately terminate suspicious requests and return an error message to the user, while avoiding leaking internal system information. The blocking operation should be limited to the request to prevent further impact on the normal operation of the system.

[0370] The implementation steps of request blocking are as follows, which are designed to ensure that when a suspicious request is detected, the system can immediately terminate the request and return an appropriate error message to the user to avoid leaking internal system information.

[0371] Step 1: Define blocking criteria:

[0372] Specify what kind of requests should be blocked, for example:

[0373] Detected XPath injection features;

[0374] The context consistency check failed;

[0375] Exceeded access frequency limit.

[0376] Step 2: Design the error message:

[0377] Prepare a common error message format to avoid leaking any system internal information and ensure that users can understand the cause of the error but do not get sensitive information.

[0378]

[0379] Step 3: Implement request blocking:

[0380] In the request processing logic, combined with the detection mechanism in the previous step, when a suspicious request is found, the blocking function is called to terminate the request and return an appropriate error message.

[0381]

[0382]

[0383] Step 4: Ensure there are no side effects:

[0384] While blocking the request, ensure that other system functions will not be affected. Through design, it is ensured that the termination of the request is only for suspicious requests and does not affect the normal user operations.

[0385]

[0386] Step 5: Recording and Monitoring:

[0387] For each blocked request, log detailed information for subsequent analysis and monitoring. Make sure the logged information does not include sensitive data.

[0388]

[0389] Through these steps, request blocking can effectively prevent suspicious requests from affecting the normal operation of the system and improve the security of the system.

[0390] The following are the instructions for marking the attack source and subsequent tracking:

[0391] Mark the source of the attack (such as IP address, user ID, etc.) and take follow-up actions based on the severity of the attack, including banning related IP addresses, sending security warnings, etc. At the same time, record the attack behavior for subsequent analysis to help developers further enhance the security of the API.

[0392] The implementation steps for attack source marking and subsequent tracking are as follows, aiming to ensure that the attack source can be effectively marked and corresponding follow-up actions can be taken when an attack is detected.

[0393] Step 1: Define the marking criteria:

[0394] Clearly identify the information that needs to be marked, including:

[0395] The IP address of the attack source;

[0396] User ID;

[0397] Request timestamp;

[0398] Detected attack pattern.

[0399] Step 2: Create a tagging mechanism:

[0400] Implement a mechanism to mark and record information about the source of the attack to facilitate subsequent tracking and analysis.

[0401]

[0402] Step 3: Implement follow-up actions:

[0403] After an attack is detected, follow-up actions are taken based on the severity of the attack, such as blocking related IP addresses, sending security alerts to the security team, etc.

[0404]

[0405] Step 4: Block IP address:

[0406] Implement a blocking mechanism to prevent further requests from specific IPs to reduce system risks.

[0407] defblock_ip(ip_address):

[0408] #Assume that a database or firewall rule is used for IP blocking

[0409] add_ip_to_blocklist(ip_address)

[0410] Step 5: Send security alert:

[0411] Design a security early warning system to send attack information to the security team in a timely manner so that they can respond quickly.

[0412] defsend_security_alert(user_id,ip_address,detected_pattern):

[0413] alert_message="Security Alert:User{user_id}from IP{ip_address}triggered an attack pattern:{detected_pattern}"

[0414] #Send an alert (e.g. via email or messaging system)

[0415] send_alert(alert_message)

[0416] Step 6: Record the attack behavior:

[0417] All detected attack behaviors are recorded in a dedicated log or database for subsequent analysis and improvement of security policies.

[0418] defstore_attack_entry(attack_entry):

[0419] #Store the attack records in the database or log system

[0420] logging.info(attack_entry)#Example: Using logging

[0421] Through these steps, attack source marking and subsequent tracking can effectively improve the system's response capabilities to attacks, reduce potential threats, and provide a basis for subsequent security improvements.

[0422] The API injection attack identification method provided by the embodiment of the present invention identifies potential XPath injection attacks through multi-level technical means, especially based on the characteristics of XPath injection, including: no need for data type verification, data traversal, use of Boolean conditions, and access to multiple node types. This method uses a multi-step detection and processing mechanism to cover all aspects from user input analysis, pattern matching, behavior anomaly detection to log analysis to identify and prevent possible injection attacks.

[0423] The API injection attack identification method provided by the embodiment of the present invention has the following beneficial technical effects:

[0424] By explicitly limiting the types of API request parameters, the present invention effectively prevents type mismatch attacks. Even if XPath itself does not perform data type verification, API-level constraints can significantly reduce injection risks. At the same time, it can be combined with user session information to further ensure that the request meets the expected state and reduce the possibility of unreasonable input.

[0425] Strictly limit the depth of XPath queries to prevent malicious users from exploring the system by traversing nodes too deeply. This preventive measure can effectively prevent security risks caused by traversal. By parsing the logical structure of user input, the system can detect complex traversal requests that do not conform to normal behavior, thereby identifying potential attacks in a timely manner.

[0426] By using regular expressions to detect Boolean logic operators in user input, the system can effectively capture common injection patterns (such as "or" or "and") and identify malicious requests in a timely manner. When suspicious requests using Boolean conditions are detected, the system can immediately record and take follow-up measures to improve response speed and accuracy.

[0427] User behavior baseline construction and anomaly detection: By establishing a baseline of normal user behavior, the system can identify unusual node access patterns, especially when users try to access nodes that are inconsistent with their behavior. By monitoring the frequency of users' access to specific nodes, the system can detect abnormal behavior in a timely manner and prevent attackers from probing vulnerabilities by frequently requesting different nodes.

[0428] The present invention combines multiple mechanisms such as input verification, context checking, behavior monitoring and real-time feedback to form a comprehensive protection system. Through real-time monitoring and log recording, the system can quickly respond to potential threats and reduce the probability of successful attacks. The implementation of each step has clear operability and executability, and is easy to deploy and maintain in a practical environment. Overall, the present invention enhances the security of the API and reduces the risk of attacks through systematic identification and protection of XPath injection characteristics.

[0429] The API injection attack identification method provided by the embodiment of the present invention performs character filtering and pattern matching on user input data to obtain XPath injection feature identification results; performs type constraint detection on each input field of the user input data, and performs semantic analysis on the user input data to obtain the legality verification result of the user input data content; monitors user request behavior to obtain abnormal operation detection results; monitors the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results; performs context consistency check on the current user request to obtain suspicious request identification results, and identifies potential XPath injection attacks through multi-level technical means, especially based on the characteristics of XPath injection, can accurately identify API injection attacks.

[0430] Furthermore, the character filtering of the user input data includes:

[0431] A filtering function constructed based on predefined filtering rules is applied to perform character filtering on the user input data; this can be described with reference to the above embodiment and will not be described in detail.

[0432] The predefined filtering rules include quotation marks, logical operators, path navigation symbols and preset potentially dangerous characters that need to be filtered. Please refer to the above embodiment for description, and no further details will be given.

[0433] Furthermore, pattern matching is performed on the user input data after character filtering, including:

[0434] A matching function constructed based on a predefined regular expression pattern is applied to perform pattern matching on the user input data that has completed character filtering; the above-mentioned embodiment can be referred to for description and will not be described in detail.

[0435] The predefined regular expression pattern includes Boolean logic, path navigation symbol combination logic, preset characters and preset injection mode. Please refer to the above embodiment for description, and no further details will be given.

[0436] Furthermore, the performing type constraint detection on each input field of the user input data includes:

[0437] A type checking function constructed by applying predefined expected input types performs type constraint checking on each input field of the user input data; the description may refer to the above embodiment and will not be repeated here.

[0438] The predefined expected input types include a string input type corresponding to user login information, an integer input type corresponding to user ID and page number, and a Boolean input type corresponding to a status flag.

[0439] Furthermore, the performing semantic analysis on the user input data includes:

[0440] The semantic analysis model constructed by applying the predefined legality standard is used to perform semantic analysis on the user input data; the above-mentioned embodiment can be referred to for description and will not be described in detail.

[0441] The predefined legality standard includes a preset input content corresponding to a preset input field type. The above description can be referred to in the above embodiment and will not be repeated here.

[0442] Furthermore, monitoring the node access depth and frequency of the XPath query in the API request includes:

[0443] According to the first comparison result between the calculated node depth and the preset node depth threshold, a first suspicious behavior identification result is obtained; the description may refer to the above embodiment and will not be repeated here.

[0444] According to the second comparison result of the number of visits to the same node type within the preset time period and the preset number of visits threshold, a second suspicious behavior identification result is obtained.

[0445] Further, the context consistency check on the current user request includes:

[0446] A context consistency check is performed on the current user request based on a predefined context consistency standard; the description may refer to the above embodiment and will not be repeated here.

[0447] The predefined context consistency criteria include that the request of the logged-in user should not require login information again, and the request of the user in the target page is consistent with the function of the target page.

[0448] Figure 2 FIG. 1 is a schematic diagram of the structure of an API injection attack identification device provided by an embodiment of the present invention. Figure 2 As shown, the API injection attack identification device provided by the embodiment of the present invention includes a first acquisition unit 201, a second acquisition unit 202, a third acquisition unit 203, a first identification unit 204 and a second identification unit 205, wherein:

[0449] The first acquisition unit 201 is used to perform character filtering and pattern matching on the user input data to obtain the XPath injection feature recognition result; the second acquisition unit 202 is used to perform type constraint detection on each input field of the user input data, and perform semantic analysis on the user input data to obtain the legitimacy verification result of the user input data content; the third acquisition unit 203 is used to monitor the user request behavior to obtain the abnormal operation detection result; the first identification unit 204 is used to monitor the node access depth and frequency of the XPath query in the API request to obtain the suspicious behavior recognition result; the second identification unit 205 is used to perform context consistency check on the current user request to obtain the suspicious request recognition result.

[0450] Specifically, the first acquisition unit 201 in the device is used to perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results; the second acquisition unit 202 is used to perform type constraint detection on each input field of the user input data, and perform semantic analysis on the user input data to obtain the legitimacy verification result of the user input data content; the third acquisition unit 203 is used to monitor user request behavior to obtain abnormal operation detection results; the first identification unit 204 is used to monitor the node access depth and frequency of the XPath query in the API request to obtain suspicious behavior recognition results; the second identification unit 205 is used to perform context consistency check on the current user request to obtain suspicious request recognition results.

[0451] The API injection attack identification device provided by the embodiment of the present invention performs character filtering and pattern matching on user input data to obtain XPath injection feature identification results; performs type constraint detection on each input field of the user input data, and performs semantic analysis on the user input data to obtain the legality verification result of the user input data content; monitors user request behavior to obtain abnormal operation detection results; monitors the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results; performs context consistency check on the current user request to obtain suspicious request identification results, and identifies potential XPath injection attacks through multi-level technical means, especially based on the characteristics of XPath injection, can accurately identify API injection attacks.

[0452] The embodiment of the API injection attack identification device provided in the embodiment of the present invention can be specifically used to execute the processing flow of the above-mentioned method embodiments. Its functions are not repeated here, and reference can be made to the detailed description of the above-mentioned method embodiments.

[0453] Figure 3 A schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as Figure 3 As shown, the electronic device includes: a processor (processor) 301, a memory (memory) 302 and a bus 303;

[0454] The processor 301 and the memory 302 communicate with each other via the bus 303;

[0455] The processor 301 is used to call the program instructions in the memory 302 to execute the methods provided by the above method embodiments, for example, including:

[0456] Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results;

[0457] Performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data, to obtain a legality verification result of the user input data content;

[0458] Monitor user request behaviors and obtain abnormal operation detection results;

[0459] Monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results;

[0460] Perform context consistency check on the current user request to obtain suspicious request identification results.

[0461] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer can perform the methods provided by the above method embodiments, for example, including:

[0462] Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results;

[0463] Performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data, to obtain a legality verification result of the user input data content;

[0464] Monitor user request behaviors and obtain abnormal operation detection results;

[0465] Monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results;

[0466] Perform context consistency check on the current user request to obtain suspicious request identification results.

[0467] This embodiment provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program enables the computer to execute the methods provided by the above method embodiments, for example, including:

[0468] Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results;

[0469] Performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data, to obtain a legality verification result of the user input data content;

[0470] Monitor user request behaviors and obtain abnormal operation detection results;

[0471] Monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results;

[0472] Perform context consistency check on the current user request to obtain suspicious request identification results.

[0473] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented 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.

[0474] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0475] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0476] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0477] In the description of this specification, the description with reference to the terms "one embodiment", "a specific embodiment", "some embodiments", "for example", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0478] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for identifying an API injection attack, characterized in that: include: Perform character filtering and pattern matching on user input data to obtain XPath injection feature recognition results; Performing type constraint detection on each input field of the user input data, and performing semantic analysis on the user input data, to obtain a legality verification result of the user input data content; Monitor user request behaviors and obtain abnormal operation detection results; Monitor the node access depth and frequency of XPath queries in API requests to obtain suspicious behavior identification results; Perform context consistency check on the current user request to obtain suspicious request identification results.

2. The API injection attack identification method according to claim 1, characterized in that: The character filtering of the user input data includes: Apply the filter function built based on the predefined filter rules to perform character filtering on the user input data; The predefined filtering rules include quotation marks, logical operators, path navigation symbols and preset potentially dangerous characters that need to be filtered.

3. The API injection attack identification method according to claim 1, characterized in that: Perform pattern matching on user input data that completes character filtering, including: Applying a matching function built based on a predefined regular expression pattern to perform pattern matching on the user input data that has completed character filtering; The predefined regular expression pattern includes Boolean logic, path navigation symbol combination logic, preset characters and preset injection mode.

4. The API injection attack identification method according to claim 1, characterized in that: The performing type constraint detection on each input field of the user input data includes: Applying a type checking function constructed by predefined expected input types to perform type constraint detection on each input field of the user input data; The predefined expected input types include a character string input type corresponding to user login information, an integer input type corresponding to a user ID and a page number, and a Boolean value input type corresponding to a status flag.

5. The API injection attack identification method according to claim 1, characterized in that: The performing semantic analysis on the user input data includes: Performing semantic analysis on the user input data using a semantic analysis model constructed using a predefined legality standard; The predefined legality standard includes preset input content corresponding to a preset input field type.

6. The API injection attack identification method according to claim 1, characterized in that: The monitoring of the node access depth and frequency of the XPath query in the API request includes: Obtaining a first suspicious behavior identification result according to a first comparison result of the calculated node depth and a preset node depth threshold; A second suspicious behavior identification result is obtained according to a second comparison result between the number of visits to the same node type within a preset time period and a preset number of visits threshold.

7. The API injection attack identification method according to claim 1, characterized in that: The context consistency check on the current user request includes: Performing a context consistency check on the current user request based on a predefined context consistency standard; The predefined context consistency criteria include that a request from a logged-in user should not require login information again, and that the user's request in a target page is consistent with a function of the target page.

8. An API injection attack identification device, characterized in that: include: The first acquisition unit is used to perform character filtering and pattern matching on the user input data to obtain an XPath injection feature recognition result; A second acquisition unit is used to perform type constraint detection on each input field of the user input data, and to perform semantic analysis on the user input data to obtain a legality verification result of the user input data content; The third acquisition unit is used to monitor the user request behavior and obtain abnormal operation detection results; The first identification unit is used to monitor the node access depth and frequency of the XPath query in the API request to obtain a suspicious behavior identification result; The second identification unit is used to perform a context consistency check on the current user request to obtain a suspicious request identification result.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images