A risk API discovery method, a risk API discovery device, and a storage medium

Abstract

The embodiment of the application discloses a risk API discovery method, a risk API discovery device and a storage medium, and is used in the technical field of API. The method comprises the following steps: passively detecting API access traffic to obtain a first API path in the API access traffic; reconstructing the first API path based on a risk API rule to obtain a second API path after reconstruction, wherein the second API path is a risk API which should not be exposed to the external network; accessing the second API path to determine whether the second API path is exposed to the network, and performing security disposal on the second API path according to the determination result. In the embodiment of the application, the first API path is reconstructed to obtain the second API path, and the second API path is accessed, so that it can be determined whether the risk API corresponding to the second API path is exposed to the network, and the risk API can be processed before the risk API is accessed and utilized by the outside.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of API, and particularly relate to a risk API discovery method, a risk API discovery device and a storage medium. BACKGROUND

[0002] At present, in the field of data security, API (Application Programming Interface) is currently an explosive growth of external supply mode, and traditional products such as WAF (rule-based) or API gateway (service governance) are difficult to solve API-related security problems such as API asset discovery, API vulnerability discovery, and abnormal behavior monitoring.

[0003] At present, for API asset discovery and API vulnerability discovery, the main solution is to analyze mirror traffic, passively collect API information, and then analyze API-related vulnerabilities, and a small number of products will actively and automatically verify in the test environment. Specifically: 1. Passive discovery of API based on analysis of mirror traffic. Analyze the imported API mirror traffic and passively extract API information accessed by external access. 2. Detect API vulnerabilities based on analysis of mirror traffic. Analyze the imported API mirror traffic, and detect the vulnerabilities of the API itself according to the request and response data of the API, such as weak password, plaintext password, insecure configuration, unauthorized access, etc. 3. Based on the discovered vulnerabilities, construct various corresponding payload payloads in the test environment for automatic verification. Automatic verification is limited by the particularity of the production environment and is generally performed in the test environment. At this time, it is mainly to actively send requests, analyze the returned response by constructing a payload, and verify the vulnerability.

[0004] The existing API asset discovery is a passive API discovery method based on mirror traffic, which has great lag and deficiency in discovering risks. This method can only passively discover the API from the mirror traffic when the API has actually been accessed, and then different processing measures such as protection, repair or offline can be taken according to the actual situation. But the API has been successfully exploited when the access occurs. There is a great security risk for hidden risk APIs such as zombie APIs and debugging APIs. If the API is discovered and processed after being externally accessed and exploited, the loss has already been caused. SUMMARY

[0005] The embodiments of the present application provide a risk API discovery method, a risk API discovery device and a storage medium, which can actively determine whether a risk API is exposed to a network and can process the risk API before the risk API is externally accessed and exploited.

[0006] The embodiment of the application provides a risk API discovery method, comprising:

[0007] Passively detecting API access traffic to obtain a first API path in the API access traffic;

[0008] Reconstructing the first API path based on a risk API rule to obtain a second API path after reconstruction, wherein the second API path is a risk API that should not be exposed to an external network;

[0009] Accessing the second API path to determine whether the second API path is exposed to a network, and performing security disposal on the second API path according to a determination result.

[0010] Further, the passive detection of the API access traffic to obtain the first API path in the API access traffic comprises:

[0011] Analyzing API mirror traffic corresponding to the API access traffic;

[0012] Passively extracting the first API path in the API mirror traffic.

[0013] Further, the reconstruction of the first API path based on the risk API rule to obtain the second API path after reconstruction comprises:

[0014] Obtaining first API feature information corresponding to different risk API categories respectively;

[0015] Reconstructing the first API path using first API feature information corresponding to a preset risk API category to obtain a second API path after reconstruction, wherein the second API path after reconstruction belongs to the preset risk API category.

[0016] Further, the risk API category comprises a zombie API, a debugging API, a multi-version API, a component-related API and a management class API.

[0017] The first API feature information comprises a keyword in the API path, a construction format of the API path, an additional access path at the end of the API path and a default port in the API path.

[0018] Further, the reconstruction of the first API path based on the risk API rule to obtain the second API path after reconstruction further comprises:

[0019] Obtaining a dynamic API rule;

[0020] reconstruct the first API path based on the risk API rule and the dynamic API rule to obtain a reconstructed second API path.

[0021] Further, the risk API rule includes first API feature information corresponding to a risk API category itself, and the dynamic API rule includes second API feature information corresponding to the risk API category obtained by analyzing a plurality of risk APIs.

[0022] The reconstructing the first API path based on the risk API rule and the dynamic API rule to obtain a reconstructed second API path includes:

[0023] reconstructing the first API path using the first API feature information and the second API feature information corresponding to a target risk API category to obtain a reconstructed second API path, wherein the reconstructed second API path belongs to the target risk API category.

[0024] Further, the accessing the second API path to determine whether the second API path is exposed to a network includes:

[0025] periodically accessing the second API path on the network and determining whether the access is successful;

[0026] If the access is successful, it is determined that the second API path has been exposed to the network.

[0027] If the access fails, it is determined that the second API path has not been exposed to the network.

[0028] Further, the security disposal of the second API path according to the determination result includes:

[0029] If the determination result is that the second API path has been exposed to the network, whether the second API path is needed is checked by a preset checking rule, and the second API path is disposed according to the checking result.

[0030] Embodiments of the present application also provide a risk API discovery device, comprising:

[0031] an acquisition unit configured to passively detect API access traffic to obtain a first API path in the API access traffic;

[0032] a reconstruction unit configured to reconstruct the first API path based on a risk API rule to obtain a reconstructed second API path, wherein the second API path is a risk API that should not be exposed to an external network.

[0033] An access unit is configured to access the second API path to determine whether the second API path is exposed to a network, and perform security processing on the risk API according to the determination result.

[0034] The embodiment of the present application further provides a risk API discovery device, which comprises:

[0035] A central processing unit, a memory, an input and output interface, a wired or wireless network interface, and a power supply;

[0036] The memory is a transitory storage memory or a persistent storage memory;

[0037] The central processing unit is configured to communicate with the memory, execute the instruction operation in the memory on a control plane function entity to perform the risk API discovery method.

[0038] The embodiment of the present application further provides a computer readable storage medium, which comprises instructions, and when the instructions are run on a computer, the computer is caused to perform the risk API discovery method.

[0039] From the above technical solutions, the embodiment of the present application has the following advantages:

[0040] The method of the embodiment of the present application comprises: passively detecting API access traffic to obtain a first API path in the API access traffic; reconstructing the first API path based on a risk API rule to obtain a second API path after reconstruction, wherein the second API path is a risk API that should not be exposed to an external network; accessing the second API path to determine whether the second API path is exposed to a network, and performing security processing on the second API path according to the determination result. In the embodiment of the present application, the first API path is reconstructed to obtain the second API path, and the second API path is accessed, so that it can be determined whether the risk API corresponding to the second API path is exposed to the network, and the risk API can be processed before the risk API is accessed and utilized by the outside. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments described in the present application, and other drawings can also be obtained by those skilled in the art according to these drawings.

[0042] Figure 1 A risk API discovery flowchart disclosed in the embodiment of the present application;

[0043] Figure 2A risk API discovery flowchart of one risk API rule disclosed by the embodiment of the present application;

[0044] Figure 3 A risk API discovery flowchart of one risk API rule and dynamic rule disclosed by the embodiment of the present application;

[0045] Figure 4 A risk API discovery flowchart of another risk API rule and dynamic rule disclosed by the embodiment of the present application;

[0046] Figure 5 A discovery device diagram of one risk API disclosed by the embodiment of the present application;

[0047] Figure 6 A discovery device diagram of another risk API disclosed by the embodiment of the present application. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical scheme and advantages of the present application more clear, the present application will be further described in detail below with reference to the drawings, and the described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by those skilled in the art without making creative efforts belong to the scope of protection of the present application.

[0049] In the following description, the description of "one specific embodiment" or "one embodiment" and the like refers to a subset of all possible embodiments, but it can be understood that "one specific embodiment" or "one embodiment" can be the same subset or different subset of all possible embodiments, and can be combined with each other without conflict. In the following description, the term "plurality" refers to at least two.

[0050] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0051] The existing API asset discovery is a method of passively discovering API based on mirror traffic. There is a great lag and deficiency in the risk discovery. This method can only passively discover the API from the mirror traffic when the API has actually accessed. Then, different processing measures such as protection, repair or offline of the API can be taken according to the actual situation. But the API has been successfully used when the access occurs. There is a great security risk for hidden risk API such as zombie API and debugging API. If the discovery and processing are waited until the API is accessed and used by the outside, the loss has been caused. Therefore, the embodiment of the present application provides a risk API discovery method, which can actively determine whether the risk API is exposed to the network and can process the risk API before the risk API is accessed and used by the outside, such as Figure 1 As shown in the specific steps are as follows:

[0052] 101. Passively detecting API access traffic to obtain a first API path in the API access traffic.

[0053] In the embodiment of the present application, the risk API discovery device can passively detect API access traffic to obtain a first API path in the API access traffic. Specifically, the detection behavior in the API access traffic is generally passive. When the API has actually accessed, the API information is passively extracted by analyzing the API access traffic, and the first API path is contained in the API information. It can be understood that the API access traffic is generally the access traffic of the user sending an access request to the API and the API responding to the access request and returning to the user. In the embodiment of the present application, the API path can be understood as the access address of the API, which is generally composed of symbols, numbers and letters, such as the Baidu address www.baidu.com.

[0054] 102. Reconstructing the first API path based on a risk API rule to obtain a second API path after reconstruction.

[0055] After obtaining the first API path in the API access traffic, the first API path is reconstructed based on a risk API rule to obtain a reconstructed second API path, where the second API path is a risk API that should not be exposed to the external network. It can be understood that the external network refers to a network that can be accessed only through a regular network connection, such as a Baidu network, a Sogou network, and the like, which are not limited herein. The risk API generally refers to an API that contains confidential information or a confidential function. If the risk API is exposed to the external network, the risk API is likely to be accessed and utilized, resulting in leakage of the confidential information or the confidential function of the risk API. The risk API rule refers to characteristic information (features) possessed by the risk API, which can be a keyword or a construction format corresponding to the risk API, and the like, which are not limited herein. The reconstruction of the first API path based on the risk API rule can be understood as reconstructing the first API path using the characteristic information possessed by the risk API, such as adding a keyword corresponding to the risk API to the first API path, or modifying the construction format of the first API path to a construction format corresponding to the risk API, which are not limited herein. At this time, the reconstructed second API path is a risk API with corresponding characteristic information. That is, the first API path is reconstructed based on the risk API rule to obtain possible risk APIs, which are the second API path. It can be understood that the first API path can be a risk API or a non-risk API, which are not limited herein.

[0056] 103. Accessing the second API path to determine whether the second API path is exposed to the network.

[0057] After obtaining the reconstructed second API path, the second API path can be accessed to determine whether the second API path is exposed to the network. That is, the possible risk API is accessed to determine whether the risk API is exposed to the network. Specifically, the access website corresponding to the second API path can be accessed in a browser. If the access is successful, it is determined that the second API path is exposed to the network. In the embodiments of the present application, the second API path, which is a possible risk API that should not be exposed to the external network, i.e., a hidden risk API, can be actively accessed to determine whether the hidden risk API is exposed to the network.

[0058] 104. Performing security disposal on the second API path according to the determination result.

[0059] After determining whether the second API path is exposed to the network, the second API path is disposed of according to the determination result. Generally, if the determination result is that the second API path is exposed to the network, that is, the hidden risk API is not exposed to the network, the second API path can not be processed. If the determination result is that the second API path is exposed to the network, the second API path can be protected or directly offline, which is not limited here.

[0060] It can be seen that the method of the embodiment of the application comprises: passively detecting API access traffic to obtain a first API path in the API access traffic; reconstructing the first API path based on a risk API rule to obtain a second API path after reconstruction, wherein the second API path is a risk API that should not be exposed to the external network; accessing the second API path to determine whether the second API path is exposed to the network, and disposing of the second API path according to the determination result. In the embodiment of the application, the first API path is reconstructed to obtain the second API path, and the second API path is accessed to determine whether the risk API corresponding to the second API path is exposed to the network, so that the risk API can be processed before it is externally accessed and utilized.

[0061] The process of discovering the risk API based on the risk rule will be described in detail below, as shown in FIG. 1, the specific steps are as follows: Figure 2

[0062] 201. Analyze API mirror traffic corresponding to API access traffic to obtain a first API path.

[0063] In the embodiment of the application, the API mirror traffic corresponding to the API access traffic can be analyzed to obtain the first API path. Specifically, the API mirror traffic corresponding to the API access traffic is analyzed, and the first API path in the API mirror traffic is passively extracted. It can be understood that for the API that has already occurred external access behavior, the mirror traffic corresponding to the access request initiated by the user to the API and the response request initiated by the API to the user can be obtained, the mirror traffic is analyzed, and the first API path in the API access traffic is passively extracted.

[0064] 202. Reconstruct the first API path according to the first API feature information corresponding to the preset risk API category to obtain a second API path after reconstruction.

[0065] ​After obtaining the first API path, the first API path can be reconstructed according to the first API feature information corresponding to the preset risk API category, to obtain a reconstructed second API path. Specifically, the first API feature information corresponding to different risk API categories can be obtained; each risk API category has its corresponding feature information (characteristics), and the first API path is reconstructed using the first API feature information corresponding to the preset risk API category, to obtain a reconstructed second API path, wherein the reconstructed second API path belongs to the preset risk API category. For risk APIs, they can be classified according to the feature information corresponding to the risk APIs into multiple risk API categories. The risk API categories include zombie APIs, debugging APIs, multi-version APIs, component-related APIs, and management-class APIs; different risk API categories have corresponding first API feature information.

[0066] Among them, the zombie API refers to an API that has been abandoned but not offline, and can still be normally accessed but forgotten, such as an API of https, which may have an offline http version. The debugging API refers to an API used for debugging purposes, which is generally used to view various running details and state information of services in real time; the debugging API is often used in development and test environments, and once it is mistakenly published to the production environment, it will allow public access and leak a large amount of sensitive information; for example, the debugging interface / debug / pprof / interface series of Go language (Golang) and the API interface of the open source project swagger. The multi-version API refers to an API after version upgrade, with the old version still online; for example, some v3 interfaces may have old version interfaces such as v2 and v1 that have not been processed offline and still provide services to the outside. The component-related API refers to various service component-related APIs; components can be divided into middleware (such as Tomcat, Apache, etc.), various databases (Oracle, Couchdb, Elasticsearch, etc.), development frameworks (such as Spring), etc.; these components often contain online monitoring and management classes and some functions that return default information, and cannot be directly published to the external network; if the related management API is exposed to the external network, it may lead to serious consequences; different components have default ports and specific API paths. The management-class API refers to various development-related management platform-class APIs; for example, the / manage and / script interfaces of the management platform Jenkins, etc., these management platforms all have their own default ports and specific API paths for access.

[0067] The first API feature information corresponding to the risk API includes: a keyword in the API path, a construction format of the API path, an additional access path at the end of the API path, and a default port in the API path. The first API path is reconstructed using the first API feature information corresponding to the preset risk API category. The reconstruction method can be keyword replacement, construction mode, specific path splicing, and API port path reconstruction. The keyword replacement is to replace a certain keyword in the first API path with a keyword corresponding to the preset risk API category. The keyword corresponding to the preset risk API category can be a protocol type, such as replacing the protocol type of the first API path to generate a new API path. When the preset risk API category is a debugging API, the corresponding keyword can be debug, and the URL (Uniform Resource Locator) in the first API path can be replaced with debug. The construction mode is that the construction formats corresponding to each risk API are different, such as the positions of the main domain name, the subdomain name, com, and the version number can also be different. The version and other fields are identified, and the construction format of the first API path is converted into the construction format corresponding to the risk API, such as the construction format corresponding to the component-related API. The specific path splicing is to append a specific access path to the first API path, that is, to append the additional access path at the end of the API path corresponding to the risk API. For example, when the first API path is reconstructed into a debugging API, debug can be added at the end of the first API path, and when it is reconstructed into a management API, Jenkins can be added at the end. The API path reconstruction is to intercept the URL of the first API path, and then reconstruct the second API path according to the port and the default path corresponding to the risk API.

[0068] It can be understood that the first API path is reconstructed into the second API path using the feature information corresponding to the risk API, in order to construct the risk API to be discovered. The more the second API paths reconstructed, the more the risk APIs discovered.

[0069] 203. Periodically access the second API path on the network, and determine whether the second API path is exposed to the network according to the access result.

[0070] After the reconstructed second API path is obtained, the second API path can be periodically accessed on the network to determine whether the second API path is exposed to the network according to the access result. The second API path is accessed one by one on the network periodically, and it is determined whether the access is successful; if the access is successful, it is determined that the second API path is exposed to the network; if the access fails, it is determined that the second API path is not exposed to the network. Wherein, there are various cases when accessing the second API path:

[0071] First, when accessing the second API path, it is checked whether the second API path is exposed to the network, which is mainly realized by analyzing the response of the API. Specifically, the access address corresponding to the second API path can be searched on the network, and if the corresponding access result is returned, it is determined that the second API path is exposed to the network.

[0072] Second, the second API path is periodically discovered. For the case that there are many business systems and the API management is complex, the periodic scanning method can be used for active discovery to keep up with the deployment changes of the API in time and avoid omission.

[0073] Third, the second API path is a hidden risk API that has been protected. For the API that is not allowed to be accessed, protective measures are taken to directly and uniformly process it. The processing here is generally divided into two cases. The first case is uniform rejection. In this case, although the hidden risk API is actually online, it is considered that the risk API is not exposed to the network because of the protection measures. At this time, the second API path can be periodically accessed, and the active discovery is periodically performed to confirm that it is still not exposed to the network, that is, the hidden risk API has not been found by the protection measures, and the risk API does not exist in the network. Once the hidden risk API has no protection measures, it can be determined to be found again and alarmed. The second case is to return a fixed page uniformly. In this case, the scheme considers that the risk API exists in the network, that is, it has been exposed to the network. At this time, the context of the risk API can be confirmed and marked as no risk by manual confirmation. Similarly, the active discovery needs to be performed periodically, and once the protection measures disappear and the context changes, it can be identified and alarmed.

[0074] Further, for suspected abandoned API. For the first API path obtained by passive analysis of traffic, the access situation can be statistically monitored for a long period. If some first API path has normal access behavior before, but there is no access traffic for a long time later, the first API path can be actively discovered. Once it is confirmed to be online, it should be alarmed whether the first API path has been abandoned. If it is a zombie API, it should be confirmed whether it needs to be offline. As for repeated API. The API developed repeatedly has similar request, response and other information, but it provides services online at the same time. After identification, the repeated API can be offline to simplify the number of API interfaces. For this kind of API, the API can be statistically compared and identified by analyzing the context of the API, the k-v information of the request and response.

[0075] 204、If the second API path has been exposed to the network, dispose the second API path according to the checking result.

[0076] If the determination result is that the second API path has been exposed to the network, check whether the second API path is needed through a preset checking rule, and dispose the second API path according to the checking result. Based on the current API, possible hidden risk API is constructed, and risk API active discovery operation is performed piece by piece. In this process, once the existence of risk API is found, it can be marked as a risk API actively discovered. These risk APIs are manually checked and confirmed. If not needed, the risk API can be offline or other emergency protection and rectification measures can be taken according to actual needs. If needed, the risk API can be marked as a normal API, and API monitoring and other operations can be normally performed.

[0077] It can be seen that in the embodiment of the application, the hidden risk API (second API path) can be actively discovered, the existence of the hidden risk API can be discovered early, whether the hidden risk API should exist can be analyzed and confirmed, and measures can be taken for protection or direct offline, which can effectively avoid the hidden risk API from being utilized. In the case that API security problem is more and more important, the discovery problem of various hidden risk APIs without access behavior is solved.

[0078] It can be understood that, in order to make the number of second API paths obtained by reconstruction more and more comprehensive, and improve the coverage and accuracy of the discovered risk API, risk API rules and dynamic API rules can be used for risk API discovery, as shown in Figure 3 The specific steps are as follows:

[0079] 301、analyze the API mirror traffic corresponding to the API access traffic to obtain a first API path.

[0080] It can be understood that step 301 is similar to step 201 described above, and details are not repeated here.

[0081] 302, reconstruct the first API path according to the first API feature information and the second API feature information corresponding to the target risk API category, to obtain the reconstructed second API path.

[0082] In the embodiments of the present application, dynamic API rules can be obtained; the first API path is reconstructed based on the risk API rules and the dynamic API rules to obtain the reconstructed second API path. Among them, the risk API rules include: the first API feature information corresponding to the risk API category itself; the dynamic API rules include: the second API feature information corresponding to the risk API category obtained by analyzing a plurality of risk APIs, and the second API feature information is different from the first API feature information. It can be understood that, as shown in Figure 4 As shown, API information is extracted according to API mirror traffic corresponding to API access traffic, and the API set corresponding to the first API path is obtained by passive discovery. The multi-dimensional feature information of the API in the API set can be analyzed, and the basic feature in the first API path is matched, the corresponding risk API category is determined for the first API path matched successfully and the corresponding risk API label is assigned, wherein the basic feature can be understood as the first API feature information in the risk API rules, that is, the feature information of the risk API itself. It can be understood that the risk API label refers to the risk API category (such as debugging API, component related API, etc.), and a first API path can have multiple risk API labels. When the API mirror traffic is passively analyzed to obtain a large amount of API information, these existing APIs can be analyzed according to these multi-aspect features, so as to obtain various risk API label information. When the first API path is assigned with the risk API label, it can be confirmed by manual confirmation whether the risk API label is correct, that is, whether the first API path belongs to the risk API category corresponding to the risk API label assigned. When it is confirmed to belong, a comprehensive analysis is triggered to analyze the multi-aspect features of the first risk API, and the multi-aspect features can be keywords, paths, ports or contexts, etc. The multi-aspect features are corresponding to the corresponding risk API category, that is, the dynamic API rule library is obtained, and the multi-aspect features are the second API feature information in the dynamic API rules.

[0083] It can be understood that the feature information in the risk API is not fixed, and the use of dynamic API rules can obtain more accurate second API paths. For example, for a debugging API, based on the first feature information of the hidden risk API, the defined basic feature in terms of keywords is to contain the path end containing the debug keyword. Using this basic feature to match the API set currently passively analyzed from the traffic mirror, all first API paths containing the debug keyword can be labeled with the debugging API. Once confirmed manually, a comprehensive analysis of the first API path from the construction mode, keywords, paths, ports or context can be triggered, and based on the obtained second feature information (such as finding that the keywords of the debugging API also include heap or trace), the dynamic API rule library for actively discovering the constructed hidden risk API can be greatly enriched, forming a positive feedback process.

[0084] The first API path is reconstructed using the first API feature information and the second API feature information corresponding to the target risk API category, and a reconstructed second API path is obtained, wherein the reconstructed second API path belongs to the target risk API category. That is, the first API path is reconstructed in combination with the feature information in the risk API rule and the dynamic API rule, various second API paths are constructed, and active discovery is performed; for the dynamic rule that discovers the hidden risk API, the effectiveness thereof should be counted, and for the rule with higher effectiveness, the corresponding second API feature information can be merged into the risk API rule.

[0085] 303、Network access to the second API path one by one, and determine whether the second API path is exposed to the network according to the access result.

[0086] 304、If the second API path has been exposed to the network, dispose of the second API path according to the checking result.

[0087] It can be understood that steps 303 and 304 are similar to steps 203 and 204 described above, and will not be described here.

[0088] It can be seen that, in the embodiment of the application, the dynamic API rule is used to determine the hidden risk API type of the passive discovery API, and then the passive discovery API is comprehensively analyzed to obtain the multi-aspect features corresponding to the hidden risk API type; after determining the hidden risk API category that needs to be reconstructed for the first API path, the corresponding multi-aspect features of the corresponding hidden risk API category and the corresponding first API feature information in the risk API rule are used to reconstruct the first API path. Compared with the risk API rule, the dynamic API rule is more abundant, and in terms of accuracy, it is more suitable for the actual characteristics of the current business environment (such as various habitual characteristics of system developers in developing, designing and configuring APIs). The emergence principle of various hidden risk APIs is analyzed, based on the risk API rule, combined with the dynamic risk API discovery rule (multi-aspect features obtained by analyzing existing APIs) in the current environment, various potential risk APIs are constructed and actively discovered, which helps security personnel to confirm these hidden API assets and take offline or emergency protection measures, so as to prevent risks in advance.

[0089] The embodiment of the application further provides a risk API discovery device, as shown in the accompanying drawings, which comprises: Figure 5

[0090] The acquisition unit 501 is configured to passively detect API access traffic to obtain a first API path in the API access traffic.

[0091] The reconstruction unit 502 is configured to reconstruct the first API path based on a risk API rule to obtain a second API path after reconstruction, wherein the second API path is a risk API that should not be exposed to the external network.

[0092] The access unit 503 is configured to access the second API path to determine whether the second API path is exposed to the network, and to perform security disposal on the risk API according to the determination result.

[0093] The embodiment of the application further provides a risk API discovery device, please refer to Figure 6 The risk API discovery device 600 of the embodiment of the application can comprise one or more central processing units (CPUs) 601 and a memory 602, and the memory 602 stores one or more application programs or data.

[0094] ​The memory 602 can be volatile memory or persistent storage. The programs stored in the memory 602 can include one or more modules, each of which can include a series of instruction operations in the electronic device. Further, the central processor 601 can be configured to communicate with the memory 602 to execute the series of instruction operations in the memory 602 on the post-quantum cryptography attack protection device 600.

[0095] The post-quantum cryptography attack protection device 600 can also include one or more power supplies 605, one or more wired or wireless network interfaces 604, one or more input / output interfaces 603, and / or one or more operating systems, such as Windows ServerTM, Mac OSXTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0096] The central processor 601 can perform the operations performed by the first aspect or any of the specific method embodiments of the first aspect described above, and the specific details are not repeated.

[0097] The present application provides a computer readable storage medium, including instructions, when the instructions run on a computer, the computer executes the method described in the first aspect or any of the specific implementation manners of the first aspect.

[0098] The present application provides a computer program product including instructions or a computer program, when the computer program product runs on a computer, the computer executes the method described in the first aspect or any of the specific implementation manners of the first aspect.

[0099] It can be understood that in various embodiments of the present application, the sequence number of each step does not mean the order of execution, the execution order of each step should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0100] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working process of the system and device described above can refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.

[0101] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented by other manners. For example, the apparatus embodiments described above are merely illustrative, for example, the division of the units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system or apparatus, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, apparatuses or units, and can be electrical, mechanical or other forms.

[0102] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place or distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0103] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0104] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part of the prior art that contributes or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product (computer program product) stored in a storage medium includes a plurality of instructions for causing a computer device (which can be a personal computer, a business server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

Claims

1. A risk API discovery method, characterized in that, The method comprises the following steps: Passively detecting API access traffic to obtain a first API path in the API access traffic; Reconstructing the first API path based on a risk API rule to obtain a second API path after reconstruction, wherein the second API path is a risk API that should not be exposed to the external network; Accessing the second API path to determine whether the second API path is exposed to the network, and performing security processing on the second API path according to the determination result; The method further comprises the following steps: Obtaining a dynamic API rule; Reconstructing the first API path based on the risk API rule and the dynamic API rule to obtain the second API path after reconstruction, wherein the dynamic API rule comprises second API feature information corresponding to a risk API category obtained by analyzing a recognized risk API in historical API access traffic; According to the determination result, the effectiveness of the dynamic API rule corresponding to the risk API that has been found to be exposed to the external network is counted, and second API feature information with effectiveness meeting a preset condition is merged into the risk API rule.

2. The risk API discovery method of claim 1, wherein, The method further comprises the following steps: Analyzing API mirror traffic corresponding to the API access traffic; Passively extracting the first API path in the API mirror traffic.

3. The risk API discovery method of claim 1, wherein, The method further comprises the following steps: Obtaining first API feature information corresponding to different risk API categories respectively; Reconstructing the first API path using first API feature information corresponding to a preset risk API category to obtain the second API path after reconstruction, wherein the second API path after reconstruction belongs to the preset risk API category.

4. The risk API discovery method of claim 3, wherein, The risk API categories comprise a zombie API, a debugging API, a multi-version API, a component-related API, and a management class API; The first API feature information comprises a keyword in the API path, a construction format of the API path, an additional access path at the end of the API path, and a default port in the API path.

5. The risk API discovery method of claim 1, wherein, The risk API rule comprises first API feature information corresponding to a risk API category itself; The method further comprises the following steps: Analyzing a plurality of risk APIs to obtain second API feature information corresponding to a risk API category, and taking the second API feature information as the dynamic API rule; The method further comprises the following steps: The first API path is reconstructed using the first API feature information and the second API feature information corresponding to the target risk API category, to obtain a reconstructed second API path, wherein the reconstructed second API path belongs to the target risk API category.

6. The risk API discovery method of claim 1, wherein, The accessing of the second API path to determine whether the second API path is exposed to the network comprises: periodically accessing the second API path on the network and determining whether the access is successful; if the access is successful, it is determined that the second API path is exposed to the network; if the access fails, it is determined that the second API path is not exposed to the network.

7. The risk API discovery method of claim 1, wherein, The security processing of the second API path according to the determination result comprises: if the determination result is that the second API path is exposed to the network, it is checked by a preset checking rule whether the second API path is retained on the network, and the second API path is processed according to the checking result.

8. A risk API discovery apparatus, characterized by, comprise: an acquisition unit configured to passively detect API access traffic to acquire a first API path in the API access traffic; a reconstruction unit configured to reconstruct the first API path based on a risk API rule to obtain a reconstructed second API path, wherein the second API path is a risk API that should not be exposed to the external network; an access unit configured to access the second API path to determine whether the second API path is exposed to the network, and to perform security processing on the risk API according to a determination result; the reconstruction unit is further configured to acquire a dynamic API rule, and to reconstruct the first API path based on the risk API rule and the dynamic API rule to obtain the reconstructed second API path; wherein the dynamic API rule comprises second API feature information corresponding to a risk API category obtained by analyzing a recognized risk API in historical API access traffic; a merging unit configured to count the effectiveness of a dynamic API rule corresponding to a risk API exposed to the external network according to the determination result, and to merge second API feature information with effectiveness satisfying a preset condition into the risk API rule.

9. A risk API discovery apparatus, characterized by, comprise: a central processing unit, a memory, an input / output interface, a wired or wireless network interface, and a power supply; the memory is a transitory storage memory or a persistent storage memory; the central processing unit is configured to communicate with the memory, execute instruction operations in the memory on a control plane function entity, and perform the risk API discovery method of any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium comprises instructions which, when executed on a computer, cause the computer to perform the risk API discovery method of claims 1 to 8.

11. A computer program product comprising instructions or a computer program, characterized in that, When the computer program product is executed on a computer, the computer is caused to perform the risk API discovery method of claims 1 to 8.

Images