Interface risk mining method and device, storage medium and terminal

Abstract

The embodiment of the invention discloses an interface risk mining method and device, a storage medium and a terminal. Determining a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface; when an access operation for the target interface is monitored, obtaining a current response parameter returned after the target interface responds to the access operation; and verifying the current response parameter according to the credible response parameter baseline, and determining the risk state of the target interface according to the verification result. The credible response parameter base line of the target interface is determined according to the historical flow behavior log of the interface, so that the response parameter output information conforming to the expectation under the normal condition of the interface can be reflected; if the target interface has a new access operation, the output parameter of the access operation can be verified according to the credible response parameter baseline, so that whether the access belongs to normal access or not is verified, and the potential attack risk faced by the output interface can be effectively mined according to the verification result.

Description

Technical Field

[0001] The embodiments of the present specification relate to the field of computer technology, and in particular, to an interface risk mining method, device, storage medium, and terminal. Background Art

[0002] With the development and progress of current Internet technology, developers have developed and applied a large number of application programming interfaces (APIs) in various scenarios to meet diverse needs. As a bridge for communication between software systems, the core function of API is to achieve mutual access and information exchange between different systems, accelerating the rapid update and innovation of functions. However, due to some defects and problems caused by improper configuration during the design and implementation process, API has become one of the key targets of hacker attacks. When API is attacked, it may lead to user privacy leakage or interruption of key services. Summary of the invention

[0003] The embodiments of this specification provide an interface risk mining method, device, storage medium and terminal, which can solve the technical problem that it is difficult to discover the risks existing in the interface in advance in the related technology.

[0004] In a first aspect, an embodiment of the present specification provides an interface risk mining method, the method comprising:

[0005] Determine a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface;

[0006] When an access operation to the target interface is detected, a current response parameter returned by the target interface in response to the access operation is obtained;

[0007] The current response parameter is verified according to the trusted response parameter baseline, and the risk status of the target interface is determined according to the verification result.

[0008] In a possible implementation, the above-mentioned method of determining a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface includes: collecting the historical traffic behavior log of the target interface, and parsing the historical traffic behavior log to obtain the historical response parameter information of the target interface; and constructing a trusted response parameter baseline corresponding to the target interface based on the historical response parameter information.

[0009] In a possible implementation, the above-mentioned collection of historical traffic behavior logs of the target interface includes: determining a preset time window corresponding to a trusted response parameter baseline based on a high-confidence time period of the target interface, and collecting the historical traffic behavior logs of the above-mentioned target interface within the above-mentioned preset time window.

[0010] In a possible implementation, the above-mentioned determination of the risk status of the above-mentioned target interface based on the verification result includes: if the above-mentioned current response parameters meet the above-mentioned trusted response parameter baseline, then the above-mentioned target interface is determined to be a secure interface, and the above-mentioned access operation is processed in a normal response; if the above-mentioned current response parameters do not meet the above-mentioned trusted response parameter baseline, then the above-mentioned target interface is determined to be a risky interface, and the above-mentioned access operation is processed in an intercepted response.

[0011] In a possible implementation, after determining that the target interface is a risk interface, it also includes: obtaining all interface asset information in the application system, determining at least one associated interface corresponding to the risk interface based on the full interface asset information, and the correlation between each associated interface and the risk interface meets preset related conditions; performing risk assessment on each associated interface based on the trusted response parameter baseline corresponding to each associated interface, and determining the risk status of each associated interface according to the risk assessment results of each associated interface.

[0012] In a possible implementation, after determining that the target interface is a risk interface, it also includes: generating a risk information report for the risk interface, and sending the risk information report to a management terminal corresponding to the risk interface; receiving a monitoring and defense strategy returned by the management terminal in response to the risk information report, and configuring the risk interface based on the monitoring and defense strategy.

[0013] In a second aspect, an embodiment of the present specification provides an interface risk mining device, the device comprising:

[0014] A trusted policy generation module, used to determine a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface;

[0015] An access operation acquisition module is used to, when an access operation to the target interface is detected, acquire a current response parameter returned by the target interface in response to the access operation;

[0016] The expected response verification module is used to verify the above-mentioned current response parameters according to the above-mentioned trusted response parameter baseline, and determine the risk status of the above-mentioned target interface according to the verification result.

[0017] In a third aspect, an embodiment of the present specification provides a computer program product comprising instructions, which, when executed on a computer or a processor, enables the computer or the processor to execute the steps of the above method.

[0018] In a fourth aspect, an embodiment of the present specification provides a computer storage medium, wherein the computer storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the steps of the above method.

[0019] In a fifth aspect, an embodiment of the present specification provides a terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is suitable for being loaded by the processor and executing the steps of the above method.

[0020] The beneficial effects brought by the technical solutions provided by some embodiments of this specification include at least:

[0021] The embodiment of this specification provides an interface risk mining method, which determines the trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface; when the access operation to the target interface is monitored, the current response parameter returned by the target interface after responding to the access operation is obtained; the current response parameter is verified according to the trusted response parameter baseline, and the risk status of the target interface is determined according to the verification result. Since the output parameter information of the target interface after responding to the request is unified when it is normally accessed, when the target interface returns uncommon output parameter information, it indicates that there is a difference between this access and most normal accesses. Based on this, in the embodiment of this specification, the trusted response parameter baseline of the target interface is determined according to the historical traffic behavior log of the interface, and the trusted response parameter baseline can reflect the expected response output parameter information of the interface under normal circumstances; then when a new access operation occurs on the target interface, the output parameter of this access operation can be verified according to the trusted response parameter baseline, and whether this access belongs to normal access can be determined according to the verification result, thereby effectively mining the potential attack risk of the interface, facilitating the subsequent accurate monitoring and security defense of the risky interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 An exemplary system architecture diagram of an interface risk mining method provided in an embodiment of this specification;

[0024] Figure 2 A flowchart of an interface risk mining method provided in an embodiment of this specification;

[0025] Figure 3 A flowchart of an interface risk mining method provided in an embodiment of this specification;

[0026] Figure 4 A strategy generation flow chart of an interface risk mining method provided in an embodiment of this specification;

[0027] Figure 5 A structural block diagram of an interface risk mining device provided in an embodiment of this specification;

[0028] Figure 6 A schematic diagram of the structure of a terminal provided in an embodiment of this specification. DETAILED DESCRIPTION

[0029] In order to make the features and advantages of the embodiments of this specification more obvious and easy to understand, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the embodiments of this specification.

[0030] When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of the embodiments of this specification as detailed in the appended claims. And in the description of the embodiments of this specification, unless otherwise indicated, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B, can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of this specification, "multiple" refers to two or more than two.

[0031] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.

[0032] Application Programming Interface (API) is a way for software systems to access and exchange information with each other. The API interface defines the way to call another application (or service) in one application, allowing developers to interact only through the API interface without knowing the specific implementation details inside the program, thereby improving the reusability and interoperability of the software. As a medium for sharing and communicating functional modules and data resources between software systems, the core role of API is to achieve mutual access and information exchange between different systems, so as to flexibly and efficiently meet the increasingly complex and changing needs of users. For example, a social application can share location by calling the map API, while an e-commerce platform can use the payment API to provide users with a smooth online shopping payment experience.

[0033] However, while APIs bring many conveniences, their security issues are becoming increasingly prominent, and they have become one of the key targets of hacker attacks. For example, a common interface attack method is a database collision attack, which is a network attack that uses an automatic mechanism. Since people often reuse the same password for multiple accounts, the success rate of such attacks is very high. After attackers find a set of valid credentials, they may use these credentials to illegally access other websites and interfaces, or sell verified credentials to other criminals for data theft, account takeover (ATO), and other fraudulent activities. Database collision attacks have no rules, so they are not easy to identify and prevent, and they are also very difficult to intercept. Once an API is attacked, it may not only lead to the leakage of user privacy, but also have a serious impact on the normal operation of key services, and even cause systemic security risks.

[0034] Therefore, the embodiments of this specification provide an interface risk mining method, which determines the trusted response parameter baseline of the target interface based on the historical traffic behavior log of the interface. The trusted response parameter baseline can reflect the expected response output parameter information of the interface under normal circumstances; then when a new access operation occurs on the target interface, the output parameters of this access operation can be verified according to the trusted response parameter baseline, and it can be determined whether this access is a normal access based on the verification result, thereby effectively mining the potential attack risks of the interface, so as to solve the above-mentioned technical problem that it is difficult to discover the risks of the interface in advance.

[0035] See also Figure 1 , Figure 1 An exemplary system architecture diagram of an interface risk mining method provided in an embodiment of this specification.

[0036] like Figure 1As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 is used to provide a medium for a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired communication links or wireless communication links, for example, the wired communication link includes an optical fiber, a twisted pair, or a coaxial cable, and the wireless communication link includes a Bluetooth communication link, a Wireless-Fidelity (Wi-Fi) communication link, or a microwave communication link.

[0037] The terminal 101 can interact with the server 103 through the network 102 to receive messages from the server 103 or send messages to the server 103, or the terminal 101 can interact with the server 103 through the network 102 to receive messages or data sent by other users to the server 103. The terminal 101 can be hardware or software. When the terminal 101 is hardware, it can be various electronic devices, including but not limited to smart watches, smart phones, tablet computers, laptop portable computers and desktop computers. When the terminal 101 is software, it can be installed in the electronic devices listed above, which can be implemented as multiple software or software modules (for example: used to provide distributed services), or it can be implemented as a single software or software module, which is not specifically limited here.

[0038] In an embodiment of the present specification, terminal 101 first determines a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface; then, when terminal 101 detects an access operation to the target interface, it obtains the current response parameters returned by the target interface in response to the access operation; at this time, terminal 101 verifies the current response parameters according to the trusted response parameter baseline, and determines the risk status of the target interface according to the verification result.

[0039] The server 103 may be a business server that provides various services. It should be noted that the server 103 may be hardware or software. When the server 103 is hardware, it may be implemented as a distributed server cluster consisting of multiple servers, or it may be implemented as a single server. When the server 103 is software, it may be implemented as multiple software or software modules (for example, for providing distributed services), or it may be implemented as a single software or software module, which is not specifically limited here.

[0040] Alternatively, the system architecture may not include the server 103. In other words, the server 103 may be an optional device in the embodiments of this specification, that is, the method provided in the embodiments of this specification may be applied to a system structure that only includes the terminal 101, and the embodiments of this specification do not limit this.

[0041] It should be understood that Figure 1The number of terminals, networks and servers in the figure is only for illustration and any number of terminals, networks and servers may be used according to implementation requirements.

[0042] See also Figure 2 , Figure 2 A flowchart of an interface risk mining method provided in an embodiment of this specification. The execution subject of the embodiment of this specification can be a terminal that executes interface risk mining, or a processor in the terminal that executes the interface risk mining method, or an interface risk mining service in the terminal that executes the interface risk mining method. For the convenience of description, the specific execution process of the interface risk mining method is introduced below by taking the execution subject being the processor in the terminal as an example.

[0043] like Figure 2 As shown, the interface risk mining method may at least include:

[0044] S202: Determine a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface.

[0045] Optionally, in order to grasp the interaction process between the target interface and the user's access operation, a traffic behavior log is usually generated for all data behaviors involved in the target interface. Through a series of strict security control measures and verification mechanisms, including but not limited to user identity authentication, authority management, data encryption transmission, and real-time monitoring and analysis of access logs, users need to undergo security verification and perform normal behaviors before they can access the target interface, so that it can be determined that most of the access to the target interface is reliable and secure access. In other words, the historical traffic behavior log of the target interface has recorded the normal access operations performed by a large number of users on the target interface in the past, so a large amount of reliable access information can be obtained from the historical traffic behavior log.

[0046] Optionally, since the interface always responds consistently and returns parameters with fixed parameter types when accessed normally, by deeply mining and analyzing these historical data, statistics and calculations are performed on the information related to the response parameters in the historical traffic behavior log of the target interface, the specific response mode of the interface under normal circumstances can be further identified, including but not limited to: which output parameter types are common, which output parameter types are abnormal, which output parameter formats are standard, and the response speed of the interface under different time periods or different loads, the number of responses of the interface within a period of time, etc. These statistical data can construct an effective trusted response parameter baseline for the target interface, and the trusted response parameter baseline can be used to reflect the expected response behavior of the target interface to normal access. The trusted response parameter baseline is then used to verify the output parameter information returned by the target interface for the access operation, so that the risks existing in the current access to the target interface can be clarified.

[0047] It should be noted that the target interface can be an interface that needs risk identification determined from all interfaces, such as a payment interface, an information call interface, etc. For some interfaces with routine functions, baseline construction and risk mining may not be performed.

[0048] S204: When an access operation to a target interface is detected, a current response parameter returned by the target interface in response to the access operation is obtained.

[0049] Optionally, in the actual application scenario where the target interface is located, the access operations of the target interface can be monitored to promptly capture and record all access operations that occur to the target interface, whether these operations are part of the normal cloud original god process or potential security threat attempts. Specifically, when a new access request arrives at the target interface, the current response parameters returned by the target interface in response to the access request will be immediately obtained, including but not limited to key information such as data content, format, status code, etc. This information is obtained in real time to ensure the timeliness and accuracy of the data. Timely check whether there is a significant deviation between the output parameters of the interface for this request and the expected trusted response output parameter baseline, so as to determine whether the access operation corresponding to this request is a normal access operation, realize dynamic monitoring of access operations, and explore the risks that the interface may face.

[0050] S206: Verify the current response parameter according to the trusted response parameter baseline, and determine the risk status of the target interface according to the verification result.

[0051] Optionally, the captured current response parameters are compared and verified with the preset trusted response output parameter baseline. From the introduction of the above embodiment, it can be known that the trusted response output parameter baseline is obtained by counting and calculating a large number of normal response parameters based on historical traffic behavior logs. It represents the characteristics that a normal and compliant interface response should have. The comparison and verification process involves multiple dimensions, such as parameter integrity, consistency, compliance, etc., which aims to comprehensively evaluate whether the output parameters of the interface for this request are consistent with the expected trusted response output parameter baseline.

[0052] Furthermore, if the verification result shows that there is a significant deviation between the output baseline of the interface for this request, such as abnormal data content, format mismatch, status code error, etc., it means that the access operation corresponding to this request may be abnormal. On the contrary, if the verification result shows the degree of conformity between the current response parameters and the trusted response parameter baseline, it can be said that the access operation corresponding to this request is a safe access operation. In this way, we can not only timely discover potential security risks such as malicious attacks and data tampering, but also deeply explore other risks that the interface may face, such as performance bottlenecks and resource leakage. This is of great significance to improving the overall security, stability and user experience of the system. At the same time, this dynamic monitoring mechanism also provides strong data support and decision-making basis for subsequent troubleshooting, performance optimization and the formulation of security protection strategies.

[0053] In one possible implementation, the verification and judgment process can be based on big data analysis and machine learning algorithms, so that the model can be pre-trained to automatically adapt to and identify abnormal behavior patterns in various complex scenarios, thereby achieving dynamic monitoring of access operations.

[0054] In an embodiment of the present specification, an interface risk mining method is provided, which determines the trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface; when an access operation to the target interface is monitored, the current response parameter returned by the target interface after responding to the access operation is obtained; the current response parameter is verified according to the trusted response parameter baseline, and the risk status of the target interface is determined according to the verification result. Since the output parameter information of the target interface after responding to the request is uniform when it is normally accessed, when the target interface returns uncommon output parameter information, it indicates that there is a difference between this access and most normal accesses. Based on this, in an embodiment of the present specification, the trusted response parameter baseline of the target interface is determined according to the historical traffic behavior log of the interface, and the trusted response parameter baseline can reflect the expected response output parameter information of the interface under normal circumstances; then when a new access operation occurs on the target interface, the output parameter of this access operation can be verified according to the trusted response parameter baseline, and whether this access belongs to normal access can be determined according to the verification result, thereby effectively mining the potential attack risk of the interface, facilitating the subsequent accurate monitoring and security defense of the risky interface.

[0055] See also Figure 3 , Figure 3 A flowchart of an interface risk mining method provided in an embodiment of this specification.

[0056] like Figure 3 As shown, the interface risk mining method may at least include:

[0057] S302: Collect historical traffic behavior logs of the target interface, and parse the historical traffic behavior logs to obtain historical response parameter information of the target interface.

[0058] Optionally, see Figure 4 , Figure 4 This is a strategy generation flow chart of an interface risk mining method provided in an embodiment of this specification. Figure 4 As shown in the figure, generally speaking, a user initiates an access request to a target interface, and after the access request reaches the target interface, it will be responded to by the target interface. Then the target interface will generate and return the corresponding output parameters to the user end, and the exchange of these parameters will be recorded and stored in the historical traffic behavior log. In order to build a trusted response parameter baseline, it is necessary to parse the historical traffic behavior log to obtain the historical response parameter information corresponding to the target interface.

[0059] In a possible embodiment, as the target interface continues to run and use in the actual application environment, its full historical traffic behavior log may cover data records spanning several years. During this period, in order to meet the ever-changing user needs and the requirements of technological development, the target interface itself is likely to have undergone multiple iterations and upgrades. Each iteration may be accompanied by the enhancement of interface functions, the optimization of performance, or the improvement of security. These changes directly lead to the corresponding adjustment of interface input parameters (input parameters) and output parameters (output parameters). Therefore, for the access operations that need to be verified at present, directly referring to the full historical traffic behavior log may not have sufficient accuracy. If you try to build a reliable parameter baseline based on all historical traffic behavior logs, first of all, the difficulty of data integration and analysis is relatively large, and secondly, it may also mislead the determination of the current baseline, resulting in unreliable baselines. In contrast, the historical traffic behavior logs in the recent period can better reflect the current actual operation status and user access mode of the interface, and thus have a higher reference value for evaluating the effectiveness and security of access operations. Therefore, in actual operation, a more reasonable approach is to select the traffic behavior logs in the recent period as the main basis for building parameter baselines based on the current version and status of the interface. This not only improves the accuracy and reliability of the baseline, but also effectively saves computing resources and improves the efficiency of system verification.

[0060] Specifically, the preset time window corresponding to the trusted response parameter baseline can be determined based on the high confidence time period of the target interface, and the historical traffic behavior log of the target interface within the preset time window can be collected. The historical response parameter information of the target interface is obtained by parsing this part of the historical traffic behavior log. The high confidence time period is determined according to the current state and version of the target interface. The data within this period can accurately reflect the characteristics of the current normal response parameters. The specific values ​​can be, for example, 7 days, 30 days, etc., obtained by technical personnel through statistics, research and other means. The embodiments of this specification do not limit the method for determining the high confidence time period.

[0061] S304: Construct a trusted response parameter baseline corresponding to the target interface based on the historical response parameter information.

[0062] Optionally, see Figure 4 When building a trusted response parameter baseline, you can specifically parse the parameter type and parameter value output after the interface responds to the request, and then calculate the distribution of the parameters, and finally determine the expected trusted response parameter baseline. Specifically, first, the parameter value and parameter type of the parameter output after the interface responds to the request are deeply analyzed, and the analysis results are the basis for the subsequent establishment of the baseline. Next, it is necessary to calculate the distribution of the parameters, including the frequency of occurrence of each parameter value, the mean, variance, median and other statistical quantities of the calculated parameters, etc. The distribution of the output parameters can reflect the rules and characteristics of the interface response. Finally, based on the above various parameter information, the trusted response parameter baseline of the "normal" or "trusted" range of the interface response parameters can be determined. The baseline can help the system quickly and accurately identify abnormal or untrusted responses in subsequent interface calls and response verifications.

[0063] Furthermore, if Figure 4 As shown in the figure, after building the trusted response parameter baseline, the interface risk mining strategy based on the trusted response parameter baseline must be determined. In the interface risk mining strategy, it is stipulated that the response parameters output by the target interface in the actual application scenario must be compared and verified with the trusted response baseline parameters, and when the two do not match, it is determined that the current access request has a risk, and when the two match, it is determined that the current access request is a normal access.

[0064] S306: When an access operation to the target interface is detected, a current response parameter returned by the target interface in response to the access operation is obtained.

[0065] Regarding step S306, please refer to the detailed description in step S204, which will not be repeated here.

[0066] S308. Verify the current response parameters according to the trusted response parameter baseline; if the current response parameters meet the trusted response parameter baseline, determine the target interface as a secure interface, and perform normal response processing on the access operation; if the current response parameters do not meet the trusted response parameter baseline, determine the target interface as a risky interface, and perform intercept response processing on the access operation.

[0067] Optionally, see Figure 4 In actual application scenarios, when a user initiates access to a target interface, the target interface will return the corresponding response parameters for the access request. At this time, the current response parameters can be verified according to the trusted response parameter baseline. Specifically, the trusted response parameter baseline is compared with the current response parameters. If the current response parameters do not match the trusted response parameter baseline, the access operation can be determined to be a risky access operation. Otherwise, the access operation is a safe access operation.

[0068] Specifically, when a risky access operation is encountered, it indicates that the target interface is determined to be a risky interface, and it is necessary to respond to the risky access operation in a timely manner, such as interception processing, intercepting the risky access operation itself, and interrupting the target interface's response to it. At the same time, it is also necessary to further accurately monitor and securely defend the risky interface. If the access operation is a secure access operation, the target interface is determined to be a secure interface, and it can continue to respond normally. All interaction information between this secure access operation and the target interface will be recorded and stored in the form of traffic behavior logs, which will be used to iterate and update the trusted response parameter baseline in the future.

[0069] S310: If the target interface is a risk interface, obtain the full interface asset information in the application system, determine at least one associated interface corresponding to the risk interface based on the full interface asset information, and the correlation between each associated interface and the risk interface meets the preset related conditions.

[0070] Optionally, considering that the function implementation process often involves the linkage of multiple interfaces, these interfaces are interrelated and called on each other on the function line to meet user needs. Therefore, if the target interface is a risky interface, then the interfaces associated with it may also be risky. Based on this, please refer to Figure 4 , obtain the full amount of interface asset information in the application system, which includes the interface data of all interfaces used in the application, and determine at least one associated interface corresponding to the risk interface. The associated interface is the interface whose correlation with the risk interface meets the preset related conditions. The preset related conditions can be formulated according to actual needs, for example, it can be "on the same functional line", "with similar functions", "with mutual calling relationship", etc.

[0071] S312: Perform risk assessment on each associated interface based on the trusted response parameter baseline corresponding to each associated interface, and determine the risk status of each associated interface according to the risk assessment result of each associated interface.

[0072] Optionally, after determining each associated interface, targeted risk assessment is performed on each associated interface based on the trusted response parameter baseline corresponding to each associated interface, and then the risk status of each associated interface is determined according to the risk assessment results of each associated interface. In this way, based on the association relationship between interfaces, the related interfaces with risks can be efficiently determined through line expansion operations, thereby improving the efficiency of risk mining.

[0073] S314: Generate a risk information report for the risk interface, and send the risk information report to the management end corresponding to the risk interface; receive the monitoring and defense strategy returned by the management end in response to the risk information report, and configure the risk interface based on the monitoring and defense strategy.

[0074] Optionally, for risky interfaces, further research and verification can be performed to verify the security of the risky interfaces again to avoid the impact of misjudgment on normal interfaces.

[0075] Specifically, in order to analyze and process risk access operations, a management terminal can be set up to perform secondary analysis on risk interfaces. Then, after determining the risk interface, the risk information report corresponding to the risk interface is obtained, and the risk information report is sent to the management terminal, wherein the risk information report is a report further generated based on the current response parameter information and the verification result, which can be submitted in a form such as a table or a form that is easy for the management terminal to identify and view. The management terminal outputs a monitoring and defense strategy for the risk information report, and subsequently configures the risk interface based on the monitoring and defense strategy. The monitoring and defense strategy mainly formulates security defense measures for the target interface based on the specific information in the risk information report, such as initiating a verification operation to the user himself to confirm whether it is the operation by himself, etc. Specifically, it can be a method of instructing the user himself to enter a verification code, perform a verification operation, etc. If the verification passes, the access operation is determined to be a safe access operation. If the verification fails, the access operation is intercepted, and the user himself is warned to perform security operations such as changing the password to ensure the security of the user account.

[0076] In an embodiment of the present specification, an interface risk mining method is provided, which determines the preset time window corresponding to the trusted response parameter baseline based on the high confidence time period of the target interface, collects the historical traffic behavior log of the target interface within the preset time window, improves the accuracy and reliability of the baseline, and can effectively save computing resources and improve the efficiency of system verification. A trusted response parameter baseline corresponding to the target interface is constructed based on historical response parameter information, and the current response parameter is verified according to the trusted response parameter baseline. According to the verification result, it is determined whether the current access is a normal access, thereby effectively mining the potential attack risk of the interface. Determine at least one associated interface corresponding to the risk interface, and conduct risk assessment results for each associated interface. In this way, based on the association relationship between the interfaces, the related interfaces with risks can be efficiently determined through the expansion operation, thereby improving the efficiency of risk mining. Configure monitoring and defense strategies for risk interfaces to achieve accurate monitoring and security defense.

[0077] See also Figure 5 , Figure 5 This is a structural block diagram of an interface risk mining device provided in an embodiment of this specification. Figure 5 As shown, the interface risk mining device 500 includes:

[0078] A trusted policy generation module 510, configured to determine a trusted response parameter baseline corresponding to a target interface based on a historical traffic behavior log of the target interface;

[0079] The access operation acquisition module 520 is used to acquire the current response parameters returned by the target interface after responding to the access operation when an access operation to the target interface is detected;

[0080] The expected response verification module 530 is used to verify the current response parameters according to the trusted response parameter baseline, and determine the risk status of the target interface according to the verification result.

[0081] Optionally, the trusted policy generation module 510 is also used to collect historical traffic behavior logs of the target interface, and parse the historical traffic behavior logs to obtain historical response parameter information of the target interface; and construct a trusted response parameter baseline corresponding to the target interface based on the historical response parameter information.

[0082] Optionally, the trusted policy generation module 510 is further used to determine a preset time window corresponding to the trusted response parameter baseline based on the high confidence time period of the target interface, and collect historical traffic behavior logs of the target interface within the preset time window.

[0083] Optionally, the expected response verification module 530 is also used to determine that the target interface is a secure interface and perform normal response processing on the access operation if the current response parameters meet the trusted response parameter baseline; if the current response parameters do not meet the trusted response parameter baseline, determine that the target interface is a risky interface and perform intercept response processing on the access operation.

[0084] Optionally, the interface risk mining device 500 also includes: an expansion risk mining module, which is used to obtain the full amount of interface asset information in the application system, determine at least one associated interface corresponding to the risk interface based on the full amount of interface asset information, and the correlation between each associated interface and the risk interface meets preset related conditions; based on the trusted response parameter baseline corresponding to each associated interface, each associated interface is subjected to risk assessment, and the risk status of each associated interface is determined according to the risk assessment results of each associated interface.

[0085] Optionally, the interface risk mining device 500 also includes: a security risk defense module, which is used to generate a risk information report for the risk interface and send the risk information report to the management end corresponding to the risk interface; receive the monitoring defense strategy returned by the management end for the risk information report, and configure the risk interface based on the monitoring defense strategy.

[0086] In an embodiment of the present specification, an interface risk mining device is provided, wherein a trusted policy generation module is used to determine the trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface; an access operation acquisition module is used to obtain the current response parameters returned by the target interface after responding to the access operation when the access operation to the target interface is monitored; an expected response verification module is used to verify the current response parameters according to the trusted response parameter baseline, and determine the risk status of the target interface according to the verification result. Since the target interface has uniform output parameter information after responding to the request when it is normally accessed, when the target interface returns uncommon output parameter information, it indicates that there is a difference between this access and most normal accesses. Based on this, in an embodiment of the present specification, the trusted response parameter baseline of the target interface is determined according to the historical traffic behavior log of the interface, and the trusted response parameter baseline can reflect the expected response output parameter information of the interface under normal circumstances; then when a new access operation occurs on the target interface, the output parameter of this access operation can be verified according to the trusted response parameter baseline, and whether this access belongs to normal access can be determined according to the verification result, thereby effectively mining the potential attack risk of the interface, and facilitating the subsequent accurate monitoring and security defense of the risky interface.

[0087] The embodiments of this specification provide a computer program product including instructions. When the computer program product is executed on a computer or a processor, the computer or the processor executes the steps of any one of the methods in the above embodiments.

[0088] The embodiments of this specification also provide a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded by a processor and executing the steps of any method in the above embodiments.

[0089] See also Figure 6 , Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 6 As shown, the terminal 600 may include: at least one terminal processor 601 , at least one network interface 604 , a user interface 603 , a memory 605 , and at least one communication bus 602 .

[0090] The communication bus 602 is used to realize the connection and communication between these components.

[0091] The user interface 603 may include a display screen (Display) and a camera (Camera), and the optional user interface 603 may also include a standard wired interface and a wireless interface.

[0092] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0093] Among them, the terminal processor 601 may include one or more processing cores. The terminal processor 601 uses various interfaces and lines to connect various parts in the entire terminal 600, and executes various functions and processes data of the terminal 600 by running or executing instructions, programs, code sets or instruction sets stored in the memory 605, and calling data stored in the memory 605. Optionally, the terminal processor 601 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The terminal processor 601 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the terminal processor 601, and it can be implemented separately through a chip.

[0094] Among them, the memory 605 may include a random access memory (Random Access Memory, RAM) and may also include a read-only memory (Read-Only Memory, ROM). Optionally, the memory 605 includes a non-transitory computer-readable storage medium. The memory 605 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 605 may also be optionally at least one storage device located away from the aforementioned terminal processor 601. As Figure 6 As shown, the memory 605 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an interface risk mining program.

[0095] exist Figure 6 In the terminal 600 shown, the user interface 603 is mainly used to provide an input interface for the user and obtain the data input by the user; and the terminal processor 601 can be used to call the interface risk mining program stored in the memory 605, and specifically perform the following operations:

[0096] Determine the trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface;

[0097] When an access operation to a target interface is detected, the current response parameters returned by the target interface in response to the access operation are obtained;

[0098] The current response parameters are verified according to the trusted response parameter baseline, and the risk status of the target interface is determined based on the verification results.

[0099] In some embodiments, when the terminal processor 601 determines the trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface, it specifically performs the following steps: collecting the historical traffic behavior log of the target interface, and parsing the historical traffic behavior log to obtain the historical response parameter information of the target interface; and constructing the trusted response parameter baseline corresponding to the target interface based on the historical response parameter information.

[0100] In some embodiments, when the terminal processor 601 executes the collection of historical traffic behavior logs of the target interface, it specifically performs the following steps: determining a preset time window corresponding to a trusted response parameter baseline based on a high confidence time period of the target interface, and collecting the historical traffic behavior logs of the target interface within the preset time window.

[0101] In some embodiments, when the terminal processor 601 determines the risk status of the target interface based on the verification results, it specifically performs the following steps: if the current response parameters meet the trusted response parameter baseline, the target interface is determined to be a secure interface, and the access operation is processed normally; if the current response parameters do not meet the trusted response parameter baseline, the target interface is determined to be a risky interface, and the access operation is intercepted and responded to.

[0102] In some embodiments, after determining that the target interface is a risk interface, the terminal processor 601 further specifically performs the following steps: obtaining all interface asset information in the application system, determining at least one associated interface corresponding to the risk interface based on the full interface asset information, and the correlation between each associated interface and the risk interface meets preset related conditions; performing risk assessment on each associated interface based on the trusted response parameter baseline corresponding to each associated interface, and determining the risk status of each associated interface according to the risk assessment results of each associated interface.

[0103] In some embodiments, after determining that the target interface is a risk interface, the terminal processor 601 further specifically performs the following steps: generating a risk information report for the risk interface, and sending the risk information report to the management end corresponding to the risk interface; receiving a monitoring and defense strategy returned by the management end in response to the risk information report, and configuring the risk interface based on the monitoring and defense strategy.

[0104] In the several embodiments provided in this specification, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules is only a logical function division, and there may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0105] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0106] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The above computer program product includes one or more computer instructions. When the above computer program instructions are loaded and executed on a computer, the above process or function according to the embodiment of this specification is generated in whole or in part. The above computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The above computer instructions can be stored in a computer-readable storage medium or transmitted by the above computer-readable storage medium. The above computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The above computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, data center, etc. that contains one or more available media integrated. The above-mentioned available media can be magnetic media (for example, floppy disks, hard disks, tapes), optical media (for example, digital versatile discs (DVD)), or semiconductor media (for example, solid state drives (SSD)), etc.

[0107] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0108] In addition, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions. For example, the historical traffic behavior logs, access operations, parameter information, etc. involved in this specification are all obtained with full authorization.

[0109] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0110] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0111] The above is a description of an interface risk mining method, device, storage medium and terminal provided in the embodiments of this specification. For technical personnel in this field, according to the ideas of the embodiments of this specification, there may be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the embodiments of this specification.

Claims

1. A method for interface risk mining, the method comprising: Determine a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface; When an access operation to the target interface is detected, a current response parameter returned by the target interface in response to the access operation is obtained; The current response parameter is verified according to the trusted response parameter baseline, and the risk status of the target interface is determined according to the verification result.

2. According to the method of claim 1, determining the trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface comprises: Collecting historical traffic behavior logs of the target interface, and parsing the historical traffic behavior logs to obtain historical response parameter information of the target interface; A trusted response parameter baseline corresponding to the target interface is constructed based on the historical response parameter information.

3. According to the method of claim 1, the collecting of historical traffic behavior logs of the target interface comprises: A preset time window corresponding to a trusted response parameter baseline is determined based on a high confidence time period of the target interface, and a historical traffic behavior log of the target interface within the preset time window is collected.

4. The method according to claim 1, wherein determining the risk status of the target interface according to the verification result comprises: If the current response parameter meets the trusted response parameter baseline, the target interface is determined to be a secure interface, and a normal response process is performed on the access operation; If the current response parameter does not meet the trusted response parameter baseline, the target interface is determined to be a risky interface, and an intercept response process is performed on the access operation.

5. The method according to claim 4, after determining that the target interface is a risk interface, further comprising: Acquire all interface asset information in the application system, and determine at least one associated interface corresponding to the risk interface according to the all interface asset information, wherein the correlation between each associated interface and the risk interface satisfies a preset related condition; Based on the trusted response parameter baselines corresponding to each associated interface, risk assessment is performed on each associated interface, and the risk status of each associated interface is determined according to the risk assessment results of each associated interface.

6. The method according to claim 4, after determining that the target interface is a risk interface, further comprising: Generate a risk information report for the risk interface, and send the risk information report to a management terminal corresponding to the risk interface; Receive the monitoring and defense strategy returned by the management end in response to the risk information report, and configure the risk interface based on the monitoring and defense strategy.

7. An interface risk mining device, the device comprising: A trusted policy generation module, used to determine a trusted response parameter baseline corresponding to the target interface based on the historical traffic behavior log of the target interface; An access operation acquisition module, used for, when an access operation to the target interface is detected, acquiring a current response parameter returned by the target interface in response to the access operation; The expected response verification module is used to verify the current response parameter according to the trusted response parameter baseline, and determine the risk status of the target interface according to the verification result.

8. A computer program product comprising instructions, which, when executed on a computer or a processor, causes the computer or the processor to execute the steps of the method according to any one of claims 1 to 6.

9. A computer storage medium storing a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the steps of the method according to any one of claims 1 to 6.

10. A terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 6 when executing the computer program.

Images