CN115310085A - SDK risk detection method, device and equipment - Google Patents

SDK risk detection method, device and equipment Download PDF

Info

Publication number
CN115310085A
CN115310085A CN202210899294.0A CN202210899294A CN115310085A CN 115310085 A CN115310085 A CN 115310085A CN 202210899294 A CN202210899294 A CN 202210899294A CN 115310085 A CN115310085 A CN 115310085A
Authority
CN
China
Prior art keywords
honeypot
sdk
configuration data
detected
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210899294.0A
Other languages
Chinese (zh)
Inventor
袁静
刘阳
高强
徐峰
张家旺
陈禹
王鹏翩
张晓娜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
National Computer Network and Information Security Management Center
Original Assignee
National Computer Network and Information Security Management Center
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National Computer Network and Information Security Management Center filed Critical National Computer Network and Information Security Management Center
Priority to CN202210899294.0A priority Critical patent/CN115310085A/en
Publication of CN115310085A publication Critical patent/CN115310085A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Virology (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The invention discloses a risk detection method, a risk detection device and a risk detection device for SDK, wherein the method comprises the following steps: acquiring an application program containing the SDK to be detected; acquiring a log generated by the running of an application program in a preset first honeypot; when the log indicates that the first honeypot is not a valid honeypot, determining a probability value that the first honeypot is identified; wherein the effective target honeypot is a honeypot which successfully induces the SDK to be detected to output the risk behavior; and when the probability value is greater than a preset probability threshold value, generating a second honeypot according to the log and the service type of the SDK to be detected, and determining the risk level of the SDK according to the log generated by the application program running in the second honeypot.

Description

SDK risk detection method, device and equipment
Technical Field
The invention relates to the technical field of network security, in particular to a risk detection method, device and equipment for an SDK (software development kit).
Background
Currently, the use of an SDK (Software Development Kit) is very common, and multiple SDKs can be integrated in the same product. With the widespread use of SDKs, their associated security issues are also receiving increasing attention.
In the existing SDK security detection method, before an SDK is issued, information security personnel usually adopt a form of separately scanning an SDK code to judge whether the SDK has security holes. Subject to the skill level of information security personnel, it is highly likely that security vulnerabilities of an SDK cannot be fully discovered, thereby posing a potential security risk to a product incorporating the SDK.
Therefore, a risk detection method for the SDK is needed to effectively detect the risk of the SDK and avoid potential security risk to a product integrating the SDK.
Disclosure of Invention
The embodiment of the invention provides a risk detection method, a risk detection device and a risk detection device for an SDK (software development kit), which are used for solving the problem that the risk of the SDK cannot be effectively detected in the prior art and avoiding potential safety risk brought to a product integrating the SDK.
In order to solve the technical problem, the invention is realized as follows:
in a first aspect, a method for detecting a risk of an SDK is provided, the method including:
acquiring an application program containing the SDK to be detected;
acquiring a log generated by the running of the application program in a preset first honeypot;
determining a probability value that the first honeypot is identified when the log characterizes that the first honeypot is not a valid honeypot; wherein the effective target honeypot is a honeypot which successfully induces the SDK to be detected to output the risk behavior;
and when the probability value is greater than a preset probability threshold value, generating a second honeypot according to the log and the service type of the SDK to be detected, and determining the risk level of the SDK according to the log generated by the operation of the application program in the second honeypot.
In a second aspect, an apparatus for risk detection of an SDK is provided, the apparatus comprising:
the first acquisition module is used for acquiring an application program containing the SDK to be detected;
the second acquisition module is used for acquiring a log generated by the running of the application program in a preset first honeypot;
a first determination module, configured to determine a probability value that the first honeypot is identified when the log indicates that the first honeypot is not a valid honeypot; wherein the effective target honeypot is a honeypot which successfully induces the SDK to be detected to output the risk behavior;
and the second determining module is used for generating a second honeypot according to the log and the service type of the SDK to be detected when the probability value is larger than a preset probability threshold value, and determining the risk level of the SDK according to the log generated by the operation of the application program in the second honeypot.
In a third aspect, a risk detection device for an SDK is provided, the risk detection device comprising a processor, a memory and a computer program stored on the memory and executable on the processor, the computer program, when executed by the processor, implementing the steps of the method according to the first aspect.
In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored which, when executed by a processor, carries out the steps of the method according to the first aspect.
In the embodiment of the invention, when the risk detection is performed on the SDK, an application program including the SDK can be acquired, and a log generated when the application program runs in a preset first honeypot can be acquired. When the log represents that the first honeypot is not an effective honeypot, namely the first honeypot does not successfully induce the SDK to be detected to generate the risk behavior, the probability value of the first honeypot to be identified is determined, when the probability value is larger than a preset probability threshold value, a second honeypot can be generated according to the log and the service type of the SDK to be detected, and the risk level of the SDK is determined according to the log generated when the application program runs in the second honeypot.
Therefore, in the embodiment of the invention, when the risk detection is performed on the SDK, the detection may be performed through a preset first honeypot, when the security risk of the SDK is not detected through the first honeypot, whether the first honeypot has a higher probability to be identified may be further determined, if the first honeypot has the higher probability to be identified, a targeted second honeypot may be generated according to a log generated when the application including the SDK runs in the first honeypot and a service type of the SDK, and a risk level of the SDK may be determined according to a log generated when the application including the SDK runs in the second honeypot. Because the SDK can be subjected to security detection through the targeted second honeypot instead of being simply and roughly subjected to security detection only according to the first honeypot, the detection accuracy of the SDK can be effectively improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the invention and do not limit the invention. In the drawings:
fig. 1 is a schematic flow chart of a risk detection method for an SDK according to an embodiment of the present invention;
fig. 2 is a schematic block diagram of a risk detection apparatus for an SDK according to an embodiment of the present invention;
fig. 3 is a schematic diagram of a hardware structure of a risk detection device for an SDK according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the technical solutions of the present invention will be clearly and completely described below with reference to the specific embodiments of the present invention and the accompanying drawings. It is to be understood that the disclosed embodiments are merely exemplary of the invention, and are not intended to be exhaustive or exhaustive. All other embodiments, which can be obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, belong to the protection scope of the present invention.
The technical solutions provided by the embodiments of the present invention are described in detail below with reference to the accompanying drawings.
Referring to fig. 1, fig. 1 is a schematic flow chart of a risk detection method for an SDK according to an embodiment of the present invention, as shown in fig. 1, the method includes the following steps:
step 102: and acquiring the application program containing the SDK to be detected.
Step 104: acquiring a log generated by the running of an application program in a preset first honeypot;
step 106: when the log indicates that the first honeypot is not a valid honeypot, determining a probability value that the first honeypot is identified; wherein the effective target honeypot is a honeypot which successfully induces the SDK output risk behaviors to be detected.
Step 108: and when the probability value is greater than a preset probability threshold value, generating a second honeypot according to the log and the service type of the SDK to be detected, and determining the risk level of the SDK according to the log generated by the application program running in the second honeypot.
In the embodiment of the present invention, for the SDK to be detected, the application program integrating the SDK to be detected may be obtained first, that is, the application program including the SDK to be detected may be obtained. Then, the service type of the SDK to be detected can be further obtained to generate the first honeypot according to the service type.
The service type of the SDK to be detected may be determined according to the function provided by the SDK, and may be determined from a related document or example in the SDK to be detected, where the service type of the SDK to be detected may include, for example: the third party logs in a sharing class, a payment class, a pushing class, an advertisement class, a data statistical analysis class, a map class and the like.
In the embodiment of the present invention, when the importance degree of the service type of the SDK to be detected is higher, the preset level of the first honeypot is higher. For example, when the service type of the SDK to be detected is the payment class, the importance degree is higher, and the preset first honeypot may be a high-interaction honeypot; when the service type of the SDK to be detected is an advertisement type, the importance degree is low, and the preset first honeypot may be a low-interaction honeypot.
In the embodiment of the invention, after the first honeypot is generated, a log generated by the application program running in the preset first honeypot can be obtained, and whether the first honeypot is a valid honeypot can be determined according to the log.
In the embodiment of the invention, considering that honeypots may be identified, and under the condition that honeypots are identified, risk behaviors in the SDK may not attack honeypots temporarily, but attack real systems when the real systems are replaced, so as to cause security risks of the real systems, after an application program runs in a preset first honeypot, the embodiment of the invention can determine whether the first honeypot is a honeypot which successfully induces the SDK to be detected to output the risk behaviors according to logs generated by running, and further determine the probability value of the identified first honeypot under the condition that the first honeypot is not a valid honeypot.
When the probability value of the first honeypot being identified is determined, the associated simulation configuration data corresponding to the first honeypot may be determined according to the service type of the SDK to be detected, then, according to the log, an operation event of the application program running in the first honeypot is obtained, where the operation event includes an operation type and an operation time, and after the operation event is determined, the probability value of the first honeypot being identified is determined according to the discrete degree of the operation event in time.
In the embodiment of the present invention, the service type of each SDK and the corresponding association relationship between the service type and the simulation configuration data may be preset. For example, the data statistical analysis class, the corresponding association relationship between the accessible interface and the accessible address, and the like may be preset. According to the service types of the SDKs, simulation configuration data with high risk behavior operation probability can be determined, and meanwhile, the data are data which easily cause the first honeypot to be identified. Therefore, after the service type of the current SDK to be detected is obtained, the associated simulation configuration data corresponding to the first honeypot can be determined according to the service type of the current SDK to be detected.
After determining the associated simulation configuration data corresponding to the first honeypot, the operation event of the application program in the first honeypot for the associated simulation configuration data corresponding to the first honeypot when the application program including the SDK to be detected runs in the first honeypot may be obtained according to a log generated when the application program runs in the first honeypot. The operation event may include an operation type and an operation time. For example, the operation types may be: reading data; the operating time may be: 1/20/2022.
In the embodiment of the invention, what operation is performed on the associated simulation configuration data by the application program at what time can be determined according to the log and the associated simulation configuration data corresponding to the first honeypot, so as to evaluate whether the first honeypot is identified through the associated configuration data.
After the operation events for the associated simulation configuration data corresponding to the first honeypot are obtained, the probability value of the first honeypot being identified can be determined according to the discrete degree of the operation events in time.
In the embodiment of the invention, considering that when a certain associated simulation configuration data suspects that the first honeypot is not a real system, other associated simulation configuration data are obtained with high probability for verification, and when the first honeypot is determined to be not a real system through multiple times of verification, the associated simulation configuration data are not verified, so that the probability value of the first honeypot being identified is determined according to the discrete degree of the operation event in time.
When the probability value of the first honeypot being identified is determined, the operation time corresponding to each operation event can be obtained, the number of first operation events of which the time intervals between the corresponding operation times are smaller than a first preset time interval and the maximum number of second operation events corresponding to the operation time within a second preset time interval are determined, and then the probability value of the first honeypot being identified can be determined according to the number of the first operation events, the number of the second operation events, the total number of the operation events and a preset probability calculation formula. Wherein the second preset time interval may be smaller than the first preset time interval.
In one example, the operational events may include 5 operational events, operational event 1, operational event 2, operational event 3, operational event 4, and operational event 5; wherein, the operation time corresponding to the 5 operation events may be respectively: 1/20 in 2022, 1/20 in 2022, 08 in 2022, 1/20 in 2022, 1/09 in 2022, and 1/20 in 2022. The first operation time interval may be 3 minutes 30 seconds, the second operation time interval may be 2 minutes 10 seconds, and as is known from operation event 1 and operation event 2 by 5 minutes, operation event 2 and operation event 3 by 3 minutes, operation event 3 and operation event 4 by 1 minute, and operation event 4 and operation event 5 by 2 minutes, the first operation event may include: operation event 2, operation event 3, operation event 4, and operation event 5, and therefore, the number of first operation events is 4; as is evident from operating event 3 and operating event 4 being separated by 1 minute, and the time intervals between other operating events (including the time intervals between operating event 3 or operating event 4 and other operating events, and between other operating events) being greater than 2 minutes and 10 seconds, the second operating event may include: event 3 and event 4 are operated, so the number of second operation events is 2.
After determining the number of the first operation events, the number of the second operation events, and the total number of the operation events, the probability value of the first honeypot being identified may be determined according to a preset probability calculation formula.
In one example, the preset probability calculation formula may be:
Figure BDA0003770370430000061
wherein P may be a probability value that the first honeypot is identified; s. the General assembly May be the total number of operational events; s 1 May be the first number of operational events; s 2 May be the second number of operational events.
When the first number of operation events is 4, the second number of operation events is 2, and the total number of operation events is 5, the probability value that the first honeypot is identified may be: 0.8e 0.5 。
After determining the probability value that the first honeypot is identified, it may be determined whether the probability value is greater than a preset probability threshold. If the running time of the application program is not larger than the preset running time, the risk level of the SDK to be detected can be determined directly according to the log generated by the running of the application program in the preset first honeypot. Because the log representation includes that the application program of the SDK to be detected does not generate the risk behavior, it can be determined that the risk level of the SDK to be detected is low.
If the probability value is larger than the preset probability threshold value, the first honeypot is identified with higher probability, at the moment, a second honeypot can be generated according to the log and the service type of the SDK to be detected, and the risk level of the SDK is determined according to the log generated by the application program running in the second honeypot.
When a second honeypot is generated according to the log and the service type of the SDK to be detected, target associated simulation configuration data corresponding to an operation event with a low dispersion degree in time may be acquired first, then, real associated configuration data corresponding to the target associated simulation configuration data in a real system simulated by the first honeypot may be determined, and the target associated simulation configuration data is adjusted according to the real associated configuration data, wherein the similarity between the adjusted target associated simulation configuration data and the real associated configuration is not higher than a similarity threshold, and then, the first honeypot is adjusted according to the adjusted target associated simulation configuration data to generate the second honeypot.
In the implementation of the invention, when the second honeypot is generated according to the log and the service type of the SDK to be detected, the target associated simulation configuration data corresponding to the operation event with low dispersion degree in time can be obtained, that is, the associated simulation configuration data which is operated in a centralized manner can be obtained. Since the associated simulation configuration data is more likely to cause the first honeypot to be identified, embodiments of the present invention can iterate to adjust the associated simulation configuration data to generate the corresponding second honeypot.
When the target associated simulation configuration data is adjusted, the real associated configuration data corresponding to the target associated simulation configuration data in the real system of the first honeypot simulation may be determined first, and then the target associated simulation configuration data may be adjusted according to the real associated configuration data.
In one example, when the target associated simulation configuration data is adjusted according to the real associated configuration data, the weight coefficient may be determined according to the discrete degree of the operation event with low discrete degree in time, and the target associated simulation configuration data is adjusted according to the weight coefficient and the real associated configuration data.
When determining the weight coefficient according to the temporal dispersion degree of the operation events with low temporal dispersion degree, the third operation event number of the operation events with low temporal dispersion degree, the time interval between the corresponding operation times of which is smaller than the third preset time interval, and the maximum fourth operation event number of the operation events with low temporal dispersion degree, corresponding to the operation time within the fourth preset time interval, may be obtained, and then the weight coefficient may be determined according to the third operation event number, the fourth operation event number, the total number of the operation events with low temporal dispersion degree, and the preset weight calculation formula. Wherein the fourth preset time interval may be smaller than the third preset time interval.
In one example, the operation events with a low degree of temporal dispersion may include 4 operation events of operation event 2, operation event 3, operation event 4, and operation event 5; wherein, the operation time corresponding to the 4 operation events may be respectively: 1/2022/1/20, 08, 1/2022/1/20, 09, and 1/20/2022. The third operational time interval may be 2 minutes 30 seconds, the second operational time interval may be 1 minute 30 seconds, and then operational events 2 and 3 are known 3 minutes apart, operational events 3 and 4 are known 1 minute apart, and operational events 4 and 5 are known 2 minutes apart, and the third operational event may include: operation event 3, operation event 4, and operation event 5, and thus the number of first operation events is 3; as seen by the interval between operational events 3 and 4 being 1 minute, and the time interval between other operational events being greater than 1 minute and 30 seconds, the fourth operational event may include: event 3 and event 4, the number of fourth events is 2.
After determining the number of the third operation events, the number of the fourth operation events, and the total number of the operation events with low dispersion degree in time, the weight coefficient may be weighted according to a preset weight calculation formula.
In one example, the preset weight calculation formula may be:
Figure BDA0003770370430000081
wherein K may be a weight coefficient; s. the 0 May be the total number of operating events that are less discrete in time; s 3 The number of the third operation events can be set; s 4 The number of fourth operation events may be.
When the number of the first operation events is 3, the number of the second operation events is 2, and the total number of the operation events is 4, the weighting coefficient may be: 0.75e 0.22 。
After the target associated simulation configuration data is adjusted according to the weight coefficients and the real associated configuration data, a second honeypot can be generated, and the risk level of the SDK is determined according to a log generated by the application program running in the second honeypot.
In the embodiment of the invention, when the risk detection is performed on the SDK, an application program including the SDK can be acquired, and a log generated when the application program runs in a preset first honeypot can be acquired. When the log represents that the first honeypot is not an effective honeypot, namely the first honeypot does not successfully induce the SDK to be detected to generate the risk behavior, the probability value of the first honeypot to be identified is determined, when the probability value is larger than a preset probability threshold value, a second honeypot can be generated according to the log and the service type of the SDK to be detected, and the risk level of the SDK is determined according to the log generated when the application program runs in the second honeypot.
Therefore, in the embodiment of the invention, when the risk detection is performed on the SDK, the detection may be performed through a preset first honeypot, when the security risk of the SDK is not detected through the first honeypot, whether the first honeypot has a higher probability to be identified may be further determined, if the first honeypot has the higher probability to be identified, a targeted second honeypot may be generated according to a log generated when the application including the SDK runs in the first honeypot and a service type of the SDK, and a risk level of the SDK may be determined according to a log generated when the application including the SDK runs in the second honeypot. Because the SDK can be subjected to security detection through the targeted second honeypot instead of being simply and roughly subjected to security detection only according to the first honeypot, the detection accuracy of the SDK can be effectively improved.
Corresponding to the above risk detection method for an SDK, an embodiment of the present invention further provides a risk detection apparatus for an SDK, fig. 2 is a schematic diagram of module components of the risk detection apparatus for an SDK provided in the embodiment of the present invention, and as shown in fig. 2, the risk detection apparatus for an SDK includes:
a first obtaining module 21, configured to obtain an application program including an SDK to be detected;
a second obtaining module 22, configured to obtain a log generated by running the application in a preset first honeypot;
a first determining module 23, configured to determine a probability value that the first honeypot is identified when the log indicates that the first honeypot is not a valid honeypot; wherein the effective target honeypot is a honeypot which successfully induces the SDK to be detected to output the risk behavior;
and a second determining module 24, configured to, when the probability value is greater than a preset probability threshold, generate a second honeypot according to the log and the service type of the SDK to be detected, and determine the risk level of the SDK according to the log generated by the application running in the second honeypot.
Optionally, the apparatus further comprises:
a third obtaining module 25, configured to obtain the service type of the SDK to be detected before obtaining the log generated when the application runs in a preset first honeypot;
and the generating module 26 is configured to generate the first honeypot according to the service type of the SDK to be detected.
The generation module 26 is configured to:
the determining a probability value that the first honeypot is identified includes:
determining associated simulation configuration data corresponding to the first honeypot according to the service type of the SDK to be detected;
according to the log, acquiring an operation event of the associated simulation configuration data corresponding to the first honeypot when the application program runs in the first honeypot; the operation event comprises an operation type and an operation time;
and determining the probability value of the first honeypot being identified according to the discrete degree of the operation event in time.
Optionally, the generating module 26 is further configured to:
acquiring operation time corresponding to each operation event;
determining the number of first operation events of which the time intervals between the corresponding operation times are smaller than a first preset time interval and the maximum number of second operation events corresponding to the operation times in a second preset time interval;
and determining the probability value of the first honeypot identification according to the number of the first operation events, the number of the second operation events, the total number of the operation events and a preset probability calculation formula.
Optionally, the preset probability calculation formula is as follows:
Figure BDA0003770370430000111
wherein P is a probability value that the first honeypot is identified; s. the General assembly Is the total number of operation events; s. the 1 The number of the first operation events is the number; s 2 The number of the second operation events is the number of the second operation events.
Optionally, the generating module 26 is configured to:
acquiring target associated simulation configuration data corresponding to an operation event with low discrete degree in time;
determining real associated configuration data corresponding to the target associated simulation configuration data in the real system of the first honeypot simulation;
adjusting the target correlation simulation configuration data according to the real correlation configuration data; the similarity between the adjusted target associated simulation configuration data and the real associated configuration is not higher than a similarity threshold value;
and adjusting the first honeypot according to the adjusted target associated simulation configuration data to generate the second honeypot.
Optionally, the generating module 26 is further configured to:
determining a weight coefficient according to the discrete degree of the operation event with the low discrete degree in time;
and adjusting the target associated simulation configuration data according to the weight coefficient and the real associated configuration data.
In the embodiment of the invention, when the risk detection is performed on the SDK, an application program including the SDK can be acquired, and a log generated when the application program runs in a preset first honeypot can be acquired. When the log represents that the first honeypot is not a valid honeypot, namely the first honeypot does not successfully induce the SDK to be detected to output the risk behavior, the identified probability value of the first honeypot is determined, when the probability value is larger than a preset probability threshold value, a second honeypot can be generated according to the log and the service type of the SDK to be detected, and the risk level of the SDK is determined according to the log generated when the application program runs in the second honeypot.
Therefore, in the embodiment of the invention, when the risk detection is performed on the SDK, the detection may be performed through a preset first honeypot, when the security risk of the SDK is not detected through the first honeypot, whether the first honeypot has a higher probability to be identified may be further determined, if the first honeypot has the higher probability to be identified, a targeted second honeypot may be generated according to a log generated when the application including the SDK runs in the first honeypot and a service type of the SDK, and a risk level of the SDK may be determined according to a log generated when the application including the SDK runs in the second honeypot. Because the SDK can be subjected to security detection through the targeted second honeypot instead of simply and roughly carrying out security detection on the SDK according to the first honeypot, the detection accuracy of the SDK can be effectively improved.
Corresponding to the above risk detection method for the SDK, an embodiment of the present invention further provides a risk detection device for the SDK, and fig. 3 is a schematic diagram of a hardware structure of the risk detection device for the SDK according to an embodiment of the present invention.
The risk detection device for the SDK may be a terminal device or a server provided in the foregoing embodiment for detecting the risk of the SDK.
The risk detection device of the SDK may have a relatively large difference due to different configurations or performances, and may include one or more processors 301 and a memory 302, and the memory 302 may store one or more stored applications or data. Memory 302 may be, among other things, transient storage or persistent storage. The application program stored in memory 302 may include one or more modules (not shown), each of which may include a series of computer-executable instructions in a risk detection device for an SDK. Still further, the processor 301 may be configured to communicate with the memory 302 to execute a series of computer-executable instructions in the memory 302 on a risk detection device for an SDK. The risk detection apparatus of the SDK may also include one or more power supplies 303, one or more wired or wireless network interfaces 304, one or more input-output interfaces 305, one or more keyboards 306.
Specifically, in this embodiment, the risk detection device for the SDK includes a memory and one or more programs, where the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions in the determination device for the server identifier corresponding to the application installation package, and is configured to be executed by one or more processors, where the one or more programs include instructions for performing the above steps and can achieve the same technical effects as the above steps, which are not described in detail herein.
Further, based on the method shown in fig. 1, one or more embodiments of the present specification further provide a storage medium for storing computer-executable instruction information, where in a specific embodiment, the storage medium may be a usb disk, an optical disk, a hard disk, or the like, and when the computer-executable instruction information stored in the storage medium is executed by a processor, each process implemented by the risk detection method device in the above-described SDK risk detection method embodiment can be implemented, and is not described herein again to avoid repetition.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain a corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development, but the original code before compiling is also written in a specific Programming Language, which is called Hardware Description Language (HDL), and the HDL is not only one kind but many kinds, such as abll (Advanced boot Expression Language), AHDL (alternate hard Description Language), traffic, CUPL (computer universal Programming Language), HDCal (Java hard Description Language), lava, lola, HDL, PALASM, software, rhydl (Hardware Description Language), and vhul-Language (vhyg-Language), which is currently used in the field. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium that stores computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the units may be implemented in one or more of software and/or hardware in implementing the invention.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention 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 invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of other like elements in a process, method, article, or apparatus comprising the element.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention 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 invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only an example of the present invention and is not intended to limit the present invention. Various modifications and alterations to this invention will become apparent to those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.

Claims (10)

1. A method for risk detection of SDK, the method comprising:
acquiring an application program containing the SDK to be detected;
acquiring a log generated by the running of the application program in a preset first honeypot;
determining a probability value that the first honeypot is identified when the log characterizes that the first honeypot is not a valid honeypot; wherein the effective target honeypot is a honeypot which successfully induces the SDK to be detected to output the risk behavior;
and when the probability value is greater than a preset probability threshold value, generating a second honeypot according to the log and the service type of the SDK to be detected, and determining the risk level of the SDK according to the log generated by the operation of the application program in the second honeypot.
2. The method of claim 1, wherein before the obtaining the log generated by the application program running in the preset first honeypot, the method further comprises:
acquiring the service type of the SDK to be detected;
and generating a first honeypot according to the service type of the SDK to be detected.
3. The method of claim 2, wherein the determining a probability value that the first honeypot is identified comprises:
determining associated simulation configuration data corresponding to the first honeypot according to the service type of the SDK to be detected;
according to the log, acquiring an operation event of the associated simulation configuration data corresponding to the first honeypot when the application program runs in the first honeypot; the operation event comprises an operation type and an operation time;
and determining the probability value of the first honeypot being identified according to the discrete degree of the operation event in time.
4. The method of claim 3, wherein the determining the probability value that the first honeypot is identified according to the degree of dispersion of the operational event in time comprises:
acquiring operation time corresponding to each operation event;
determining the number of first operation events of which the time intervals between the corresponding operation times are smaller than a first preset time interval and the maximum number of second operation events corresponding to the operation times in a second preset time interval;
and determining the probability value of the identified first honeypot according to the number of the first operation events, the number of the second operation events, the total number of the operation events and a preset probability calculation formula.
5. The method of claim 4, wherein the predetermined probability calculation formula is:
Figure FDA0003770370420000021
wherein P is a probability value that the first honeypot is identified; s. the General (1) Is the total number of operational events; s 1 The number of the first operation events is the number of the first operation events; s. the 2 The number of the second operation events is.
6. The method according to claim 3, wherein the generating a second honeypot according to the log and the service type of the to-be-detected SDK comprises:
acquiring target associated simulation configuration data corresponding to an operation event with low dispersion degree in time;
determining real associated configuration data corresponding to the target associated simulation configuration data in the real system of the first honeypot simulation;
adjusting the target correlation simulation configuration data according to the real correlation configuration data; the similarity between the adjusted target associated simulation configuration data and the real associated configuration is not higher than a similarity threshold value;
and adjusting the first honeypot according to the adjusted target association simulation configuration data to generate the second honeypot.
7. The method of claim 6, wherein said adjusting said target associated simulation configuration data according to said real associated configuration data comprises:
determining a weight coefficient according to the discrete degree of the operation event with low discrete degree in time;
and adjusting the target correlation simulation configuration data according to the weight coefficient and the real correlation configuration data.
8. A risk detection apparatus for an SDK, the apparatus comprising:
the first acquisition module is used for acquiring an application program containing the SDK to be detected;
the second acquisition module is used for acquiring a log generated by the running of the application program in a preset first honeypot;
a first determining module for determining a probability value that the first honeypot is identified when the log characterizes the first honeypot as not being a valid honeypot; wherein the effective target honeypot is a honeypot which successfully induces the SDK to be detected to output the risk behaviors;
and the second determining module is used for generating a second honeypot according to the log and the service type of the SDK to be detected when the probability value is larger than a preset probability threshold value, and determining the risk level of the SDK according to the log generated by the operation of the application program in the second honeypot.
9. A risk detection device for an SDK, comprising: memory, processor and computer program stored on the memory and executable on the processor, which computer program, when executed by the processor, carries out the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, which computer program, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 7.
CN202210899294.0A 2022-07-28 2022-07-28 SDK risk detection method, device and equipment Pending CN115310085A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210899294.0A CN115310085A (en) 2022-07-28 2022-07-28 SDK risk detection method, device and equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210899294.0A CN115310085A (en) 2022-07-28 2022-07-28 SDK risk detection method, device and equipment

Publications (1)

Publication Number Publication Date
CN115310085A true CN115310085A (en) 2022-11-08

Family

ID=83859409

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210899294.0A Pending CN115310085A (en) 2022-07-28 2022-07-28 SDK risk detection method, device and equipment

Country Status (1)

Country Link
CN (1) CN115310085A (en)

Similar Documents

Publication Publication Date Title
CN107808098B (en) Model safety detection method and device and electronic equipment
CN108665143B (en) Wind control model evaluation method and device
CN111400705B (en) Application program detection method, device and equipment
CN103440456B (en) The method and device that a kind of application security is assessed
CN107729750A (en) With reference to configuration information and the Android simulator detection method and device of ardware feature
CN108536569B (en) Business behavior tracking method, device and equipment
CN111753328B (en) Private data leakage risk detection method and system
CN111639011A (en) Data monitoring method, device and equipment
CN110532755B (en) Computer-implemented risk identification method and device
CN114840427A (en) Code testing and test case generating method and device
CN115618748A (en) Model optimization method, device, equipment and storage medium
CN113419971B (en) Android system service vulnerability detection method and related device
CN110599004A (en) Risk control method, equipment, medium and device
CN112837202B (en) Watermark image generation and attack tracing method and device based on privacy protection
CN110322139B (en) Policy recommendation method and device
CN113343295A (en) Image processing method, device, equipment and storage medium based on privacy protection
CN115659340B (en) Counterfeit applet identification method and device, storage medium and electronic equipment
CN116402165A (en) Operator detection method and device, storage medium and electronic equipment
CN115310085A (en) SDK risk detection method, device and equipment
CN108334775B (en) Method and device for detecting jail-crossing plug-in
CN113992429B (en) Event processing method, device and equipment
CN111488569A (en) Authority determining and managing method, device, equipment and medium
CN111539737B (en) Account risk detection method, device and equipment
CN115688130B (en) Data processing method, device and equipment
CN111753200B (en) Data determination method, device, equipment and medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination