CN113360916A

CN113360916A - Risk detection method, device, equipment and medium for application programming interface

Info

Publication number: CN113360916A
Application number: CN202110682804.4A
Authority: CN
Inventors: 陈天; 段继平
Original assignee: Qax Technology Group Inc; Secworld Information Technology Beijing Co Ltd
Current assignee: Qax Technology Group Inc; Secworld Information Technology Beijing Co Ltd
Priority date: 2021-06-18
Filing date: 2021-06-18
Publication date: 2021-09-07

Abstract

The application belongs to the technical field of network security and discloses a risk detection method, a device, equipment and a medium for an application programming interface, wherein the method comprises the steps of determining the risk category to be detected; screening a field value of a target field corresponding to a risk category from an interface call log of an application programming interface in a preset time range; and if the abnormal field value exists in the field values, determining that the application programming interface is at risk. Therefore, the logs are called through the interface of the API, risk detection of different risk categories can be carried out, the complex operation of the risk detection is simplified, and the cost of manpower and material resources consumed by the risk detection is reduced.

Description

Risk detection method, device, equipment and medium for application programming interface

Technical Field

The present application relates to the field of network security technologies, and in particular, to a method, an apparatus, a device, and a medium for risk detection of an application programming interface.

Background

With the development of the internet of things technology, the application range of the application program is more and more extensive, for example, the application program is widely applied to the fields of banks, retail, transportation, automatic driving automobiles, smart cities and the like.

Among them, an Application Programming Interface (API) is a key component in an Application program. The application program can share data with the platform and use functions provided by the platform by calling the API provided by the platform.

In the prior art, the security problem of the API is usually avoided through the API gateway, however, the API gateway needs to be deployed in the system, and different security mechanisms need to be designed for different API security problems, so that the operation steps are complicated, and a large amount of labor and material costs are consumed.

Therefore, when risk detection is performed on the API, how to simplify the tedious steps of the API risk detection and reduce the consumed labor and material cost is a technical problem to be solved.

Disclosure of Invention

The embodiment of the application aims to provide a risk detection method, a risk detection device, risk detection equipment and a risk detection medium for an application programming interface, so that the complex steps of API risk detection are simplified and the consumed human and material cost is reduced when risk detection is carried out on an API.

In one aspect, a risk detection method for an application programming interface is provided, including:

determining a risk category to be detected;

screening a field value of a target field corresponding to a risk category from an interface call log of an application programming interface in a preset time range;

and if the abnormal field value exists in the field values, determining that the application programming interface is at risk.

In the implementation process, the risk detection is carried out only by calling the log through the interface of the API, so that the complex operation of the risk detection is simplified, and the cost of manpower and material resources consumed by the risk detection is reduced.

Preferably, the risk categories include any one or any combination of the following:

identity authentication risk, resource restriction risk, resource authorization risk and function authorization risk;

the target field corresponding to the identity authentication risk at least comprises: the number of identity authentication failures;

the target field corresponding to the resource restriction risk at least comprises at least one of the following fields: resource request rate and resource request times;

the target field corresponding to the resource authorization risk at least comprises: the number of times of resource access;

the target field corresponding to the function authorization risk at least comprises: the number of function calls.

In the implementation process, different risk categories and target fields required for risk detection are set according to the actual application scene.

Preferably, the field value is multiple, and if there is an abnormal field value in the field values, it is determined that the application programming interface is at risk, including:

determining an average value and a standard deviation of a plurality of field values of a target field;

judging whether an abnormal field value exists according to each field value, the average value and the standard deviation of the target field;

if yes, determining that an abnormal field value exists and determining that an application programming interface has risks;

otherwise, judging whether an abnormal field value exists in the field values of the target fields in a box diagram mode, and determining that the application programming interface has risks under the condition that the abnormal field value exists.

In the implementation process, a field deviation risk detection mode is combined with a box diagram mode, so that the risk detection accuracy is improved, and the problem of risk omission is solved.

Preferably, the determining whether there is an abnormal field value according to each field value, the average value and the standard deviation of the target field includes:

screening out field values meeting preset screening conditions from a plurality of field values of a target field;

respectively determining the absolute value of the difference value between each screened field value and the average value;

determining corresponding field deviation according to each absolute value and the standard deviation;

and if the field deviation in the preset abnormal deviation range exists in the field deviations, determining that an abnormal field value exists, otherwise, determining that the abnormal field value does not exist.

In the implementation process, according to the field deviation, abnormal field values in the field values can be screened out.

Preferably, the step of screening out a field value meeting a preset screening condition from a plurality of field values of the target field includes:

screening a specified number of field values from a plurality of field values of a target field, wherein the minimum value of the screened field values is not less than the maximum value of the non-screened field values;

alternatively, a specified number of field values are sorted from a plurality of field values, wherein a maximum value of the sorted field values is not greater than a minimum value of the non-sorted field values.

In the implementation process, the field values are screened, so that the data processing amount can be reduced, and the data processing speed is increased.

Preferably, the interface call log comprises: the application programming interface access log and the application programming interface authentication log; the method further comprises the following steps:

and associating the application programming interface access log with the object calling the application programming interface access log based on the information in the application programming interface authentication log.

Preferably, the identity authentication risk refers to a risk of abnormal authentication existing during user identity authentication;

the resource limitation risk refers to the risk of overload calling when the resource is called;

the resource authorization risk refers to the risk that unauthorized calling exists when the resource is called;

function authorization risk refers to the risk of unauthorized invocation of a function when it is invoked.

In the implementation process, different safety problems can be detected through different types of risks.

In one aspect, an apparatus for risk detection of an api is provided, including:

the first determining unit is used for determining the risk category to be detected;

the screening unit is used for screening the field value of the target field corresponding to the risk category from the interface call log of the application programming interface in a preset time range;

and the second determination unit is used for determining that the application programming interface is in risk if an abnormal field value exists in the field values.

Preferably, the field values are plural, and the second determining unit is configured to:

Preferably, the second determination unit is configured to: screening out field values meeting preset screening conditions from a plurality of field values of a target field;

Preferably, the second determination unit is configured to: screening a specified number of field values from a plurality of field values of a target field, wherein the minimum value of the screened field values is not less than the maximum value of the non-screened field values;

Preferably, the interface call log comprises: the application programming interface access log and the application programming interface authentication log; the second determination unit is further configured to:

In one aspect, an electronic device is provided, comprising a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, perform the steps of the method provided in any of the various alternative implementations of risk detection for an application programming interface as described above.

In one aspect, a readable storage medium is provided, on which a computer program is stored, which computer program, when being executed by a processor, is adapted to carry out the steps of the method as provided in any of the various alternative implementations of risk detection for an application programming interface as described above.

In the method, the device, the equipment and the medium for detecting the risks of the application programming interface, the types of the risks to be detected are determined; screening a field value of a target field corresponding to a risk category from an interface call log of an application programming interface in a preset time range; and if the abnormal field value exists in the field values, determining that the application programming interface is at risk. Therefore, the logs are called through the interface of the API, risk detection of different risk categories can be carried out, the complex operation of the risk detection is simplified, and the cost of manpower and material resources consumed by the risk detection is reduced.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.

Fig. 1 is a flowchart illustrating an implementation of a method for risk detection of an application programming interface according to an embodiment of the present disclosure;

fig. 2 is a flowchart illustrating an implementation of a method for detecting an identity authentication risk according to an embodiment of the present disclosure;

fig. 3 is a flowchart of an implementation of a resource constraint risk detection method according to an embodiment of the present application;

fig. 4 is a flowchart of an implementation of a method for detecting a risk of resource authorization according to an embodiment of the present application;

fig. 5 is a flowchart of an implementation of a function authorization risk detection method according to an embodiment of the present application;

fig. 6 is a flowchart illustrating an implementation of a method for risk detection and alarm according to an embodiment of the present disclosure;

fig. 7 is a block diagram illustrating a risk detection apparatus for an API according to an embodiment of the present disclosure;

fig. 8 is a schematic structural diagram of an electronic device in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.

First, some terms referred to in the embodiments of the present application will be described to facilitate understanding by those skilled in the art.

The terminal equipment: may be a mobile terminal, a fixed terminal, or a portable terminal such as a mobile handset, station, unit, device, multimedia computer, multimedia tablet, internet node, communicator, desktop computer, laptop computer, notebook computer, netbook computer, tablet computer, personal communication system device, personal navigation device, personal digital assistant, audio/video player, digital camera/camcorder, positioning device, television receiver, radio broadcast receiver, electronic book device, gaming device, or any combination thereof, including the accessories and peripherals of these devices, or any combination thereof. It is also contemplated that the terminal device can support any type of interface to the user (e.g., wearable device), and the like.

A server: the cloud server can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and can also be a cloud server for providing basic cloud computing services such as cloud service, a cloud database, cloud computing, cloud functions, cloud storage, network service, cloud communication, middleware service, domain name service, security service, big data and artificial intelligence platform and the like.

API: is a collection of definitions, procedures and protocols, the primary function being to provide a common set of functions. For example, an application may implement a function by calling an API provided by the platform, causing the platform to execute the command (action) of the application, without the need to develop the application to implement the function.

In order to simplify the tedious steps of API risk detection and reduce the cost of consumed manpower and material resources when risk detection is performed on an API, embodiments of the present application provide a risk detection method, apparatus, device and medium for an application programming interface.

In this embodiment of the application, the execution main body may be an electronic device, and optionally, the electronic device may be a server or a terminal device, which is not limited herein. In one embodiment, the electronic device is a server with an operating environment based on an X86 architecture, and the software system version of the server is Centos 7.41708, python 3.6.

Referring to fig. 1, an implementation flow chart of a risk detection method for an application programming interface according to an embodiment of the present application is shown, and the specific implementation flow of the method is as follows:

step 100: and determining the risk category to be detected.

Specifically, the risk category to be detected may be set by default, or may be determined according to an instruction of the user.

In one embodiment, the risk category to be detected selected by the user from the risk categories is obtained.

Wherein, the risk category may include any one or any combination of the following: identity Authentication (Broken Authorization) risk, resource restriction risk, resource Authorization risk (BOLA), and Function Authorization risk (BFLA).

The identity authentication risk refers to a risk that abnormal authentication may exist when a user performs identity authentication.

For example, when a user performs authentication through the authentication API to log on a platform, since an attacker may attempt to log on through a guessed user password, there may be an authentication risk if the authentication API is called by the same user multiple times in a short time.

Resource restriction risk refers to the risk that an overload call may exist when a resource is called.

For example, when a resource request is made through the API, an attacker may occupy too many Service resources of the platform through a large number of API requests, so that a legitimate user cannot obtain a response of the Service, that is, perform a Denial of Service (Dos) attack on the platform.

Resource authorization risk refers to the risk that an unauthorized invocation may exist when a resource is invoked.

For example, when accessing a resource through an API, since an attacker may use an unauthorized resource name to illegally invoke an unauthorized resource, if the number of resource accesses for a user to invoke the API to access a specified resource is much lower than the number of corresponding resource accesses of other users, there may be a risk of resource authorization.

Function authorization risk refers to the risk that an unauthorized call may exist when a function is called.

For example, since APIs of some management functions are in a public state or API parameters of API function calls may be predicted, an ordinary user may illegally call a designated function that an administrator has permission to call through the predicted API parameters under an unauthorized condition, and therefore, if the number of times that a certain user calls the designated function through the API is much lower than the number of times that other users call the corresponding function, there may be a risk of function authorization.

In practical applications, the risk category may also be set according to practical application scenarios, and is not limited herein.

Therefore, different risk categories can be set according to different API risk problems, and different target fields can be set according to different risk categories in subsequent steps so as to carry out corresponding risk detection.

Step 101: and screening the field value of the target field corresponding to the risk category from the interface call log of the application programming interface in a preset time range.

Specifically, the field value of the target field corresponding to the risk category to be detected is screened out from an interface call log of an API called by a user within a preset time range.

In one embodiment, when screening out the field value of the target field corresponding to the risk category, the following steps may be adopted:

s1011: and acquiring an interface call log of calling the API within a preset time range by a user from the log storage device.

Optionally, the log storage device may be a search server (ES), or may be other devices, the interface call log may be obtained periodically, or may be obtained in real time, or may be obtained when a log obtaining instruction is received, the number of the users may be one or more, or the application programming interface may be one or more, which is not limited herein.

In practical applications, the preset time range may be set according to practical application scenarios, for example, the preset time range may be 1 day, 1 week, 1 month, and the like, which is not limited herein.

Therefore, the interface call logs for risk detection can be selected according to the preset time range.

S1012: and acquiring a target field set for the risk category to be detected.

Specifically, the target field corresponding to the identity authentication risk at least includes: the number of failed authentication times.

The target field corresponding to the resource restriction risk at least comprises at least one of the following fields: resource request rate and resource request times.

The target field corresponding to the resource authorization risk at least comprises: the number of resource accesses.

In the embodiment of the present application, the target field corresponding to the risk category is taken as an example for explanation, in practical applications, the target field corresponding to the risk category may also be another field, and the number of the target fields set corresponding to each risk category may be one or multiple, which is not limited herein.

Wherein, the interface call log comprises: an application programming interface access log (i.e., API access log) and an application programming interface authentication log (i.e., API authentication log). The API access log comprises a field value of a target field in the API calling process, and the API authentication log comprises an object calling the API in the API calling process.

In one embodiment, before step 101 is executed, the API access log may be further associated with an object calling the API access log based on information in the API authentication log, that is, an association relationship between a calling object of the API and a field value of a target field in the API calling process is established, so that a risk of a specific object calling the API can be conveniently detected.

In this way, the target field for risk detection can be obtained.

S1013: and extracting the field value of the target field from each interface call log.

Specifically, the target field may be understood as a parameter variable set for the risk, and the field value may be understood as an actual value of the acquired target field, that is, a variable value of the parameter variable. For example, the parameter variable is x and the parameter value is 9.

In the embodiment of the present application, only the number of field values is taken as an example for description, and in practical application, the number of field values may be one.

Further, the field values of the extracted target fields and the corresponding object associations may also be stored in a database.

Optionally, the database may be a reference database, or may also be a database built by the user, and different databases may be used for different data types.

Therefore, after the risk category to be detected is determined, data used for judging whether the API has the risk category to be detected or not can be screened from the interface call log, and the screened data are stored in the database.

Step 102: and if the abnormal field value exists in the field values, determining that the application programming interface is at risk.

Specifically, when step 102 is executed, the following steps may be adopted:

s1021: an average and a standard deviation of a plurality of field values of the target field are determined.

Specifically, the following steps are executed for each target field respectively:

an average and a standard deviation of a plurality of field values of the target field are determined.

Further, subsequent API risk judgment may be performed only for a specified object, and then a field value of a specified user may be first screened out from a plurality of field values of a target field, and then an average value and a standard deviation of the screened out plurality of field values may be determined.

Thus, the mean and standard deviation of each field value can be determined.

S1022: and judging whether an abnormal field value exists according to each field value, the average value and the standard deviation of the target field, if so, executing S1023, otherwise, executing S1024.

Specifically, when S1022 is executed, the following steps may be adopted:

step a: and screening the field values meeting preset screening conditions from the plurality of field values of the target field.

Specifically, when step a is executed, any one of the following manners may be adopted:

mode 1: a specified number of field values are sorted out from a plurality of field values of a target field. Wherein the minimum value in the screened field values is not less than the maximum value in the non-screened field values.

For example, assuming that the designated number is 2, since it is required that the minimum value of the screened field values is not less than the maximum value of the non-screened field values, it may be determined that 2 field values are screened from the plurality of field values (5, 6, 7, 8, 9, 10) of the target field, that is, 9 and 10 are screened, and it is verified that the minimum value 9 of the screened field values is not less than the maximum value 8 of the non-screened field values.

It should be noted that, since the probability of the risk of identity authentication is greater if the number of failed identity authentication is greater, and the probability of the risk of resource restriction is greater if the resource request rate or the number of resource requests is greater, the field value may be screened in the manner 1 when detecting the risk of identity authentication and the risk of resource restriction.

Mode 2: a specified number of field values are sorted out from a plurality of field values of a target field. Wherein the maximum value of the screened field values is not greater than the minimum value of the non-screened field values.

For example, assuming that the designated number is 2, since it is required that the maximum value of the screened field values is not greater than the minimum value of the non-screened field values, it may be determined that 2 field values are screened from a plurality of field values (5, 6, 7, 8, 9, 10) of the target field, that is, 5 and 6 are screened, and it is verified that the maximum value 6 of the screened field values is not greater than the minimum value 7 of the non-screened field values.

Optionally, the designated number may be one or more, may be fixedly set, or may be determined according to a user instruction.

It should be noted that, in a general case, if it is determined that one abnormal field value, that is, an outlier, exists in a plurality of field values, it may be determined that a risk exists, and therefore, the designated number may be 1, so that the data processing efficiency is relatively high, and further, to improve the accuracy of risk detection, it may also be determined whether a risk exists through a plurality of or all of the field values, and therefore, the designated number may be set according to an actual application scenario, which is not limited herein.

In practical application, the preset screening condition may also be another screening condition set according to a practical application scenario, and is not limited herein.

It should be noted that, since the probability that there is a risk of resource authorization is higher if the number of times of resource access is smaller, and the probability that there is a risk of function authorization is higher if the number of times of function call is smaller, when detecting the risk of resource authorization and the risk of function authorization, the above-mentioned method 2 may be adopted to perform the field value screening.

Step b: and respectively determining the absolute value of the difference value between each screened field value and the average value.

Step c: and determining the corresponding field deviation according to each absolute value and the standard deviation.

Where the field deviation is positively correlated with absolute value and negatively correlated with standard deviation.

In one embodiment, the field deviation is the ratio of the absolute value to the standard deviation.

Step d: if the field deviation in the preset abnormal deviation range exists in the field deviations, executing S1023, otherwise, executing S1024.

In practical applications, the preset abnormal deviation range may be set according to practical application scenarios, for example, the preset abnormal deviation range is set to have a field deviation higher than 10, and is not limited herein.

S1023: determining that an exception field value exists and determining that an application programming interface is at risk.

S1024: and judging whether an abnormal field value exists in the field values of the target fields by adopting a box diagram mode, if so, executing S1025, and otherwise, executing S1026.

S1025: determining that an exception field value exists and determining that an application programming interface is at risk.

S1026: determining that no exception field values exist and determining that no risk exists for the application programming interface.

It should be noted that the method for determining whether an abnormal field value exists through field deviation is mainly used for detecting a field value conforming to normal distribution. For example, the method of detecting abnormal field values by using field deviations can be applied to the anti-fraud field, such as whether the payment amount of the user is abnormal, whether the payment frequency of the user is abnormal, whether the number of times of purchasing a specific commodity is abnormal, and the like.

Therefore, if it is determined that no abnormal field value exists, the risk may not exist, or the distribution of the field values does not conform to the normal distribution, so that the actually existing abnormal field value is not detected, and the boxplot can perform detection on normally and non-normally distributed data.

Further, in the risk detection, only one of the two methods may be used for detection, or whether the data population to be detected conforms to the normal distribution is determined in advance, and then an appropriate detection method is further selected, which is not limited herein.

Furthermore, according to the abnormal field value, the related information such as the user of the related calling API, the calling time and the like can be determined, the abnormal field value and the related information are written into a message queue, such as a Kafka message queue, and an alarm is given to the manager through the message queue.

Further, the steps 100 to 102 may be performed after the periodic sleep according to the preset trigger time, so that the periodic risk detection of the API may be implemented.

The preset trigger time may be set by default, or may be set according to a user instruction, for example, the preset trigger time is 1 day, which is not limited herein.

In the embodiment of the application, the risk of various risk types can be detected only by analyzing the interface call log of the API without installing an API gateway or adding a specific API security policy into the API, and when the risk is determined to exist, the associated API caller, the call time and other detailed associated information can be positioned, and the risk detection result containing the abnormal field value, the associated information and the risk type can be sent to the manager for risk warning, so that the manager can further perform API risk confirmation, API restoration and the like, and the API call security can be improved. Moreover, the preset trigger time can be configured according to the actual application scene, and the risk detection is periodically performed, so that the risk monitoring of the API is realized, further, the preset threshold values such as the abnormal deviation range can be adjusted according to the actual application scene, and the field deviation detection and the box diagram detection are combined, so that the accuracy of the risk detection is improved.

The following describes in further detail the method for determining an abnormal field value by using field deviation of the field value in the above embodiment by using multiple application scenarios.

Scenario 1, an identity authentication risk detection scenario. Referring to fig. 2, an implementation flow chart of an identity authentication risk detection method is shown, and the specific implementation flow of the method is as follows:

step 200: and determining the risk category to be detected as the identity authentication risk.

Step 201: and determining the target field corresponding to the identity authentication risk as the number of identity authentication failures.

Step 202: and acquiring an interface call log of the API in a preset time range.

Step 203: and screening a plurality of field values corresponding to the failure times of the identity authentication from the interface call log.

Furthermore, the field values corresponding to the number of times of identity authentication failure when the specified user calls the API to perform identity authentication can be screened out according to the incidence relation between the user and the field values corresponding to the number of times of identity authentication failure, so that whether the specified user has an identity authentication risk when the specified user calls the API to perform identity authentication is detected in the subsequent steps.

In one embodiment, before step 203 is executed, the API access log includes a field value of the number of authentication failures in the API calling process, the API authentication log includes a user calling the API in the API calling process, and an association between the user calling the API and the field value of the corresponding number of authentication failures is established.

Step 204: and determining the average value and the standard deviation of a plurality of field values of the identity authentication failure times.

Step 205: and screening the field values meeting the preset screening condition from the field values of the identity authentication failure times.

Wherein the minimum value in the screened field values is not less than the maximum value in the non-screened field values.

In one embodiment, a maximum field value is selected from a plurality of field values of the number of failed authentication.

Step 206: and determining corresponding field deviation according to each screened field value, the average value and the standard deviation.

Step 207: and if the field deviation within the preset abnormal deviation range exists in the field deviations, determining that an abnormal field value exists, and determining that the API has an identity authentication risk.

TABLE 1

For example, see table 1, which is a statistical table of the number of authentication failures for a user. In table 1, the field values in the call log for the user to access the interface of the "/auth" API include the date, time, and the number of authentication failures. The dates (day) are day1 and day2 … …, the whole day is divided into 7 time periods with the time of 00:00-05:59 and the time of 06:00-08:00 … …, and aij is the number of identity authentication failures in the j time period on the ith day. i is the date and j is the time period. Assuming that the preset time range is 00:00-05:59 every day, screening out a11, a21 and a31 … …, determining that the maximum value a31 in the group of data is an abnormal field value, indicating that the identity authentication risk exists, and further writing the maximum value a31 into the database.

In this way, it can be determined whether there is a risk of identity authentication.

It should be noted that, when step 200 to step 207 are executed, the specific steps refer to step 100 to step 102, which are not described herein again.

Scenario 2, a resource constraint risk detection scenario. Referring to fig. 3, an implementation flow chart of a resource constraint risk detection method is shown, and the specific implementation flow of the method is as follows:

step 300: and determining the risk category to be detected as the resource limit risk.

Step 301: and determining the target field corresponding to the resource limitation risk as the resource request rate.

Step 302: and acquiring an interface call log of the API in a preset time range.

Step 303: and screening a plurality of field values corresponding to the resource request rate from the interface call log.

Furthermore, according to the association relationship between the user and the field values corresponding to the resource request rate, the field values corresponding to the resource request rate when the specified user calls the API to make a resource request can be screened out, so that in the subsequent steps, whether a resource limitation risk exists when the specified user calls the API to make a resource request or not is detected.

In one embodiment, before performing step 303, the API access log includes a field value of a resource request rate in the API calling process, the API authentication log includes a user calling the API in the API calling process, and an association between the user calling the API and the field value of the corresponding resource request rate is established.

In this way, the user who calls the API each time, and the corresponding field value for the resource request rate, can be determined.

Step 304: an average value and a standard deviation of a plurality of field values of the resource request rate are determined.

Step 305: and screening the field values meeting preset screening conditions from the field values of the resource request rate.

In one embodiment, a maximum field value is selected from a plurality of field values of the resource request rate.

Step 306: and determining corresponding field deviation according to each screened field value, the average value and the standard deviation.

Step 307: and if the field deviation in the preset abnormal deviation range exists in the field deviations, determining that an abnormal field value exists, and determining that the API has a resource limitation risk.

TABLE 2

For example, referring to table 2, an example table of rates requested for a user's resources is shown. In table 2, the field values in the interface call log for the user to access the "/mainpage" API include the date, time, and the number of authentication failures. The dates (day) are day1 and day2 … …, the whole day is divided into 7 time periods, the time is 00:00-05:59 and 06:00-08:00 … …, and bij/h is the resource request rate of the ith day in the jth time period. The resource request rate is the number of times the API requests the resource per hour, i is the date, j is the time period, and h is the hour. Assuming that the preset time range is 00:00-05:59 per day, the resource request rates screened from table 2 are b11/h, b21/h and b31/h in sequence, and the maximum value b31/h in the group of data is determined to be an abnormal field value, so that the resource restriction risk is determined to exist.

It should be noted that, when step 300 to step 307 are executed, the specific steps refer to step 100 to step 102, which are not described herein again.

Scenario 3, a resource authorization risk detection scenario. Referring to fig. 4, an implementation flow chart of a resource authorization risk detection method is shown, and the specific implementation flow of the method is as follows:

step 400: and determining the risk category to be detected as the resource authorization risk.

Step 401: and determining the target field corresponding to the resource authorization risk as the resource access times.

Step 402: and acquiring an interface call log of the API in a preset time range.

Step 403: and screening a plurality of field values corresponding to the resource access times from the interface call log.

Specifically, according to the interface call log, a user calling the API, the resource accessed through the API and the field value of the resource access times are determined, and an association relation among the user, the resource and the field value of the resource access times is established.

And if the number of the target resources is one, according to the association relationship, each user accesses a plurality of field values corresponding to the resource access times of the target resources through the API.

If the number of the target resources is multiple, the following steps may be performed for each target resource: and determining a plurality of field values corresponding to one target resource according to the association relation.

Therefore, in the subsequent steps, after the abnormal field value exists in the field value of any target resource, the abnormal user associated with the abnormal field value and any target resource can be determined according to the association relation, and therefore the resource authorization risk exists when the abnormal user accesses any target resource through the API.

It should be noted that the association relationship may be executed before executing step 403, and is not limited herein.

Step 404: an average value and a standard deviation of a plurality of field values of the resource access times are determined.

Step 405: and screening the field values meeting the preset screening condition from the field values of the resource access times.

Wherein the maximum value of the screened field values is not greater than the minimum value of the non-screened field values.

In one embodiment, the smallest field value is selected from a plurality of field values of the number of times the resource is accessed.

Step 406: and determining corresponding field deviation according to each screened field value, the average value and the standard deviation.

Step 407: and if the field deviation within the preset abnormal deviation range exists in the field deviations, determining that an abnormal field value exists, and determining that the API has a resource authorization risk.

TABLE 3

Referring to table 3, an example table of the number of times the user has accessed the resource is shown. In table 3, the field value of the number of times of resource access for each user (user) calling the API to access each resource includes the resource (resource), the number of times of resource access (times), and the user identification information. The resources include resource1 and resource 2 … ….

For example, if the target resource is resource1 and the preset abnormal deviation range is less than 10, in table 3, a group of data accessed to resource1 is time 11 and time 12 … … in sequence, and the minimum value of the access times in the group of data is determined to be time 11. Then according to the times11 and 12 … …, the deviation of the corresponding field of the times11 is determined to be 5<10, the times11 of the resource access times of the user11 accessing the resource1 in the group of data are determined to be abnormal, the resource1 is determined to have the resource authorization risk, and then the information related to the abnormality is written into the database.

It should be noted that, when step 400 to step 407 are executed, the specific steps refer to step 100 to step 102, which are not described herein again.

Scenario 4, functional authorization risk detection scenario. Referring to fig. 5, an implementation flow chart of a function authorization risk detection method is shown, and the specific implementation flow of the method is as follows:

step 500: and determining the risk category to be detected as function authorization risk.

Step 501: and determining the target field corresponding to the function authorization risk as the function call times.

Step 502: and acquiring an interface call log of the API in a preset time range.

Step 503: and screening a plurality of field values corresponding to the function calling times from the interface calling log.

In one embodiment, according to the interface call log, determining a user calling the API, a function called through the API and a field value of the number of times of function call, and establishing an association relationship among the user, the target function and the field value of the number of times of function call.

And if the number of the target functions is 1, determining a plurality of field values corresponding to the function calling times of accessing the target functions by each user through the API according to the association relation.

If the number of the target functions is multiple, the following steps may be performed for each target function respectively: and determining a plurality of field values corresponding to one target function according to the association relation.

Therefore, in the subsequent steps, after the abnormal field value exists in the field value of any target function, the abnormal user associated with the abnormal field value and any target function can be determined according to the association relation, and therefore the function authorization risk exists when the abnormal user calls any target function through the API.

It should be noted that the association relationship may be executed before step 503 is executed, and is not limited herein.

Step 504: an average value and a standard deviation of a plurality of field values of the number of function calls are determined.

Step 505: and screening the field values which meet preset screening conditions from the plurality of field values of the function calling times.

In one embodiment, the smallest field value is selected from a plurality of field values of the number of function calls.

Step 506: and determining corresponding field deviation according to each screened field value, the average value and the standard deviation.

Step 507: and if the field deviation in the preset abnormal deviation range exists in the field deviations, determining that an abnormal field value exists, and determining that the API has a function authorization risk.

TABLE 4

Referring to table 4, an example table of the number of function calls by the user to call the function through the API is shown. In table 4, functions, times of function calls (times), and user identification information (user) are included. Wherein, the function is respectively: GET, POST and PUT. The function calling times timeskL are the resource access times of the user L accessing the resource K.

For example, assuming that the target function is POST, the preset abnormality deviation range is less than 10. In table 3, a group of data using the POST is sequentially time 21 and time 22 … …, the minimum value of the function call times in the group of data is determined to be time 21, and if the deviation of the corresponding field of time 21 is determined to be 5<10 according to the time 21 and the time 22 … …, the time 21 in the group of data is determined to be an abnormal field value, that is, the function call times of the user21 calling the POST are determined to be abnormal, the function authorization risk of the POST is determined, and then the related abnormal information is written into the database.

Referring to fig. 6, an implementation flow chart of a method for risk detection and alarm provided in the embodiment of the present application is shown, and a specific implementation flow of the method is as follows:

step 600: and determining that the preset trigger time is reached.

Step 601: and acquiring unprocessed interface call logs from a log storage device.

Step 602: and extracting field values of target fields set for the risk categories to be detected from the interface call logs.

Furthermore, all the extracted interface call logs and field values are stored in a reference database.

Step 603: an exception field value among the field values is determined.

Further, the determined abnormal field value and the related information are stored in a risk database.

Step 604: and determining a risk detection result according to the determined abnormal field value.

Step 605: the risk detection result and the exception field value are added to the Kafka message queue.

Step 606: an alarm is issued to the manager via the Kafka message queue and step 600 is performed.

Based on the same inventive concept, the embodiment of the present application further provides a device for API risk detection, and because the principle of solving the problem by the device and the apparatus is similar to that of the method for API risk detection, the implementation of the device may refer to the implementation of the method, and repeated details are not repeated.

As shown in fig. 7, which is a schematic structural diagram of an apparatus for API risk detection provided in an embodiment of the present application, including:

a first determining unit 701, configured to determine a risk category to be detected;

a screening unit 702, configured to screen a field value of a target field corresponding to a risk category from an interface call log of an application programming interface in a preset time range;

a second determining unit 703, configured to determine that the application programming interface is at risk if an abnormal field value exists in the field values.

Preferably, the field values are multiple, and the second determining unit 703 is configured to:

Preferably, the second determining unit 703 is configured to: screening out field values meeting preset screening conditions from a plurality of field values of a target field;

Preferably, the second determining unit 703 is configured to: screening a specified number of field values from a plurality of field values of a target field, wherein the minimum value of the screened field values is not less than the maximum value of the non-screened field values;

Preferably, the interface call log comprises: the application programming interface access log and the application programming interface authentication log; the second determining unit 703 is further configured to:

In the method, the device, the equipment and the medium for detecting the risks of the application programming interface, the types of the risks to be detected are determined; screening a field value of a target field corresponding to a risk category from an interface call log of an application programming interface in a preset time range; and if the abnormal field value exists in the field values, determining that the application programming interface is at risk. Therefore, the logs are called through the interface of the API, risk detection of different risk categories is carried out, the complex operation of the risk detection is simplified, and the cost of manpower and material resources consumed by the risk detection is reduced.

Fig. 8 shows a schematic structural diagram of an electronic device 8000. Referring to fig. 8, the electronic device 8000 includes: a processor 8010, a memory 8020, a power supply 8030, a display unit 8080, and an input unit 8050.

The processor 8010 is the control center of the electronic device 8000, and it is to be understood that various functions of the electronic device 8000 may be performed by operating or executing software programs and/or data stored in the memory 8020 by connecting various components using various interfaces and lines, thereby performing overall monitoring of the electronic device 8000.

In an embodiment of the application, the processor 8010 executes the method of risk detection of the API as provided by the embodiment shown in fig. 1 when calling a computer program stored in the memory 8020.

Alternatively, the processor 8010 may comprise one or more processing units; preferably, the processor 8010 may integrate the application processor, which handles primarily the operating system, user interface, applications, etc., and the modem processor, which handles primarily the wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 8010. In some embodiments, the processor, memory, and/or memory may be implemented on a single chip, or in some embodiments, they may be implemented separately on separate chips.

The memory 8020 may mainly include a program storage area and a data storage area, in which an operating system, various applications, and the like may be stored; the stored data area may store data created according to the use of the electronic device 8000, and the like. Further, the memory 8020 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device.

The electronic device 8000 may also include a power supply 8030 (e.g., a battery) that may be used to provide power to the various components, which may be logically coupled to the processor 8010 via a power management system, which may be used to manage charging, discharging, and power consumption.

The display unit 8080 may be used to display information input by a user or information provided to the user, various menus of the electronic device 8000, and the like, and in the embodiment of the present invention, the display unit is mainly used to display a display interface of each application in the electronic device 8000 and objects such as texts and pictures displayed in the display interface. The display unit 8080 may include a display panel 8041. The Display panel 8041 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like.

The input unit 8050 can be used to receive information such as numbers or characters input by a user. The input unit 8050 may include a touch panel 8051 and other input devices 8052. Among other things, the touch panel 8051, also referred to as a touch screen, can collect touch operations by a user on or near the touch panel 8051 (e.g., operations by a user on or near the touch panel 8051 using any suitable object or accessory such as a finger, a stylus, etc.).

Specifically, the touch panel 8051 can detect a touch operation of a user, detect signals caused by the touch operation, convert the signals into touch point coordinates, send the touch point coordinates to the processor 8010, receive a command sent by the processor 8010, and execute the command. In addition, the touch panel 8051 can be implemented by various types such as a resistive type, a capacitive type, an infrared ray, and a surface acoustic wave. Other input devices 8052 can include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, power on/off keys, etc.), a trackball, a mouse, a joystick, and the like.

Of course, the touch panel 8051 can cover the display panel 8041, and when the touch panel 8051 detects a touch operation thereon or nearby, the touch panel 8051 is transmitted to the processor 8010 to determine the type of the touch event, and then the processor 8010 provides a corresponding visual output on the display panel 8041 according to the type of the touch event. Although in FIG. 8, the touch panel 8051 and the display panel 8041 are shown as two separate components to implement the input and output functions of the electronic device 8000, in some embodiments, the touch panel 8051 and the display panel 8041 can be integrated to implement the input and output functions of the electronic device 8000.

The electronic device 8000 may also include one or more sensors, such as pressure sensors, gravitational acceleration sensors, proximity light sensors, and the like. Of course, the electronic device 8000 may also include other components such as a camera, as required in a particular application, and these components are not shown in fig. 8 and will not be described in detail since they are not components that are used in the embodiments of the present application.

Those skilled in the art will appreciate that fig. 8 is merely an example of an electronic device and is not limiting of electronic devices and may include more or fewer components than those shown, or some components may be combined, or different components.

In an embodiment of the present application, a readable storage medium has a computer program stored thereon, and when the computer program is executed by a processor, the communication device may perform the steps in the above embodiments.

For convenience of description, the above parts are separately described as modules (or units) according to functional division. Of course, the functionality of the various modules (or units) may be implemented in the same one or more pieces of software or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims

1. A risk detection method for an Application Programming Interface (API), comprising:

determining a risk category to be detected;

screening the field value of the target field corresponding to the risk category from an interface call log of an application programming interface in a preset time range;

and if an abnormal field value exists in the field values, determining that the application programming interface is at risk.

2. The method of claim 1, wherein the risk categories include any one or any combination of:

3. The method as claimed in claim 1 or 2, wherein the field value is plural, and the determining that the application programming interface is at risk if an abnormal field value exists in the field value comprises:

determining a mean and a standard deviation of a plurality of field values of the target field;

judging whether an abnormal field value exists according to each field value of the target field, the average value and the standard deviation;

if yes, determining that an abnormal field value exists, and determining that the application programming interface has risks;

4. The method as claimed in claim 3, wherein said determining whether there is an abnormal field value according to each field value of the target field, the average value and the standard deviation comprises:

screening out field values meeting preset screening conditions from the plurality of field values of the target field;

5. The method as claimed in claim 4, wherein said filtering out a field value meeting a preset filtering condition from a plurality of field values of said target field comprises:

screening a specified number of field values from a plurality of field values of the target field, wherein the minimum value of the screened field values is not less than the maximum value of the non-screened field values;

or, a specified number of field values are sorted out from a plurality of the field values, wherein a maximum value of the sorted out field values is not greater than a minimum value of the non-sorted out field values.

6. The method of claim 1, wherein the interface call log comprises: the application programming interface access log and the application programming interface authentication log; the method further comprises the following steps:

and associating the application programming interface access log with an object calling the application programming interface access log based on the information in the application programming interface authentication log.

7. The method of claim 2, wherein the authentication risk refers to a risk of abnormal authentication when the user performs authentication;

the function authorization risk refers to the risk that unauthorized calling exists when the function is called.

8. A risk detection apparatus for an application programming interface, comprising:

the screening unit is used for screening the field value of the target field corresponding to the risk category from an interface call log of an application programming interface in a preset time range;

9. An electronic device comprising a processor and a memory, the memory storing computer readable instructions that, when executed by the processor, perform the method of any of claims 1-7.

10. A readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 7.