Api resource identification method and electronic device

Abstract

The application discloses an API resource identification method and an electronic device, and belongs to the technical field of computers. The method comprises the following steps: acquiring multi-source API asset data; performing structural analysis and semantic analysis on the API path of the multi-source API asset data to obtain interface rule information; generating a candidate API interface path set based on the interface rule information, wherein the candidate API interface path set comprises at least one candidate API interface path; performing interface survivability verification on the candidate API interface paths in the candidate API interface path set, and determining a target API interface that is alive based on the survivability verification result.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an API resource identification method and electronic device. Background Technology

[0002] In the current field of Application Programming Interface (API) security governance, API asset identification and vulnerability verification are core aspects of ensuring system security.

[0003] Current API asset identification methods primarily rely on manual aggregation, export from API management platforms, parsing static documentation such as OpenAPI / Swagger, and passive collection based on API call traffic. These methods can only identify known API interfaces that are registered, documented, or have call traffic. For legacy interfaces that are not documented, not registered, have had no call traffic for a long time, test interfaces, and privately deployed interfaces, existing solutions cannot proactively discover them, easily creating blind spots in API asset coverage.

[0004] Therefore, existing technologies cannot proactively discover hidden API interfaces with no traffic or documentation during the API interface identification process. This results in low identification efficiency, insufficient accuracy, and incomplete API asset coverage, making it difficult to meet the comprehensive asset governance needs in multi-system, large-scale API call environments. Summary of the Invention

[0005] This application provides an API resource identification method and electronic device, which can solve the problems of existing technologies in the API interface identification process, such as the inability to actively discover hidden API interfaces with no traffic or documentation, resulting in low identification efficiency, insufficient accuracy, and incomplete API asset coverage.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: Firstly, an API resource identification method is provided, including: Obtain multi-source API asset data; The multi-source API asset data is subjected to structured parsing and semantic analysis of API paths to obtain interface rule information; A candidate API interface path set is generated based on the interface rule information, and the candidate API interface path set includes at least one candidate API interface path. Perform interface liveness verification on the candidate API interface paths in the candidate API interface path set, and determine the live target API interface based on the liveness verification results.

[0007] Secondly, an electronic device is provided, comprising a processor and a memory, wherein the memory stores at least one computer program, which is loaded and executed by the processor to implement the aforementioned API resource identification method.

[0008] The API resource identification method and electronic device provided in this application can extract general rules for interfaces from multiple dimensions by acquiring multi-source API asset data and performing structured parsing and semantic analysis. It can generate potential candidate interface paths without relying on manual sorting and interface traffic. Then, it can screen out the target API interfaces that are actually alive through liveness verification, realize the active identification of hidden API interfaces that are not registered, have no traffic, and have no documentation, improve the efficiency and accuracy of hidden API interface identification, expand the coverage of API assets, and make up for the asset identification blind spots in the existing technology.

[0009] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0011] Figure 1 A flowchart of the API resource identification method provided in an embodiment of this application is shown; Figure 2 This document illustrates a flowchart of the interface liveness verification and rule dynamic optimization process provided in an embodiment of this application. Figure 3 A flowchart illustrating the deep availability verification provided in an embodiment of this application is shown; Figure 4 A schematic diagram of the structure of the API resource identification device provided in an embodiment of this application is shown; Figure 5 A structural block diagram of an electronic device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0012] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0013] Existing technologies cannot proactively discover hidden API interfaces with no traffic or documentation during the API interface identification process. This results in low identification efficiency, insufficient accuracy, and incomplete API asset coverage, making it difficult to meet the comprehensive asset governance needs in multi-system, large-scale API call environments. To address the aforementioned problems in existing technologies, this application provides an API resource identification method.

[0014] The following will combine Figures 1 to 3 The API resource identification method provided in the embodiments of this application will be explained and described in detail. These embodiments are only used to explain this application and do not constitute a limitation on this application.

[0015] Figure 1 A flowchart of the API resource identification method provided in an embodiment of this application is shown. Figure 1 As shown, this API resource identification method mainly includes the following steps (S101-S104): S101. Obtain multi-source API asset data; In this embodiment, various types of data related to the API interface are collected from multiple sources to form a comprehensive and multi-dimensional initial API asset data set, providing a data foundation for subsequent rule learning and path generation.

[0016] In some embodiments, multi-source API asset data includes at least one of the following: interface routing rules of the development framework, standardized API interface description files, known API interface record data, asset ledger metadata, and front-end static resources. Of course, multi-source API asset data may also include interface call traffic logs, interface version information, deployment environment information, etc., and this application embodiment does not impose any limitations on this.

[0017] For example, (1) extract interface routing rules from development frameworks such as SpringBoot, Django, and FastAPI; (2) extract standardized interface descriptions from OpenAPI and Swagger documentation; (3) collect known API interface record data that has been launched and is running in the business system. For example, known API interface record data includes: interface path, HTTP request method, request and response parameter structure, call frequency and security attributes, etc., to supplement asset information; (4) import asset ledger or API management records, including metadata such as interface document path, version number, module, authentication method and interface status; automatically crawl and parse front-end static resources such as HTML pages, JavaScript scripts, configuration lists and third-party libraries, and extract implicit interface information such as hard-coded API paths, HTTP methods, request header templates and parameter fields through string constant scanning and network request code pattern recognition (such as fetch(" / api / ...") and axios.post(...)).

[0018] In this embodiment, asset data is collected from multiple dimensions and sources to ensure that the initial information is comprehensive and complete, avoiding the failure to discover hidden interfaces due to a single data source, and improving the accuracy of subsequent rule learning.

[0019] S102. Perform structured parsing and semantic analysis of API paths on multi-source API asset data to obtain interface rule information; In this step, after obtaining multi-source API asset data in step S101, the API path is structurally split and semantically extracted to extract the composition rules and naming characteristics of the interface, forming interface rule information.

[0020] In some embodiments, the interface rule information includes at least one of the following: interface path composition structure, business resource naming characteristics, operation semantic characteristics, parameter and field format characteristics, context path prefix characteristics, and formatting and naming convention characteristics. Of course, the interface rule information may also include request method constraints, return structure conventions, version rules, permission domain characteristics, etc., and this application embodiment does not impose any limitations on this.

[0021] In this embodiment, the interface path composition structure is used to form a general interface pattern template; business resource naming features such as user, order, payment, account, etc., are used to represent the core business object corresponding to the interface; operation semantic features such as create, query, update, delete, cancel, export, batch, etc., are used to reflect the functional behavior type of the interface; parameter and field format features infer the semantics and business purpose of the fields by recognizing keywords such as id, is, flag, enable, status, type, etc. appearing in the parameters; context path prefix features such as / admin / , / internal / , / partner / , / openapi / , etc., are used to distinguish the interface access domain or permission level; formatting and naming convention features identify the naming style of the interface path (such as underscore, camelCase, lowercase hyphen, etc.) and are used to standardize the path generation method.

[0022] For example, extract the business resource "user" and the operation semantic "query" from the path " / api / user / query"; extract the context prefix " / admin / " from " / admin / order / list"; extract parameter format features from the parameters "user_id", "order_id", and "status"; and identify whether the interface uses underscore, camelCase, or hyphen naming conventions.

[0023] Therefore, through the above steps, scattered API assets can be summarized into reusable and reasonable interface rule information based on the aforementioned semantic features and structural patterns, enabling the system to understand interface design habits and laying the foundation for subsequent intelligent generation of candidate paths.

[0024] S103. Generate a candidate API interface path set based on the interface rule information. The candidate API interface path set includes at least one candidate API interface path. In this step, based on the interface rule information obtained in step S102, candidate API interface paths that may exist but have not yet been discovered are generated through various path association and enumeration methods.

[0025] In some embodiments, generating a candidate API interface path set based on interface rule information includes generating a candidate API interface path set based on interface rule information through at least one of the following methods: (1) resource operation integrity completion, (2) cross-resource semantic extension, (3) template analogy replacement, (4) context prefix migration, and (5) parameterized path variant generation.

[0026] The following explains and illustrates the various path association and enumeration methods mentioned above.

[0027] (1) Resource operation integrity completion: When it is detected that a resource only has partial operation interfaces (such as / user / create and / user / query), the possible operation paths are automatically completed according to common RESTful design conventions, and candidate API interfaces are generated, such as / user / update, / user / delete, / user / list, / user / batch_update, etc.

[0028] (2) Cross-resource semantic extension: Based on common relationships between business objects (e.g., users and orders, orders and payments), and combined with existing interface naming conventions, generate composite interface paths across resources. For example, given / user / {id}, candidate API interfaces such as / user / {id} / orders or / order / {id} / payment can be deduced.

[0029] (3) Template analogy replacement: In existing path templates (e.g., generic interface pattern templates formed by the interface path composition structure in interface rule information), resource names or operation verbs are replaced by analogy to form interfaces with similar functions. For example, if / invoice / create is known and similar resources such as refund and credit_note exist in the system, then candidate API interfaces such as / refund / create and / credit_note / create can be generated.

[0030] (4) Context prefix shift: By analyzing the access partition logic, different context environments (such as ordinary user domains, management domains, and internal interface domains) can be identified. If / api / order / status exists in the user access domain, candidate API interfaces such as / admin / order / override or / internal / order / refund can also be constructed in the management domain to detect interfaces left over from development or reserved during the testing phase.

[0031] (5) Generation of parameterized path variants: For paths containing placeholders or parameters (such as / api / user / {id}), the system automatically generates typical call examples (such as / api / user / 1001, / api / user / admin) and generates path variations based on common engineering practices, such as case differences (User vs. user), singular / plural forms (order vs. orders), and spelling similarities (auth vs. authorize) for candidate API interfaces. For example, given / user / {id}, it generates candidate API interfaces such as / user / 1001, / user / admin, and / users / 1001.

[0032] Through the aforementioned multi-dimensional path association and enumeration strategies, a set of potential candidate API interface paths can be constructed based on existing API asset data and interface rule information, even in the absence of explicit documentation and traffic information. This enables proactive identification of hidden API assets, significantly expands the scope of API asset detection, and increases the probability of discovering missed interfaces.

[0033] S104. Perform interface liveness verification on the candidate API interface paths in the candidate API interface path set, and determine the live target API interface based on the liveness verification results.

[0034] In this embodiment, after generating candidate API interface paths, each candidate path is actively probed by sending low-frequency requests to determine whether it actually exists, and the interface that actually exists is identified as the live target API interface.

[0035] In some embodiments, the liveness verification of candidate API interface paths in the candidate API interface path set includes: sending a probe request to each candidate API interface path, determining whether the candidate API interface is alive based on the returned response information, and generating a liveness verification result for each candidate API interface. The response information includes at least one of the following: HTTP status code, response body structure characteristics, response length characteristics, and response error semantic information. Of course, the response information may also include response time, response header keywords, request session state, etc., and this application embodiment does not impose any limitations on this.

[0036] For example, the liveness of a candidate API can be determined by analyzing the HTTP status codes in the response information. For instance, a 404 response indicates that the path does not exist; a 403 or 401 response indicates that the API exists but has restricted permissions; and a 500 or 400 error indicates that the API exists but the parameter format or business logic is incorrect.

[0037] For example, the response body structure in the response information is compared with the global error page template to determine whether the candidate API interface is a real interface. If the similarity is high, there is no real interface; if the similarity is low, there is a real interface. The global error page template can be extracted from the multi-source API asset data in step S101, such as development frameworks, known API interfaces, or front-end static resources.

[0038] For example, the stability of the response length of multiple requests can be used to determine whether an API is alive. For instance, send 2-3 requests to the same API path and record the response length each time. If the length fluctuates little, it indicates that it is a fixed business response and the API exists. If the response length fluctuates greatly and randomly, it is determined that the API does not exist.

[0039] For example, by extracting semantic information about response errors from the response information, such as extracting keywords or prompts in the response body, the system's handling logic for invalid paths can be determined, thereby inferring the existence of the API. For instance, if keywords or prompts such as "invalid path," "missing parameter," or "access denied" appear, it indicates that the API interface path exists; if "path not found" appears, it indicates that the API interface path does not exist.

[0040] In this embodiment, by verifying the liveness of candidate API paths in the candidate API path set, it is possible to accurately filter out real interfaces, exclude invalid paths, and improve the accuracy of interface identification.

[0041] In this embodiment, after filtering out the actual API interface paths, the prediction direction of subsequent interface paths can be dynamically adjusted, and the interface rule information can be adjusted to improve the hit rate of hidden interfaces in subsequent predictions of candidate API interface paths. In some embodiments, Figure 2 shows a flowchart of interface liveness verification and dynamic rule optimization provided by an embodiment of this application. Figure 2 As shown, after determining the target API interface, the method provided in this application embodiment further includes the following steps (S201-S202): S201. Send a preset number of probe requests to each target API interface, and calculate the liveness confidence of each target API interface based on the returned response information. For example, the system can batch probe target API interface paths and count the liveness confidence of each target API interface path, that is, count the number of times the returned response information is not a 404 response, such as / admin / xxx returning 403 / 400 / 500 multiple times in a row.

[0042] S202. Update the interface rule information based on the path context of the target API interface with high survival confidence, wherein the survival confidence of the target API interface with high survival confidence is higher than a preset threshold.

[0043] For example, if 10 probe requests are sent to the interface path under / admin / , and 8 consecutive non-404 responses are returned, then / admin / is set as the target API interface with high liveness confidence, and the interface rules are updated to prioritize generating more paths under this prefix as subsequent API interface paths.

[0044] Therefore, the predicted direction of subsequent interface paths can be dynamically adjusted, and the interface rule information can be adjusted, realizing adaptive optimization of the detection strategy, improving the efficiency and hit rate of hidden interface discovery, and reducing invalid detection.

[0045] After confirming that the target API interface is alive, in some embodiments, the method provided by this application further includes: performing risk verification on the target API interface, obtaining risk verification results, and generating a reproducible verification message based on the risk verification results.

[0046] In this embodiment, risk verification includes two parts: basic risk scanning and in-depth availability verification.

[0047] In some embodiments, basic risk scanning includes detecting sensitive information leakage, missing authentication mechanisms, injection vulnerabilities, unauthorized bulk deletion, and export behavior without rate limits. Specifically, based on a pre-built rule engine, vulnerability signature library, or integrated automated scanning logic, basic security checks are performed on the target API interface, and basic risk scanning is conducted simultaneously with API resource identification to identify potential risks.

[0048] For example, the response information returned by the target API interface is checked to see if it contains sensitive information such as internal IP, password, and stack trace information to detect the risk of sensitive information leakage. For example, the target API interface is checked to see if it can be accessed without a token. If it can be accessed normally, it indicates that an authentication mechanism is missing, and there is a risk of a missing or weakened authentication mechanism. For example, the parameters in the response information returned by the target API interface are checked to see if there are risks of SQL, NoSQL, or command injection to detect the risk of triggering injection-type defects. For example, the target API interface is checked to see if it can delete data in batches or export data without rate limits without verification. If it can, there is a risk of unauthorized batch deletion or export without rate limits.

[0049] In this embodiment, basic risk detection is automatically completed while asset identification is completed, realizing the integration of asset discovery and vulnerability verification, and improving the automation level of API security governance.

[0050] In some embodiments, deep exploitability verification is further performed to distinguish between theoretical risks and actual security flaws that can be exploited by attackers, thereby reducing the false positive rate. Figure 3 shows a flowchart of the risk verification including deep exploitability verification provided in an embodiment of this application. Figure 3 As shown, the process of performing risk verification on the target API interface and obtaining the risk verification result includes the following steps (S301-S302): S301. Perform deep availability verification on the target API interface and obtain response data; In this embodiment, deep availability verification can be performed by sending different types of verification requests to the target API interface to obtain corresponding response data. In some embodiments, the response data includes at least one of the following: HTTP status codes, response content, business feedback information, and system behavior changes. For example, HTTP status codes include 401 / 403 / 200 / 500, etc.; response content includes returned JSON, text, and data; business feedback includes whether data was found, whether the modification was successful, and whether an unauthorized access warning was issued; system behavior changes refer to whether the data was actually deleted / modified / queried, and whether the database has changed. Based on the content of the above response data, multi-dimensional analysis is performed to execute step S302 and obtain the risk verification result.

[0051] In some embodiments, deep verification employs fuzz testing to perform deep availability verification on the target API interface, including at least one of the following methods: (1) According to the interface parameter hierarchy of the target API interface, inject test payloads at the corresponding level, generate verification requests, and send verification requests to the target API interface; In this method (1), based on the nested hierarchical structure of interface parameters, the mutated test load is injected only at the specified parameter level without destroying the overall request structure. This can accurately trigger defects in interface parsing, data verification, or business processing logic, and avoid the inability to enter the business flow due to an illegal overall request format.

[0052] For example, the request body of an interface may have a nested JSON structure as follows: { "user": { "id": 1001, "info": { "status": 1 } } } Based on the parameter hierarchy, inject test payloads such as excessively long characters, special symbols, null values, and overflow classes into the user.info.status level, keeping the outer structure unchanged, generate and send a verification request to detect whether there are parsing crashes, information leaks, or logical errors when the interface is abnormal at the parameter level.

[0053] (2) Modify only the key business parameters of the target API interface, maintain the semantic and format constraints of other fields, generate a verification request, and send the verification request to the target API interface; In this method (2), while tampering with key business parameters, the legality and business semantics of other content such as request headers, authentication information, data types, field formats, and timestamps are preserved, which is used to bypass basic format verification, accurately trigger the real business logic of the interface, and detect the risk of parameter tampering.

[0054] For example, a normal request for a query interface is as follows: GET / api / order / query?order_id=O20250001 Header:Authorization:Bearertoken_001 Content-Type: application / json In this approach, only the critical business parameter order_id=O20250002 is modified, while keeping the Token, request header, and parameter format unchanged. A verification request is then generated and sent to detect whether there is a risk of illegal parameter tampering at the interface.

[0055] (3) Based on the resource ownership and permission model of the target API interface, construct a cross-identity access verification request and send the verification request to the target API interface; In this method (3), based on the resource ownership relationship and permission control model corresponding to the interface, cross-user, cross-tenant, and cross-role access requests are constructed, and the resource identifier of the current identity is replaced with the resource identifier of other identities in order to detect whether the interface has an object-level permission control deficiency (IDOR / BOLA) type of privilege escalation vulnerability.

[0056] For example, the currently logged-in user is A, the user ID is 1001, and the resource ID is user_id=1001; construct a cross-identity access request, replace user_id with another user ID 1002, keep the logged-in identity unchanged, generate a verification request and send it: GET / api / user / info?user_id=1002 Header: Authorization: Bearer token_of_user_1001 To detect whether the interface allows unauthorized viewing or modification of other people's data.

[0057] (4) For the business process corresponding to the target API interface, skip the business pre-steps to construct the verification request for subsequent interface calls and send the verification request to the target API interface.

[0058] In this method (4), for business process interfaces with multiple steps, strong dependencies, and state machine constraints, the pre-operation is not performed according to the normal process. Instead, the interface request for the subsequent steps is directly constructed and called to verify whether the interface performs mandatory verification on the business pre-conditions, execution status, and operation order, and to detect business process bypass vulnerabilities.

[0059] For example, the normal process of an order business is: create an order → pay → ship; skip the "pay" pre-step, directly construct and send the verification request of the "ship" interface, and check whether the shipping logic can be triggered directly in the unpaid state, thereby verifying the completeness of the business state machine verification.

[0060] S302. Extract risk features from the response data, compare the risk features with the preset judgment rules, obtain the risk availability conclusion, and use the availability conclusion as the risk verification result.

[0061] In this step, the response data obtained during the verification process of the above-mentioned deep exploitability verification is analyzed from multiple dimensions. Risk features that can reflect the security status of the interface are extracted from the response data. The extracted risk features are then matched and compared with preset judgment rules. Based on the matching results, it is determined whether the current risk can be truly exploited by attackers, and finally, the risk exploitability conclusion is obtained.

[0062] For example, multi-dimensional analysis includes: identifying HTTP status codes, extracting key fields and sensitive information from the response content, determining whether the business execution result was successful, and detecting whether the system has undergone changes in data query / modification / deletion behaviors, in order to extract the risk characteristics of the current risk. For example, risk characteristics include at least one of the following: status code characteristics extracted from the response, data return characteristics, business execution characteristics, and system behavior characteristics.

[0063] For example, the preset judgment rule is a pre-defined judgment condition used to determine whether a vulnerability is exploitable, including but not limited to at least one of the following: (1) Business data can be successfully obtained without carrying legitimate authentication information, which is determined to be an unauthorized access vulnerability that can be exploited; (2) When accessing other users' accounts, the ability to successfully return, modify, or delete other users' business data is considered an exploitable unauthorized access vulnerability. (3) If database anomalies, command execution results or code error messages appear in the response after injecting the test payload, it is determined that the injection vulnerability can be exploited; (4) If subsequent operations can be successfully executed by skipping the business pre-processing steps, it is determined that the business logic bypass vulnerability can be exploited; (5) If the interface returns sensitive content such as internal IP, key, stack information, and user privacy data, it is determined that the sensitive information has been leaked and can be used.

[0064] After extracting risk characteristics, they are matched and compared with preset judgment rules to determine exploitability. For example, the risk characteristics are compared one by one with the judgment conditions in the preset judgment rules to determine whether at least one judgment condition is met. If so, the risk exploitability conclusion is exploitable, indicating that the risk is a real security vulnerability that can be triggered and exploited by an attacker. If no exploitable judgment condition is met, the risk exploitability conclusion is unexploitable, indicating that the risk is a theoretical warning or a false alarm.

[0065] For example, if after deep exploitability verification sends a cross-identity access request, the response status code is 200, the response content returns other users' private data, and the business feedback is that the query was successful, then the extracted risk feature is "200 status code + returned other people's data". After comparing this feature with the preset judgment rules, the conditions for unauthorized access are met, so it is judged as an exploitable unauthorized access vulnerability. If after injecting the payload, only the parameter format is returned, no database anomaly occurs, and no data change occurs, then no exploitable conditions are met, and it is judged as unexploitable.

[0066] Therefore, by conducting multi-dimensional analysis and rule comparison of the response data of deep exploitability verification, it is possible to effectively distinguish between real vulnerabilities and theoretical alerts, significantly reduce the false alarm rate, accurately identify real exploitable vulnerabilities, and improve the reliability and practicality of risk verification results.

[0067] For security risks identified as exploitable, a reproducible verification message is automatically generated, such as a structured proof of concept (PoC). The target API interface is then repaired based on this reproducible verification message. In some embodiments, the method provided in this application further includes: replaying the reproducible verification message on the repaired target API interface, comparing the actual response with the original vulnerability response, and determining whether the vulnerability has been completely repaired. This achieves closed-loop vulnerability verification, ensuring that risks are effectively rectified.

[0068] To more clearly illustrate the deep exploitability verification and vulnerability closure process of the embodiments of this application, the following uses an unauthorized access vulnerability (IDOR) as an example to illustrate the deep exploitability verification and vulnerability closure process in an application example. Specifically, it includes the following steps (S401-S406): S401. Based on the resource ownership and permission model of the target API interface, construct an unauthorized access verification request and send the verification request to the target API interface. For example, an unauthorized access verification request can be constructed as follows: GET / api / user / info?user_id=1001 Header:Authorization:Bearer{User 1002's valid token} S402. Obtain response data and perform multi-dimensional analysis on the response data; For example, the response data in this application sample is as follows: HTTP status code: 200 Response content: Return user 1001's name, phone number, and other private data. Business feedback: User information successfully obtained. System behavior: The backend reads and returns business data that is not from the current user. S403. Extract risk characteristics and compare them with preset judgment rules. Based on the comparison results, determine the risk availability conclusion. The risk characteristics extracted from the response data are: 200 status code + return of privacy data not belonging to the current user. This risk characteristic is compared with the preset judgment rules. If it meets the exploitable condition of "cross-identity access can successfully obtain other people's data", it is judged as an exploitable vulnerability.

[0069] S404. Generate PoC based on availability conclusions; For example, the above unauthorized access verification request can be saved as a structured PoC for subsequent vulnerability review and remediation verification.

[0070] S405. After patching the vulnerability, replay the PoC for regression verification. For example, after the vulnerability is patched on the interface, the HTTP request corresponding to the PoC is automatically replayed to obtain the actual response after the patch.

[0071] For example, the repaired response is: HTTP status code: 403; Response content: No permission.

[0072] S406. Compare the actual response with the original vulnerability response to determine the effectiveness of the fix.

[0073] For example, the actual response after the fix is ​​compared with the expected response when the original vulnerability was triggered: Before the fix: 200+ users, 1001 privacy data; After the fix: 403 No permission. As you can see, the response before and after the fix are different, indicating that the vulnerability has been effectively fixed and the risk loop has been closed.

[0074] The API resource identification method provided in this application can extract general rules for interfaces from multiple dimensions by acquiring multi-source API asset data and performing structured parsing and semantic analysis. It can generate potential candidate interface paths without relying on manual sorting and interface traffic. Then, it can screen out the target API interfaces that are actually alive through liveness verification, realize the proactive identification of hidden API interfaces that are not registered, have no traffic, and have no documentation, improve the efficiency and accuracy of hidden API interface identification, expand the coverage of API assets, and make up for the asset identification blind spots in the existing technology.

[0075] Figure 4 This diagram illustrates a structural block diagram of an API resource identification device 100 provided in an exemplary embodiment of this application. The API resource identification device 100 described above can achieve the following: Figures 1 to 3 All or part of the contents of any of the embodiments shown. The following is only a brief description of the structure and function of the API resource identification device 100. For other matters not covered, please refer to the relevant descriptions in the API resource identification method above. The embodiments of the API resource identification device 100 correspond to the embodiments of the API resource identification method above. All implementation processes and methods of the above method embodiments can be applied to the embodiments of the API resource identification device 100 and can achieve the same technical effect.

[0076] In some embodiments, such as Figure 4 As shown, the API resource identification device 100 includes: an acquisition module 101, a rule learning module 102, a path generation module 103, and an identification module 104. In this embodiment, the acquisition module 101 is used to acquire multi-source API asset data; the rule learning module 102 is used to perform structured parsing and semantic analysis of API paths on the multi-source API asset data to obtain interface rule information; the path generation module 103 is used to generate a candidate API interface path set based on the interface rule information, the candidate API interface path set including at least one candidate API interface path; the identification module 104 is used to perform interface liveness verification on the candidate API interface paths in the candidate API interface path set, and determine the live target API interface based on the liveness verification result.

[0077] In some embodiments, multi-source API asset data includes at least one of the following: interface routing rules of the development framework, API standardization interface description files, known API interface record data, asset ledger metadata, and front-end static resources.

[0078] In some embodiments, the interface rule information includes at least one of the following: interface path composition structure, business resource naming characteristics, operation semantic characteristics, parameter and field format characteristics, context path prefix characteristics, and formatting and naming specification characteristics.

[0079] In some embodiments, the path generation module 103 is used to generate a set of candidate API interface paths based on interface rule information, including: generating the set of candidate API interface paths based on interface rule information through at least one of the following methods: resource operation integrity completion, cross-resource semantic extension, template analogy replacement, context prefix migration, and parameterized path variant generation.

[0080] In some embodiments, the identification module 104 is used to perform interface liveness verification on the candidate API interface paths in the candidate API interface path set, including: sending a probe request to each candidate API interface path, determining whether the candidate API interface is alive based on the returned response information, generating a liveness verification result corresponding to each candidate API interface, wherein the response information includes at least one of the following: HTTP status code, response body structure features, response length features, and response error semantic information.

[0081] In some embodiments, the identification module 104 is further configured to send a preset number of probe requests to each target API interface, and to calculate the survival confidence of each target API interface based on the returned response information; and to update the interface rule information based on the path context to which the target API interface with high survival confidence belongs, wherein the survival confidence of the target API interface with high survival confidence is higher than a preset threshold.

[0082] In some embodiments, the identification module 104 is further configured to perform risk verification on the target API interface, obtain the risk verification result, and generate a reproducible verification message based on the risk verification result.

[0083] In some embodiments, the identification module 104 is further configured to perform risk verification on the target API interface and obtain risk verification results, including: performing deep availability verification on the target API interface to obtain response data, the response data including at least one of the following: HTTP status code, response content, business feedback information, system behavior changes; extracting risk features from the response data, comparing the risk features with preset judgment rules to obtain risk availability conclusions, and using the availability conclusions as risk verification results.

[0084] In some embodiments, the identification module 104 is further configured to perform deep exploitability verification on the target API interface, including at least one of the following methods: According to the interface parameter hierarchy of the target API interface, inject test payloads at the corresponding levels, generate verification requests, and send verification requests to the target API interface; Modify only the key business parameters of the target API interface, maintain the semantic and format constraints of other fields, generate a verification request, and send the verification request to the target API interface; Based on the resource ownership and permission model of the target API interface, construct a cross-identity access verification request and send the verification request to the target API interface. For the business process corresponding to the target API interface, skip the business pre-processing steps to construct the verification request for subsequent interface calls, and send the verification request to the target API interface.

[0085] The API resource identification device provided in this application can extract general rules for interfaces from multiple dimensions by acquiring multi-source API asset data and performing structured parsing and semantic analysis. It can generate potential candidate interface paths without relying on manual sorting and interface traffic. Then, it can screen out the target API interfaces that are actually alive through liveness verification, realize the active identification of hidden API interfaces that are not registered, have no traffic, and have no documentation, improve the efficiency and accuracy of hidden API interface identification, expand the coverage of API assets, and make up for the asset identification blind spots in the existing technology.

[0086] Figure 5 A structural block diagram of an electronic device 1000 illustrating an exemplary embodiment of this application is shown. The electronic device 1000 can be implemented as the API resource identification method described above.

[0087] Typically, electronic device 1000 includes a processor 1001 and a memory 1002.

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

[0089] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1002 are used to store at least one instruction, which is executed by the processor 1001 to implement all or part of the steps in the API resource identification method shown in the method embodiments of this application.

[0090] Those skilled in the art will understand that Figure 5 The structure shown does not constitute a limitation on the electronic device 1000, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0091] In one exemplary embodiment, a readable storage medium is also provided, which stores a program or instructions that, when executed by a processor, implement all or part of the steps in the API resource identification method described above. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0092] In one exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform all or part of the steps of the above-described API resource identification method.

[0093] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0094] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for identifying API resources, characterized in that, include: Obtain multi-source application programming interface (API) asset data; The multi-source API asset data is subjected to structured parsing and semantic analysis of API paths to obtain interface rule information; A candidate API interface path set is generated based on the interface rule information, and the candidate API interface path set includes at least one candidate API interface path. Perform interface liveness verification on the candidate API interface paths in the candidate API interface path set, and determine the live target API interface based on the liveness verification results.

2. The method according to claim 1, characterized in that, The multi-source API asset data includes at least one of the following: interface routing rules of the development framework, API standardized interface description files, known API interface record data, asset ledger metadata, and front-end static resources.

3. The method according to claim 1, characterized in that, The interface rule information includes at least one of the following: interface path composition structure, business resource naming characteristics, operation semantic characteristics, parameter and field format characteristics, context path prefix characteristics, and formatting and naming specification characteristics.

4. The method according to claim 1, characterized in that, The generation of a candidate API interface path set based on the interface rule information includes: A set of candidate API interface paths is generated based on the interface rule information using at least one of the following methods: Resource operation integrity completion, cross-resource semantic extension, template analogy replacement, context prefix migration, and parameterized path variant generation.

5. The method according to claim 1, characterized in that, The step of verifying the liveness of candidate API interface paths in the candidate API interface path set includes: A probe request is sent to each of the candidate API interface paths, and the liveness of the candidate API interface is determined based on the returned response information. A liveness verification result is generated for each candidate API interface. The response information includes at least one of the following: HTTP status code, response body structure characteristics, response length characteristics, and response error semantic information.

6. The method according to claim 1, characterized in that, The method further includes: Send a preset number of probe requests to each of the target API interfaces, and calculate the liveness confidence of each target API interface based on the returned response information; The interface rule information is updated based on the path context to which the target API interface with high survival confidence belongs, wherein the survival confidence of the target API interface with high survival confidence is higher than a preset threshold.

7. The method according to claim 1, characterized in that, The method further includes: Perform risk verification on the target API interface, obtain the risk verification result, and generate a reproducible verification message based on the risk verification result.

8. The method according to claim 7, characterized in that, The step of performing risk verification on the target API interface and obtaining the risk verification result includes: Perform deep availability verification on the target API interface to obtain response data, which includes at least one of the following: HTTP status code, response content, business feedback information, and system behavior changes; Risk features are extracted from the response data, and the risk features are compared with preset judgment rules to obtain a risk availability conclusion. The availability conclusion is used as the risk verification result.

9. The method according to claim 7, characterized in that, The deep availability verification of the target API interface includes at least one of the following methods: According to the interface parameter hierarchy of the target API interface, inject test payloads at the corresponding level, generate verification requests, and send the verification requests to the target API interface; Modify only the key business parameters of the target API interface, maintain the semantic and format constraints of other fields, generate a verification request, and send the verification request to the target API interface; Based on the resource ownership and permission model of the target API interface, a cross-identity access verification request is constructed and sent to the target API interface. For the business process corresponding to the target API interface, skip the business pre-processing steps, construct the verification request for subsequent interface calls, and send the verification request to the target API interface.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the API resource identification method as described in any one of claims 1 to 9.

Images