Interface risk tracing method and device, equipment, storage medium and program product

Abstract

The invention provides an interface risk tracing method and device, equipment, a storage medium and a program product, and relates to the technical field of computers.The method comprises the steps that protocol analysis is conducted on API information of an application programming interface, and a performance judgment result of the API is obtained; performing abnormal risk point monitoring on the API interface according to the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface which is abandoned or no longer used, but exists in a code or is abnormally utilized; and carrying out risk tracing according to the abnormal interface. According to the method, the risk nodes are judged by performing protocol analysis and access legal compliance analysis on the API interface information, and then the risk traceability is performed on the risk nodes, so that the traceability accuracy is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an interface risk tracing method, device, equipment, storage medium and program product. Background Art

[0002] Based on the popularity of big data, cloud computing and the Internet of Things, most existing enterprises and institutions have begun to adopt complex computer systems and platforms, which are usually composed of multiple modules, services and interfaces. In the field of communications, the application programming interface (API) is widely used. For example, telecom operators can integrate with other partners' systems through API interfaces to achieve business operations such as traffic settlement and bill query; communication equipment providers can use API interfaces to allow their equipment to interact with other systems to achieve functions such as equipment management and alarm monitoring; mobile applications can use API interfaces to call services such as SMS sending and payment provided by communication operators. However, the interfaces in the system and platform involve many security and quality risks, such as data leakage, security vulnerabilities, performance issues, etc. These risks may have a serious impact on the entire system and platform, and even cause the collapse of the system and platform. Due to the widespread application of API interfaces in the field of communications, it is very important to ensure the security and performance of API interfaces. Therefore, it is necessary to trace the source of API interfaces. Interface traceability can help discover and track possible problems and risks in the interface call process and improve the reliability and stability of the system.

[0003] At present, the technical routes for risk tracing of API interfaces mainly include: identification and classification of API interfaces and monitoring and tracking of API interfaces. However, the accuracy of the above risk tracing technologies is low. Summary of the invention

[0004] The present invention provides an interface risk tracing method, device, equipment, storage medium and program product, which are used to solve the defect of low accuracy of risk tracing of API interface in the prior art and improve the accuracy of risk tracing.

[0005] The present invention provides an interface risk tracing method, comprising the following steps: Perform protocol analysis on the application programming interface (API) interface information to obtain the performance judgment result of the API interface; The API interface is monitored for abnormal risk points according to the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally used; Risk tracing is performed based on the abnormal interface.

[0006] According to an interface risk tracing method provided by the present invention, the protocol analysis of the application programming interface API interface information is performed to obtain the performance judgment result of the API interface, including: Acquire the message information of the API interface from the API interface information; Acquire the response time and request time of the message according to the message information, and use the difference between the response time and the request time as the first processing time of the message; If the first processing time is greater than a set threshold, the request mode of the message is obtained, and the average processing time of the request mode is determined; the average processing time is the average of the processing time of all messages with the same request mode; If the first processing time is greater than the average processing time, obtaining a browser from which the request for the message originates; Obtaining a second processing time required by the browser to process a message corresponding to the request method; If the first processing time is greater than the second processing time, it is determined that the performance judgment result is that there is a performance abnormality in the API interface.

[0007] According to an interface risk tracing method provided by the present invention, the abnormal risk point monitoring of the API interface is performed according to the performance judgment result to obtain an abnormal interface, including: If the performance judgment result is that the API interface has a performance abnormality, then performing interface request message analysis, response message analysis, and structure analysis on the API interface; When the interface request message analysis result, the response message analysis result, and the structure analysis result are all abnormal, determining that the API interface is the abnormal interface; Among them, the abnormal results of interface request message analysis include at least one of request header abnormality, request method abnormality, request parameter abnormality, path and uniform resource locator URL abnormality and request body abnormality; the abnormal results of response message analysis include at least one of response status code abnormality, response header abnormality, response body abnormality and business logic abnormality; the abnormal results of structure analysis include at least one of missing data field, field type mismatch, incorrect field format, illegal field value and inconsistent structure.

[0008] According to an interface risk tracing method provided by the present invention, an interface request message analysis is performed on the API interface, including: Determine whether the request message of the API interface meets the expected format and protocol requirements, and check whether the request message can be correctly received and processed by the API interface; Analyze the response message of the API interface, including: Verify whether the response of the API interface meets expectations, and check whether the API interface returns correct data or error information normally; Performing structural analysis on the API interface includes: Check whether the data structure of the API interface conforms to the preset structure.

[0009] According to an interface risk tracing method provided by the present invention, the risk tracing according to the abnormal interface includes: According to the pre-built API call chain model, the data flow track corresponding to the abnormal interface is restored; the API call chain model is used to describe the calling sequence and dependency relationship of the API interface; Generate a business system process relationship link according to the data flow trajectory; Risk tracing is performed based on the business system process relationship link.

[0010] According to an interface risk tracing method provided by the present invention, the API call chain model is constructed based on the following method: Define the API interface according to the interface requirement information; Establish connections between the API interfaces, and combine multiple APIs in order according to business demand information to obtain an initial call chain model; Configure the calling parameters of each of the API interfaces in the initial calling chain model; The initial call chain model is tested, and if the test is successful, the call chain model is obtained.

[0011] The present invention also provides an interface risk tracing device, comprising the following modules: The protocol analysis module is used to perform protocol analysis on the application programming interface (API) interface information to obtain the performance judgment result of the API interface; A risk point monitoring module, used to monitor the abnormal risk points of the API interface according to the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally used; The risk tracing module is used to perform risk tracing based on the abnormal interface.

[0012] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the interface risk tracing method as described in any one of the above is implemented.

[0013] The present invention also provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the interface risk tracing method as described in any one of the above is implemented.

[0014] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the interface risk tracing methods described above.

[0015] The interface risk tracing method, device, equipment, storage medium and program product provided by the present invention perform protocol analysis on the API interface information to obtain the performance judgment result of the API interface; monitor the API interface for abnormal risk points according to the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally used; and risk tracing is performed according to the abnormal interface. The present invention determines the risk node by performing protocol analysis and access legal compliance analysis on the API interface information, and then performs risk tracing on the risk node, thereby improving the accuracy of tracing. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 It is a flow chart of the interface risk tracing method provided by the present invention.

[0018] Figure 2 It is a schematic diagram of the API call chain modeling process provided by the present invention.

[0019] Figure 3 It is a schematic diagram of the API traceability process provided by the present invention.

[0020] Figure 4 It is a flow chart of the API risk tracing method based on link analysis provided by the present invention.

[0021] Figure 5 It is a structural schematic diagram of the http protocol analysis model provided by the present invention.

[0022] Figure 6 It is a structural diagram of the access legality and compliance analysis model provided by the present invention.

[0023] Figure 7 It is a structural schematic diagram of the interface risk tracing device provided by the present invention.

[0024] Figure 8 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] Currently, relevant technologies cannot solve the following problems in business API traceability: Uncertain data sources: APIs in business systems may call data from multiple sources, resulting in uncertain data sources, which makes risk tracing more difficult. Limitations of risk assessment: APIs in business systems may not all be included in the scope of risk assessment, resulting in limitations in risk assessment and thus failure to fully assess API risks; There are many factors that restrict traceability conditions: Due to the special position and importance of APIs in business systems, the permissions to access and change them are restricted, which makes risk tracing difficult.

[0027] Based on the above problems, the present invention provides an interface risk tracing method, which can realize access to interface performance, interface status alarm and full-link tracing of interface business, solve the problems of uncertainty of risk sources and low tracing accuracy, and meet the technical requirements of interface performance access, interface status alarm and full-link tracing of business.

[0028] Combine the following Figure 1-Figure 8 The interface risk tracing method, device, equipment, storage medium and program product of the present invention are described.

[0029] Figure 1 is a flow chart of the interface risk tracing method provided by the present invention, such as Figure 1 As shown, the method includes the following: Step 101, performing protocol analysis on the application programming interface API interface information to obtain a performance judgment result of the API interface.

[0030] In the embodiment of the present invention, traffic is obtained by traffic mirroring, libpcap+pf_ring is used to capture the traffic on the network card, and the protocol features are parsed after capture, and then the protocol features are analyzed, and finally the protocol information of the message is extracted.

[0031] Traffic mirroring is the process of making a copy of network traffic to another port or device so that it can be monitored and analyzed. libpcap is a library commonly used in computer network monitoring and packet analysis. It provides a set of APIs for capturing network packets, which can be used to capture and process data traffic on network interfaces. libpcap supports multiple operating systems, including Linux, Unix, Windows, etc. pf_ring is a high-performance packet processing framework that is an extension of libpcap and aims to provide higher packet processing speed and throughput. pf_ring optimizes the way network packets are processed, provides higher packet capture performance and better multi-core processing capabilities, and is suitable for high-speed network traffic capture and processing scenarios.

[0032] It is understandable that the http message features as message headers carry some special identifiers that can be parsed, for example: 4f5054494f4e53, 48454144, 474554, 504f5354, 44454c455445 and other protocol identifiers, and then the specific protocol types are analyzed and reorganized based on these identifiers to obtain complete and identifiable message information.

[0033] For example, the process of packet capture and parsing is as follows: (1) Packet capture: libpcap and pf_ring are used for packet capture, where libpcap is responsible for basic capture operations, while pf_ring provides more efficient packet processing capabilities. After the data packets are extracted from the network interface, they are processed in user space.

[0034] (2) Protocol feature analysis: The captured data packets contain messages of multiple protocols. The http message contains some feature identifiers, such as a specific hexadecimal string, for example, 4f5054494f4e53 corresponds to the http / 1.1 identifier. By analyzing these feature identifiers in the data packet, the specific protocol type can be identified and reassembled. For example, by identifying 4f5054494f4e53, it can be determined that this is a message of the http protocol.

[0035] (3) Protocol reorganization and information extraction: Once the protocol identifier is identified, the data packet can be further parsed to extract the complete message information, including the detailed fields of the protocol, data content, etc. The parsed content can be used for subsequent analysis, such as network traffic monitoring, performance analysis, or security inspection.

[0036] By combining libpcap and pf_ring, efficient traffic capture and analysis can be achieved. libpcap is responsible for packet capture operations, while pf_ring provides faster packet collection, distribution, and processing functions. Using libpcap+pf_ring can improve the efficiency of packet capture and analysis, and is suitable for scenarios where real-time analysis and processing of high-speed network traffic is required, such as network security monitoring, traffic analysis, etc.

[0037] Furthermore, the API interface information is subjected to protocol analysis to obtain the performance judgment result of the API interface. For example, for the API interface information, the http protocol analysis model is used to extract information, including account, URL (Uniform Resource Locator), request time, request method, request source browser type, etc., and then the extracted information is subjected to performance analysis to determine the performance judgment result of the API interface. Among them, the http protocol analysis model is used to determine the performance problems of the API interface, and through detailed message analysis to capture and evaluate key performance indicators, such as request and response time, request method, browser source, etc., so as to understand the performance status of the API interface and discover potential risk points.

[0038] In one embodiment, the message information of the API interface is obtained from the API interface information; based on the message information, the response time and request time of the message are obtained, and the difference between the response time and the request time is used as the first processing time of the message; if the first processing time is greater than the set threshold, the request method of the message is obtained, and the average processing time of the request method is determined, wherein the average processing time is the mean of the processing time of all messages with the same request method; if the first processing time is greater than the average processing time, the browser from which the message is requested is obtained; the second processing time required for the browser to process the message corresponding to the request method is obtained; if the first processing time is greater than the second processing time, it is determined that the performance judgment result is that there is a performance abnormality in the API interface.

[0039] It is understandable that the first processing time is used to evaluate the preliminary performance of the API. If the first processing time is greater than the set threshold, it means that there may be a problem with the interface response time. At this point, it is necessary to further determine the request method of the message (such as GET, POST, PUT, DELETE). Each request method may have different processing logic and complexity in the system. Different request methods may involve different operations or data processing, resulting in differences in their processing time. By analyzing the average processing time of different request methods, the normal processing time of different request types can be understood, so as to determine whether each request method is abnormal. If the first processing time of the message exceeds the average processing time corresponding to the request method, it means that there is a bottleneck or performance problem in the processing of the request method.

[0040] Furthermore, the performance analysis of the API interface is conducted in combination with the time required by the browser to process a specific request method. Different browsers may perform differently in terms of network requests and data processing. The performance differences of the browsers and the degree of optimization of network requests will affect the processing time of the request message. Therefore, the type of browser used by the user will affect the processing time of the request message. Even if the processing time of the request method seems normal, if the processing time in a certain browser is abnormal, it may mean that there are specific problems or incompatibility in the browser. At the same time, factors such as the browser version, configuration, and plug-ins may affect performance. By analyzing the time required by the browser to process a specific request method, the problem can be more accurately located, for example, whether it is caused by the specific implementation of the browser or the network conditions. Relying solely on the average processing time of the request method may not reveal all problems. The browser-specific processing time provides more levels of details and helps to understand the performance bottleneck more comprehensively. If a certain request method performs poorly in all browsers, the problem may be on the server side or the request processing logic; if the processing time is abnormal only in a specific browser, the problem may be in the specific implementation or compatibility of the browser.

[0041] In the embodiment of the present invention, determining that an anomaly exists based on the first processing time of the message is the first step in detecting performance problems. Further analysis of the request method and browser type is to ensure that the performance problem is fully understood and accurately diagnosed. Multiple analyses can help discover and solve more subtle performance problems, ensuring that the API interface can provide good performance in different usage scenarios.

[0042] Step 102: Monitor the API interface for abnormal risk points based on the performance judgment result to obtain an abnormal interface.

[0043] When an API interface has performance anomalies, the API interface is monitored for abnormal risk points, and then based on the monitoring results, it is determined whether the API interface is an abnormal interface. Among them, an abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally used (such as maliciously used).

[0044] The embodiment of the present invention adopts the access legal compliance analysis model to monitor abnormal risk points of API interfaces. Through the access legal compliance analysis model, audit analysis is performed on interface request messages, response messages, structures, etc. to determine whether they are abnormal interfaces. At the same time, abnormal interfaces are monitored. If a large amount of data is transmitted on the interface, it is determined that an attack may have occurred and an alarm will be generated immediately.

[0045] In one embodiment, abnormal risk point detection is performed on the API interface, wherein the abnormal risk point detection includes interface request message analysis, response message analysis, and structure analysis.

[0046] (1) Interface request message analysis: Determine whether the API interface request message conforms to the expected format and protocol requirements, and check whether the request message can be correctly received and processed by the API interface. Specifically include: Check the request header: verify the existence of required request header fields (such as Content-Type, Authorization, etc.); check whether the format of the header fields is correct, such as date format, character set, etc.; Verify the request method: confirm whether the http method (GET, POST, PUT, DELETE, etc.) used in the request is consistent with the interface document; Check request parameters: For GET requests, check whether the query parameters meet expectations; for POST and PUT requests, check whether the parameters in the request body are complete and in the correct format, such as JSON, XML, etc. Verify the path and URL: confirm whether the requested URL path is correct and whether it matches the path defined in the interface; Parse the request body: If the request contains a body (such as a POST request), parse the request body and verify whether its content conforms to the format and fields required by the interface; Exception handling: Record and analyze exceptions in request messages, such as format errors, missing required fields, etc.

[0047] (2) Response message analysis: Verify whether the response of the API interface meets expectations, and check whether the API interface returns correct data or error information normally. Specifically include: Check the response status code: Verify whether the returned HTTP status code meets expectations, such as 200 OK, 404 NotFound, 500 Internal Server Error, etc. Check the response header: Make sure the response header contains required fields (such as Content-Type) and is in the correct format; check whether the field values ​​in the response header are as expected; Parse the response body: verify whether the format of the response body (such as JSON, XML, etc.) is correct; check whether the data in the response body conforms to the expected structure and fields; Check business logic: Compare the actual returned results with the expected results to confirm whether the interface returns data correctly according to the business logic; Exception handling: Record and analyze exceptions in response messages, such as status code errors, data format errors, business logic inconsistencies, etc.

[0048] (3) Structural analysis: Check whether the data structure of the API interface conforms to the preset structure. Specifically including: Define data structure: Define data structure according to interface documents or protocols, such as JSON Schema and XML Schema; Parse data structure: extract data from the request body or response body and verify whether its structure is consistent with the defined structure; Verify field types and ranges: Ensure that the field types (such as string, number, Boolean, etc.) in the data structure are consistent with the definition; check whether the value of the field is within the expected range, such as number range, string length, etc.; Check required fields: Confirm that all required fields exist and are not empty; Exception handling: Record and analyze exceptions in structures, such as missing fields, type mismatch, incorrect format, etc.

[0049] After detecting abnormal risk points on the API interface, if the interface request message analysis results, response message analysis results, and structure analysis results are all abnormal, the API interface is determined to be an abnormal interface. Among them, the abnormal interface request message analysis results include at least one of the following: Request header abnormalities: such as missing necessary fields or incorrect field formats; request method abnormalities: such as http method errors; request parameter abnormalities: such as missing parameters, incorrect parameter formats, or incorrect parameter values; path and uniform resource locator URL abnormalities: such as URL path errors; request body abnormalities: such as incorrect formats or incomplete data.

[0050] The abnormal response message analysis result includes at least one of the following: Abnormal response status code: such as incorrect status code; abnormal response header: such as missing required fields, incorrect field format; abnormal response body: such as incorrect format, incomplete data, incorrect data; abnormal business logic, such as results that do not meet business expectations.

[0051] Abnormal structural analysis results include at least one of the following: Missing data fields: such as missing required fields; field type mismatch: such as type error; incorrect field format: such as format error; illegal field value: such as value out of range, enumeration value error; inconsistent structure: such as nested structure error, array length mismatch.

[0052] It is understandable that if there are exceptions in the request message (such as the request header does not meet the specifications, the parameters are incorrect, etc.), this may indicate that the interface is not called correctly, which may be because the interface has been abandoned or there is abnormal use, but the request message exception alone is not enough to confirm that the interface is an abnormal interface, which may just be an error or abuse of certain requests. Exceptions in the response message (such as error status code, unexpected return content, etc.) may show that the interface processing is abnormal or no longer valid. The response exception may indicate that the function of the interface is no longer available, but it still needs to be combined with other information. The presence of invalid or expired fields in the structure may indicate that the data format or content of the interface is no longer applicable. The structural analysis exception may indicate that the interface is abandoned or no longer used, but it may also be a change in the data format or version update problem. Therefore, a comprehensive judgment is made based on all analysis results. If the interface exhibits multiple abnormal characteristics and these exceptions meet the characteristics of abnormal interfaces (such as frequent requests but not used by business logic, the presence of expired fields, etc.), it can be more confidently judged that the interface is an abnormal interface.

[0053] Step 103: perform risk tracing based on the abnormal interface.

[0054] After determining the abnormal interface, that is, the abnormal risk point, the pre-built API call chain model is used to trace the risk of the abnormal interface. The API call chain model is used to describe the calling sequence and dependency of the API interface.

[0055] The API call chain model is constructed in the following way: define the API interface according to the interface requirement information; establish the connection between the API interfaces, and combine multiple APIs in sequence according to the business requirement information to obtain the initial call chain model; configure the call parameters of each API interface in the initial call chain model; test the initial call chain model, and if the test is successful, obtain the call chain model.

[0056] For example, refer to Figure 2 , based on the API usage, pre-build the API call chain model, including the source, target, parameters and other information of the API call. The specific steps are as follows: (1) Define APIs: Identify the APIs required in the system, clarify the functions, input parameters, output results and business logic of each API; describe each API in detail, including function description, parameter list, data format and expected output.

[0057] (2) Establishing API connections: Based on the API functions and business requirements, establish connections between APIs to ensure smooth transmission and exchange of data between different APIs. The purpose of establishing connections between APIs is to achieve data transmission and exchange so that different APIs can call each other and work together.

[0058] (3) Design a call chain: According to business needs, multiple APIs are combined in sequence to form a complete call chain model, where the call chain model describes the order and dependencies of a series of API calls; in the call chain model, each API is responsible for completing a specific task or function and passing the result to the next API for further processing, thereby implementing a series of logical processing or business processes. By combining multiple APIs in a specific order, complex business logic can be implemented. Combining multiple APIs in sequence to form a complete call chain model can help realize the traceability of the entire call chain, thereby providing assistance in troubleshooting, performance optimization, business process tracking, security auditing, and data monitoring.

[0059] (4) Configure call parameters: For each API, configure the corresponding parameters and options to achieve the purpose of traceability. First, have a deep understanding of the functions, inputs and outputs of each API. Understanding the functions provided by the API can help determine the parameters and options that need to be configured. At the same time, it is also necessary to clarify the traceability requirements. For example, you need to track the source, processing method, quality and other information of the data, or you want to record the API call time, operator, input parameters and other detailed information. According to the specific needs, determine the parameters and options that need to be configured. Then, according to the requirements of the API, control the behavior of the API by configuring appropriate parameters. The parameters may include the format of the input data, filtering conditions, sorting method, time range, etc., to ensure that the parameter settings are consistent with the requirements and comply with the API specifications. Furthermore, the API can provide some options for customized operations. According to the traceability requirements, select the appropriate options and set them. For example, you need to configure the log level, turn on the debug mode, set the format of the returned results, etc.

[0060] (5) Testing and verification: After establishing a complete API call chain, testing and verification are required to ensure that the entire system can work properly and meet business needs. After configuring the call parameters, use specific input data and parameter combinations to test whether the API's functions and outputs meet expectations. If problems are found, the parameters and options can be adjusted and optimized. After completing the test, record and store the test information. At the same time, record the API configuration information for traceability purposes. For example, it can be comments in the code, instructions in the configuration file, or record the API configuration information in relevant documents, and store the recorded information in a safe and reliable location for subsequent use and traceability.

[0061] In one embodiment, based on a pre-built API call chain model, the data flow trajectory corresponding to the abnormal interface is restored; based on the data flow trajectory, a business system process relationship link is generated; and risk tracing is performed based on the business system process relationship link.

[0062] For example, refer to Figure 3 , API traceability tracking includes the following steps: (1) Analyze the API call chain model to determine the risk vulnerabilities in the API usage process. During the monitoring and tracking process, some abnormal situations may occur, such as excessive frequency of API interface use and unreasonable size of transmitted data.

[0063] (2) Through full-link tracing of data nodes, the data flow trajectory is restored, for example, the account information, time point, IP address passed, interface information accessed, data information sent, etc. are recorded, and content analysis is performed to determine whether there is sensitive data. If so, an alarm is generated and processed to achieve the purpose of accountability.

[0064] (3) Through SparSQL, all interface access situations are arranged according to the specific relationships presented by their characteristics to form the interface business system process relationship links, and the links can be traced. The link traceability information includes but is not limited to: business time consumption, business link status, business risk exposure points, business abnormality risk points, business violation risk index and other information.

[0065] The interface risk tracing method provided by the embodiment of the present invention performs protocol analysis on the API interface information to obtain the performance judgment result of the API interface; monitors the API interface for abnormal risk points based on the performance judgment result to obtain abnormal interfaces; abnormal interfaces represent interfaces that have been abandoned or no longer used, but exist in the code or are abnormally used; and risk tracing is performed based on abnormal interfaces. The present invention determines the risk nodes by performing protocol analysis and access legal compliance analysis on the API interface information, and then performs risk tracing on the risk nodes, thereby improving the accuracy of tracing.

[0066] In order to further analyze and illustrate the interface risk tracing method provided by the present invention, refer to the following embodiments.

[0067] The embodiment of the present invention specifically provides an API risk tracing method based on link analysis. Figure 4 This method obtains traffic through traffic mirroring, uses protocol feature identifiers to identify message information, uses the http protocol analysis model to extract information from API interface information, and then determines the risk nodes through access legal compliance analysis, and determines the process relationship link, and finally traces the source. This method can be used to assist development and operation personnel in fault diagnosis, capacity estimation, performance bottleneck analysis, and call link combing. The API risk tracing method based on link analysis mainly includes the following contents: (1) Preparation phase - traffic acquisition and message identification: Traffic is acquired through traffic mirroring, and libpcap+pf_ring is used to capture the traffic on the network card. After capturing, the protocol features are parsed, and then the protocol features are analyzed, and finally the protocol information of the message is extracted.

[0068] (2) Model construction phase - protocol analysis model and access legal compliance analysis model: For API interface information, use the http protocol analysis model to extract some of the information, including but not limited to: account number, URL, request time, request method, request source browser type, etc.; through access legal compliance analysis, determine the abnormal risk points and abnormal behavior defects of this request.

[0069] 2.1) HTTP protocol analysis model: The HTTP protocol analysis model can be used to determine the time when a user obtains a request and the time when a user obtains a response. Subtracting the two can yield the interface performance, which can be used to determine the bottleneck of the interface and whether it is under attack.

[0070] refer to Figure 5 The process of protocol analysis based on the http protocol analysis model is as follows: Extract information from the message, give priority to extracting account information and URL information, and then extract request time and response time. After extracting account information and URL information, enter the request time and response time analysis stage. The formula in this stage is a subtraction formula: response time - request time = interval time n. If there is no interval time (that is, the interval time is 0), return to re-extraction. If there is an interval time (that is, the interval time is greater than 0), enter the next stage of analysis. Analyze common request methods such as GET, POST, PUT, etc., output the mean of the message processing time of each request method, and the interval time n is divided into three states: n equals the mean, n is greater than the mean, and n is less than the mean. After the mean is calculated, enter the request browser judgment stage. This stage can judge commonly used browsers such as chrome, 360ee 360, safari, etc. Finally, according to the request time, response time, interval time, request method mean and requested browser, determine the performance judgment result of the API interface. Based on this information, performance judgment can be performed to meet the needs of monitoring abnormal risk points. For example, by combining the request time and the request method, the average response time or maximum response time under different request methods can be calculated to evaluate the performance of the interface. At the same time, according to the type of browser from which the request comes, the interval time between requests sent by different browsers under a certain request method can be counted, and corresponding judgments and processing can be made accordingly.

[0071] 2.2) Access legal compliance analysis model: Audit and analyze interface request messages, response messages, structures, etc. to determine whether they are abnormal interfaces. At the same time, monitor abnormal interfaces. If a large amount of data is transmitted on the interface, it is determined that an attack may have occurred and an alarm will be generated immediately.

[0072] refer to Figure 6 The process of performing access legal compliance analysis based on the access legal compliance analysis model is as follows: Based on the performance judgment results, the abnormal risk points of the interface are monitored if the conditions for monitoring abnormal risk points are met. For example, the request content, response content, interface information, access source, account, interface performance, business system, access target object, etc. of the message in the interface are mainly monitored. Behavioral defect analysis is performed on abnormal risk points, mainly interface request message analysis, response message analysis and structure analysis. The abnormal interface is found through the analysis results. If it is an abnormal interface, abnormal interface detection is performed; if it is not an abnormal interface, abnormal risk point monitoring is returned. For example, the abnormal interface can be judged through the following steps: Interface request message analysis: Get the interface request message, including the request header, request method, URL, parameters, etc. Then, use appropriate tools or methods to parse the message and extract key information. For example, commonly used tools include Wireshark, Postman, etc. Based on the information in the message, judge the legitimacy and consistency of the request. At the same time, check whether the URL complies with the interface specifications and whether the parameters are correct. Finally, analyze the source IP address and user information of the request, which can be combined with access logs, identity authentication, etc. to determine whether there are abnormal requests.

[0073] Response message analysis: Get the interface response message, including the response header, status code, content, etc. Parse the response message and extract key information. At the same time, check the response status code to ensure that the returned result meets expectations. Finally, analyze the response content, including data format, return value, etc., to determine whether there are any abnormalities.

[0074] Structural analysis: If the interface returns structured data, such as JSON or XML, you can perform structural analysis. Parse the structure of the response content and find specific fields or key information. Analyze the integrity of the structure, field type, data range, etc. to observe whether there are any abnormal situations or abnormal interfaces.

[0075] Through the above analysis, potential abnormal interfaces can be found. Possible signs include: frequent requests for a specific interface but the interface is not used in the business logic, abnormal status codes or error messages in the response message, and invalid or expired fields in the structure. After discovering potential abnormal interfaces, you can further track the source code that calls the interface, and conduct evaluation and cleanup to ensure the security and robustness of the system.

[0076] Finally, monitor the abnormal interface to determine whether there is a large amount of data transmission. If there is a large amount of data transmission, an attack alarm will be issued. If not, return to abnormal risk point monitoring.

[0077] (3) Full-link tracing of interface business traceability: mainly includes API call chain modeling (refer to Figure 2 ) and API traceability (reference Figure 3 ).

[0078] The API risk tracing method based on link analysis provided in the embodiment of the present invention solves the problem of comprehensive API tracing and tracking, and proposes a method for realizing API tracing by using an http protocol analysis model and an access legal compliance analysis model. Compared with the prior art, it has the following advantages: 1) Clear data source: The API in the business system may call data from multiple sources. The embodiment of the present invention can identify the source of each data by identifying the identifier in the data message and then processing it through the protocol analysis model.

[0079] 2) Ability to assess API risks: APIs in the business system are chained and modeled in a pre-configured manner, so that all APIs are included in the scope of risk assessment.

[0080] 3) The embodiments of the present invention are highly targeted. Based on the analysis of the API call chain, it can locate risks according to different API usage situations. By pre-establishing a chain model and an analysis model, it solves the problem that manual classification and investigation is difficult to locate risky APIs in a short time. The application model can realize automated traceability and investigation, which can greatly improve the traceability efficiency of business interface risks.

[0081] 4) The embodiment of the present invention can quickly and accurately locate the link where the risk is located by modeling and analyzing the API call chain model, which can effectively make up for the defects of low handling efficiency and inability to accurately locate in the existing technology. When an external attack behavior generates a threat alarm, it can achieve extremely fast positioning. After changing the existing mode alarm, the risk hidden danger cannot be completely eliminated if the connection before and after the attack is not checked in time.

[0082] The interface risk tracing device provided by the present invention is described below. The interface risk tracing device described below and the interface risk tracing method described above can be referenced to each other.

[0083] refer to Figure 7 The interface risk tracing device provided by the present invention includes a protocol analysis module 701, a risk point monitoring module 702 and a risk tracing module 703.

[0084] The protocol analysis module 701 is used to perform protocol analysis on the application programming interface API interface information to obtain the performance judgment result of the API interface; The risk point monitoring module 702 is used to monitor the abnormal risk points of the API interface according to the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally used; The risk tracing module 703 is used to perform risk tracing according to the abnormal interface.

[0085] The interface risk tracing device provided by the embodiment of the present invention performs protocol analysis on the API interface information to obtain the performance judgment result of the API interface; monitors the API interface for abnormal risk points according to the performance judgment result to obtain abnormal interfaces; abnormal interfaces represent interfaces that have been abandoned or no longer used, but exist in the code or are abnormally used; and risk tracing is performed according to the abnormal interfaces. The present invention determines the risk nodes by performing protocol analysis and access legal compliance analysis on the API interface information, and then performs risk tracing on the risk nodes, thereby improving the accuracy of tracing.

[0086] In one embodiment, the protocol analysis module 701 is specifically used to: Acquire the message information of the API interface from the API interface information; Acquire the response time and request time of the message according to the message information, and use the difference between the response time and the request time as the first processing time of the message; If the first processing time is greater than a set threshold, the request mode of the message is obtained, and the average processing time of the request mode is determined; the average processing time is the average of the processing time of all messages with the same request mode; If the first processing time is greater than the average processing time, obtaining a browser from which the request for the message originates; Obtaining a second processing time required by the browser to process a message corresponding to the request method; If the first processing time is greater than the second processing time, it is determined that the performance judgment result is that there is a performance abnormality in the API interface.

[0087] In one embodiment, the risk point monitoring module 702 is specifically used to: If the performance judgment result is that the API interface has a performance abnormality, then performing interface request message analysis, response message analysis, and structure analysis on the API interface; When the interface request message analysis result, the response message analysis result, and the structure analysis result are all abnormal, determining that the API interface is the abnormal interface; Among them, the abnormal results of interface request message analysis include at least one of request header abnormality, request method abnormality, request parameter abnormality, path and uniform resource locator URL abnormality and request body abnormality; the abnormal results of response message analysis include at least one of response status code abnormality, response header abnormality, response body abnormality and business logic abnormality; the abnormal results of structure analysis include at least one of missing data field, field type mismatch, incorrect field format, illegal field value and inconsistent structure.

[0088] In one embodiment, the risk point monitoring module 702 is specifically used to: Determine whether the request message of the API interface meets the expected format and protocol requirements, and check whether the request message can be correctly received and processed by the API interface; Analyze the response message of the API interface, including: Verify whether the response of the API interface meets expectations, and check whether the API interface returns correct data or error information normally; Performing structural analysis on the API interface includes: Check whether the data structure of the API interface conforms to the preset structure.

[0089] In one embodiment, the risk tracing module 703 is specifically used to: According to the pre-built API call chain model, the data flow track corresponding to the abnormal interface is restored; the API call chain model is used to describe the calling sequence and dependency relationship of the API interface; Generate a business system process relationship link according to the data flow trajectory; Risk tracing is performed based on the business system process relationship link.

[0090] In one embodiment, the risk tracing module 703 is specifically used to: Define the API interface according to the interface requirement information; Establish connections between the API interfaces, and combine multiple APIs in order according to business demand information to obtain an initial call chain model; Configure the calling parameters of each of the API interfaces in the initial calling chain model; The initial call chain model is tested, and if the test is successful, the call chain model is obtained.

[0091] Figure 8 An example of a physical structure diagram of an electronic device is shown in FIG. Figure 8As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830 and a communication bus 840, wherein the processor 810, the communication interface 820 and the memory 830 communicate with each other through the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the interface risk tracing method, which includes: performing protocol analysis on the application programming interface API interface information to obtain the performance judgment result of the API interface; performing abnormal risk point monitoring on the API interface according to the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally used; and performing risk tracing according to the abnormal interface.

[0092] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0093] On the other hand, the present invention also provides a computer program product, which includes a computer program. The computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the interface risk tracing method provided by the above methods, which method includes: performing protocol analysis on the application programming interface API interface information to obtain a performance judgment result of the API interface; monitoring the API interface for abnormal risk points based on the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally used; and performing risk tracing based on the abnormal interface.

[0094] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it is implemented to execute the interface risk tracing method provided by the above-mentioned methods, the method comprising: performing protocol analysis on the application programming interface API interface information to obtain a performance judgment result of the API interface; monitoring the API interface for abnormal risk points based on the performance judgment result to obtain an abnormal interface; the abnormal interface represents an interface that has been abandoned or is no longer used, but exists in the code or is abnormally utilized; and performing risk tracing based on the abnormal interface.

[0095] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0096] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0097] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An interface risk tracing method, characterized in that: include: Perform protocol analysis on the application programming interface (API) interface information to obtain the performance judgment result of the API interface; According to the performance judgment result, the API interface is monitored for abnormal risk points to obtain an abnormal interface; The abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally utilized; Risk tracing is performed based on the abnormal interface.

2. The interface risk tracing method according to claim 1, characterized in that: The protocol analysis of the application programming interface API interface information is performed to obtain the performance judgment result of the API interface, including: Acquire the message information of the API interface from the API interface information; Acquire the response time and request time of the message according to the message information, and use the difference between the response time and the request time as the first processing time of the message; If the first processing time is greater than a set threshold, the request mode of the message is obtained, and the average processing time of the request mode is determined; the average processing time is the average of the processing time of all messages with the same request mode; If the first processing time is greater than the average processing time, obtaining a browser from which the request for the message originates; Obtaining a second processing time required by the browser to process a message corresponding to the request method; If the first processing time is greater than the second processing time, it is determined that the performance judgment result is that there is a performance abnormality in the API interface.

3. The interface risk tracing method according to claim 1 is characterized in that: The step of monitoring the API interface for abnormal risk points according to the performance judgment result to obtain an abnormal interface includes: If the performance judgment result is that the API interface has a performance abnormality, then performing interface request message analysis, response message analysis, and structure analysis on the API interface; When the interface request message analysis result, the response message analysis result, and the structure analysis result are all abnormal, determining that the API interface is the abnormal interface; Among them, the abnormal results of interface request message analysis include at least one of request header abnormality, request method abnormality, request parameter abnormality, path and uniform resource locator URL abnormality and request body abnormality; the abnormal results of response message analysis include at least one of response status code abnormality, response header abnormality, response body abnormality and business logic abnormality; the abnormal results of structure analysis include at least one of missing data field, field type mismatch, incorrect field format, illegal field value and inconsistent structure.

4. The interface risk tracing method according to claim 3 is characterized in that: Performing interface request message analysis on the API interface includes: Determine whether the request message of the API interface meets the expected format and protocol requirements, and check whether the request message can be correctly received and processed by the API interface; Analyze the response message of the API interface, including: Verify whether the response of the API interface meets expectations, and check whether the API interface returns correct data or error information normally; Performing structural analysis on the API interface includes: Check whether the data structure of the API interface conforms to the preset structure.

5. The interface risk tracing method according to claim 1, characterized in that: The risk tracing according to the abnormal interface includes: According to the pre-built API call chain model, the data flow track corresponding to the abnormal interface is restored; the API call chain model is used to describe the calling sequence and dependency relationship of the API interface; Generate a business system process relationship link according to the data flow trajectory; Risk tracing is performed based on the business system process relationship link.

6. The interface risk tracing method according to claim 5 is characterized in that: The API call chain model is constructed based on the following method: Define the API interface according to the interface requirement information; Establish connections between the API interfaces, and combine multiple APIs in order according to business demand information to obtain an initial call chain model; Configure the calling parameters of each of the API interfaces in the initial calling chain model; The initial call chain model is tested, and if the test is successful, the call chain model is obtained.

7. An interface risk tracing device, characterized in that: include: The protocol analysis module is used to perform protocol analysis on the application programming interface (API) interface information to obtain the performance judgment result of the API interface; A risk point monitoring module, used to monitor abnormal risk points of the API interface according to the performance judgment result to obtain an abnormal interface; The abnormal interface represents an interface that has been abandoned or no longer used, but exists in the code or is abnormally utilized; The risk tracing module is used to perform risk tracing based on the abnormal interface.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the interface risk tracing method as described in any one of claims 1 to 6 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the interface risk tracing method as described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the interface risk tracing method as described in any one of claims 1 to 6 is implemented.

Images