CN106815135B - Vulnerability detection method and device - Google Patents
Vulnerability detection method and device Download PDFInfo
- Publication number
- CN106815135B CN106815135B CN201510855801.0A CN201510855801A CN106815135B CN 106815135 B CN106815135 B CN 106815135B CN 201510855801 A CN201510855801 A CN 201510855801A CN 106815135 B CN106815135 B CN 106815135B
- Authority
- CN
- China
- Prior art keywords
- source code
- code file
- file
- original
- vulnerability
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
- Stored Programmes (AREA)
Abstract
The application discloses a vulnerability detection method and device. Wherein, the method comprises the following steps: acquiring a source code file of a target application, wherein the source code file comprises identification information of the target application; searching whether the identification information is stored in a database or not, and extracting an original source code file corresponding to the identification information from the database under the condition that the identification information is stored in the database; judging whether the source code file is the same as the original source code file or not; if the source code files are different, acquiring a first source code which is different from the original source code file in the source code file; and matching the first source code with a pre-established vulnerability repair characteristic model to determine the vulnerability repaired by the first source code. The method and the device solve the technical problem that in the prior art, the vulnerability position and the repaired vulnerability parameters cannot be effectively identified, and more manpower is consumed to analyze the vulnerability.
Description
Technical Field
The application relates to the field of information security, in particular to a vulnerability detection method and device.
Background
In recent years, as more and more applications on the internet are developed, the vulnerability probability of the applications is greatly increased, and manufacturers release new versions containing patches to introduce vulnerability fixing schemes for various applications. In the process of releasing the new version, relevant personnel need to know the positions, parameters and the like of the vulnerabilities repaired by the new version so as to determine the security of the new version.
However, most of the existing technologies are to download the patch to the corresponding page by simply monitoring the information of the patch page, and read the vulnerability description file, passively obtain some information about the vulnerability, and cannot effectively identify the vulnerability location and the repaired vulnerability parameters, and only manually perform vulnerability analysis.
In view of the above problems, no effective solution has been proposed.
Disclosure of Invention
The embodiment of the application provides a vulnerability detection method and device, which at least solve the technical problem that in the prior art, vulnerability analysis needs to be carried out by consuming more manpower due to the fact that vulnerability positions and repaired vulnerability parameters cannot be effectively identified.
According to an aspect of the embodiments of the present application, there is provided a vulnerability detection method, including: acquiring a source code file of a target application, wherein the source code file comprises identification information of the target application; searching whether the identification information is stored in a database or not, and extracting an original source code file corresponding to the identification information from the database under the condition that the identification information is stored in the database; judging whether the source code file is the same as the original source code file or not; if the source code files are different, acquiring a first source code which is different from the original source code file in the source code file; and matching the first source code with a pre-established vulnerability repair characteristic model to determine the vulnerability repaired by the first source code.
According to another aspect of the embodiments of the present application, there is also provided a vulnerability detection apparatus, including: the system comprises a first acquisition unit, a second acquisition unit and a third acquisition unit, wherein the first acquisition unit is used for acquiring a source code file of a target application, and the source code file comprises identification information of the target application; the searching unit is used for searching whether the identification information is stored in the database or not, and extracting an original source code file corresponding to the identification information from the database under the condition that the identification information is stored in the database; the judging unit is used for judging whether the source code file is the same as the original source code file or not; the second acquisition unit is used for acquiring a first source code which is different from the original source code file in the source code file if the source codes are different; and the detection unit is used for matching the first source code with a pre-established vulnerability repair characteristic model and determining the vulnerability repaired by the first source code.
In the embodiment of the application, a source code file of a target application is obtained, wherein the source code file comprises identification information of the target application; searching whether the identification information is stored in a database or not, and extracting an original source code file corresponding to the identification information from the database under the condition that the identification information is stored in the database; judging whether the source code file is the same as the original source code file or not; if the source code files are different, acquiring a first source code which is different from the original source code file in the source code file; the method comprises the steps of matching a first source code with a pre-established vulnerability repair characteristic model, determining the mode of a vulnerability repaired by the first source code, starting from an applied source code file, finding out a changed first source code by comparing the source code file with a stored original source code, and further matching the vulnerability repaired by the first source code according to the vulnerability repair characteristic model, so that the purpose of accurately analyzing the vulnerability repair position, type and parameters is achieved, the technical effect of improving the application safety is achieved, and the technical problem that in the prior art, the vulnerability analysis is carried out due to the fact that the vulnerability position and the repaired vulnerability parameters cannot be effectively identified, and more manpower is consumed is solved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a block diagram of a hardware structure of a computer terminal running a vulnerability detection method according to an embodiment of the present application;
fig. 2 is a schematic flowchart of a vulnerability detection method according to an embodiment of the present application;
fig. 3 is a schematic flowchart of another alternative vulnerability detection method according to an embodiment of the present application;
fig. 4 is a block diagram of a vulnerability detection apparatus according to an embodiment of the present application;
FIG. 5 is a block diagram of an alternative determining unit according to an embodiment of the present application;
FIG. 6 is a block diagram of an alternative first obtaining unit according to an embodiment of the present application;
FIG. 7 is a block diagram of an alternative second obtaining unit according to an embodiment of the present application; and
fig. 8 is a block diagram of another alternative vulnerability detection apparatus according to an embodiment of the present application.
Detailed Description
In order to make the technical solutions better understood by those skilled in the art, 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 partial embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
Example 1
According to an embodiment of the present application, there is also provided a method embodiment of a vulnerability detection method, it should be noted that the steps shown in the flowchart of the figure may be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in an order different from that here.
The method provided by the first embodiment of the present application may be executed in a mobile terminal, a computer terminal, or a similar computing device. Taking an example of running on a computer terminal, fig. 1 is a hardware structure block diagram of a computer terminal of a vulnerability detection method according to an embodiment of the present application. As shown in fig. 1, the computer terminal 10 may include one or more (only one shown) processors 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. It will be understood by those skilled in the art that the structure shown in fig. 1 is only an illustration and is not intended to limit the structure of the electronic device. For example, the computer terminal 10 may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.
The memory 104 may be configured to store software programs and modules of application software, such as program instructions/modules corresponding to the vulnerability detection method in the embodiment of the present application, and the processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, so as to implement the vulnerability detection method of the application software. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The transmission device 106 is used for receiving or transmitting data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network adapter (NIC) that can be connected to other Network devices through a base station to communicate with the internet. In one example, the transmission device 106 can be a Radio Frequency (RF) module, which is used to communicate with the internet in a wireless manner.
Under the operating environment, the application provides a vulnerability detection method as shown in fig. 2. Fig. 2 is a flowchart of a vulnerability detection method according to a first embodiment of the present application.
Step S202, a source code file of the target application is obtained, wherein the source code file contains identification information of the target application.
In step S202 of the present application, the source code file refers to a set of source codes, where the source codes are a group of characters having a specific meaning and capable of implementing a specific function, and the identification information may be a name of the target application, which is not limited in this embodiment.
Optionally, in step S202, the method for obtaining the source code file of the target application may include: crawling a download address of a target application; resolving URL (Uniform Resource Locator) of the target application from the download address; and downloading the source code file according to the URL.
Specifically, a download address of the target application is crawled periodically, a URL of the target application is resolved from the download address, and the URL is written into a database for subsequent use. Moreover, the resource availability can be judged according to the URL, the influence on the performance under the condition that the resource is unavailable is eliminated, and the available resource is marked and written into the database; after the operation is completed, the source code file of the target application is crawled according to the URL.
Step S204, whether the identification information is stored in the database or not is searched, and the original source code file corresponding to the identification information is extracted from the database under the condition that the identification information is stored in the database.
In step S204, determining whether the identification information is already stored in the database, if not, creating a new file and a new directory, and recording a Hash (Hash) value of the source code file; if the Hash value is already stored in the database and the Hash value is already recorded, step S206 is executed.
It should be noted that the database includes source code files of each application that are crawled regularly, and records Hash values, version numbers, names, and the like of the corresponding source code files.
Taking the Hash value, version number and name of the source code file contained in the database as an example, the specific contents are shown in table 1:
TABLE 1
Step S206, determine whether the source code file is the same as the original source code file.
In step S206, if the identification information is stored in the database, the original source code file corresponding to the identification information is extracted from the database, and it is further determined whether the source code file is the same as the original source code file, and if not, it is determined that the file has changed. Optionally, the determining whether the source code file is the same as the original source code file includes:
and step S10, reading the Hash value in the source code file and the Hash value in the original source code file.
Taking the target application as the panning point as an example, assuming that the Hash value of the source code file of the panning point is value5, the Hash value of the original source code file C of the panning point read from the database (as shown in table 1) is value 3.
Step S12, determine whether the Hash value in the source code file is the same as the Hash value in the original source code file.
Still taking the target application as an example of the panning point, compare whether value5 is the same as value 3.
Step S14, if the Hash value in the source code file is the same as the Hash value in the original source code file, the source code file is the same as the original source code file; and if the Hash value in the source code file is different from the Hash value in the original source code file, the source code file is different from the original source code file.
Taking the target application as an panning point as an example, if value5 is different from value3, it indicates that the source code file of the panning point is different from the original source code file of the panning point stored in the database, and if value5 is the same as value3, it indicates that the source code file of the panning point is the same as the original source code file of the panning point stored in the database.
In steps S10 to S14, it can be determined whether the source code file is the same as the original source code file by determining whether the Hash value is the same. The source code file and the original source code file both contain corresponding Hash values, and if the Hash values need to be judged to be the same, the Hash values of the source code file need to be read from the source code file and the Hash values of the original source code file need to be read from the original source code file.
Judging whether the Hash value in the source code file is the same as the Hash value in the original source code file or not, and if the Hash value in the source code file is the same as the Hash value in the original source code file, indicating that the source code file is the same as the original source code file; if the Hash value in the source code file is different from the Hash value in the original source code file, the source code file is different from the original source code file, and the file change condition exists.
In step S208, if the source code file is different from the original source code file, a first source code different from the original source code file is obtained.
In step S208, when the source code file is different from the original source code file, the vulnerability detection method of this embodiment needs to locate the specific location where the change occurs, and determine which source codes in the source code file have changed. Optionally, acquiring the first source code in the source code file, which is different from the original source code file, includes steps S20 to S22.
In step S20, the source code file and the original source code file are decompressed respectively.
In step S20, if the source code file is different from the original source code file, it indicates that the source code file and the original source code file are different versions of the same application (i.e., different versions of the target application), and in order to accurately analyze the bug fix location, type, and parameters, the source code file and the original source code file need to be decompressed first.
Step S22, traverse the decompressed source code file and the decompressed original source code file, compare whether each subfile in the decompressed source code file is the same as each subfile in the decompressed original source code file, to obtain the first source code and record the line number of the first source code.
In step S22, after the decompression is completed, comparing whether each subfile in the decompressed source file is the same as each subfile in the decompressed original source file with respect to the traversed and decompressed source file, comparing the change of each file to obtain the first source code, and recording the line number, content, and the like of the change.
Further, the first source code which changes is stored in a database, an original source code file is backed up, the original source code file is covered by the source code file, and the next crawling is waited.
Step S210, matching the first source code with a pre-established vulnerability repair characteristic model, and determining the vulnerability repaired by the first source code.
In step S210 of the present application, when a difference between a source code file and an original source code file is compared, a vulnerability repair feature model is established according to a vulnerability library generated in advance for different development languages, where the vulnerability repair feature model includes: the method comprises the steps of SQL (Structured Query Language) injection, any code execution, variable coverage, file inclusion and other various vulnerability repair files, analyzing a first source code to a character string, judging whether the first source code is added with functions, assignments and other operations, matching the first source code with a vulnerability repair characteristic model, accurately identifying the vulnerability repaired by the first source code, and specifically identifying the position, type and parameters of the repaired vulnerability.
Optionally, the vulnerability repair feature model includes at least one vulnerability repair file, and the vulnerability repair file is at least used for repairing one or more of the following vulnerabilities: SQL injection, arbitrary source code execution, variable overrides, and file containment.
According to the scheme provided by the first embodiment of the application, starting from the source code file of the application, the first source code which changes is found out by comparing the source code file with the stored original source code, and then the bug repaired by the first source code is matched according to the bug repairing characteristic model, so that the purpose of accurately analyzing the location, type and parameters of bug repairing is achieved, the technical effect of improving the application security is achieved, and the technical problem that the prior art cannot effectively identify the location and repaired bug parameters, so that more manpower is consumed for analyzing the bug is solved.
Optionally, as shown in fig. 3, after determining whether the source code file is the same as the original source code file, the method further includes:
step S302, if the source code files are different, a second source code which is different from the source code file in the original source code file is obtained.
In step S302, in the case that the source code file is different from the original source code file, the vulnerability detection method of this embodiment may further find out a second source code in the original source code file, which is different from the source code file.
Step S304, the first source code and the second source code are respectively matched with a pre-established backdoor feature library, and whether the first source code and the second source code are maliciously implanted into a backdoor is determined.
In step S304, it is determined whether the first source code and the second source code are maliciously implanted into the backdoor by matching the first source code with the backdoor feature library and matching the second source code with the backdoor feature library. Here, the back door is a method of obtaining access to a program or a system by bypassing security control.
Further, by traversing the first source code and the second source code, for example traversing: php (Hypertext Preprocessor), c, asp (Active Server Page), aspx (class library for developing web application), java, ruby (scripting language), python (a surface object, interpreted computer programming language) and other files which can be compiled or interpreted, and whether the source code file adopts addition, deletion or modification operation relative to the original source code file is judged through a sequence match library of difflib.
Therefore, the problem that the application program safety is low due to the fact that the position of the bug cannot be effectively identified and the repaired bug parameters in the prior art is solved.
It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.
Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method of the embodiments of the present application.
Example 2
According to the embodiment of the present application, there is also provided an embodiment of an apparatus for implementing the above method embodiment, where the apparatus provided by the above embodiment of the present application can be run on a computer terminal.
Fig. 4 is a schematic structural diagram of a vulnerability detection apparatus according to an embodiment of the present application.
As shown in fig. 4, the vulnerability detection apparatus may include a first obtaining unit 402, a searching unit 404, a determining unit 406, a second obtaining unit 408 and a detecting unit 410.
The first obtaining unit 402 is configured to obtain a source code file of a target application, where the source code file includes identification information of the target application; a searching unit 404, configured to search whether the identification information has been stored in the database, and extract an original source code file corresponding to the identification information from the database in the case that the identification information has been stored in the database; a determining unit 406, configured to determine whether the source code file is the same as the original source code file; a second obtaining unit 408, configured to obtain, if the source code files are different, a first source code in the source code file that is different from the original source code file; the detecting unit 410 is configured to match the first source code with a pre-established vulnerability fixing feature model, and determine a vulnerability fixed by the first source code.
It can be seen from the above that, in the second embodiment of the present application, by starting from the source code file of the application, the first source code that changes is found out by comparing the source code file with the stored original source code, and then the bug repaired by the first source code is matched according to the bug repair feature model, so as to achieve the purpose of accurately analyzing the location, type and parameters of the bug repair, thereby achieving the technical effect of improving the application security, and further solving the technical problem that the prior art cannot effectively identify the location of the bug and the repaired bug parameters, which requires more manpower to analyze the bug.
It should be noted here that the first obtaining unit 402, the searching unit 404, the judging unit 406, the second obtaining unit 408 and the detecting unit 410 correspond to steps S202 to S210 in the first embodiment, and the five modules are the same as the corresponding steps in the implementation example and application scenario, but are not limited to the disclosure in the first embodiment. It should be noted that the modules described above as a part of the apparatus may be run in the computer terminal 10 provided in the first embodiment, and may be implemented by software or hardware.
Optionally, the second obtaining unit 408 is further configured to obtain, if the source code files are different from each other, a second source code in the original source code file, where the second source code is different from the source code file; the detecting unit 410 is further configured to match the first source code and the second source code with a pre-established backdoor feature library, respectively, and determine whether the first source code and the second source code are maliciously implanted into a backdoor.
Alternatively, as shown in fig. 5, the judging unit 406 includes: a reading module 502 and a judging module 504.
The reading module 502 is configured to read a Hash value in the source code file and a Hash value in the original source code file; a judging module 504, configured to judge whether a Hash value in the source code file is the same as a Hash value in the original source code file; if the Hash value in the source code file is the same as the Hash value in the original source code file, the source code file is the same as the original source code file; and if the Hash value in the source code file is different from the Hash value in the original source code file, the source code file is different from the original source code file.
It should be noted here that the reading module 502 and the determining module 504 correspond to steps S10 to S14 in the first embodiment, and the two modules are the same as the corresponding steps in the implementation example and the application scenario, but are not limited to the disclosure of the first embodiment. It should be noted that the modules described above as a part of the apparatus may be run in the computer terminal 10 provided in the first embodiment, and may be implemented by software or hardware.
Alternatively, as shown in fig. 6, the first obtaining unit 402 includes: a crawling module 602, a parsing module 604, and a downloading module 606.
The crawling module 602 is configured to crawl a download address of the target application; the parsing module 604 is configured to parse the uniform location identifier URL of the target application from the download address; and a downloading module 606, configured to download the source code file according to the URL.
Alternatively, as shown in fig. 7, the second obtaining unit 408 includes: a decompression module 702 and a traversal module 704.
The decompression module 702 is configured to decompress the source code file and the original source code file, respectively; the traversal module 704 is configured to traverse the decompressed source code file and the decompressed original source code file, compare whether each subfile in the decompressed source code file is the same as each subfile in the decompressed original source code file, to obtain the first source code, and record a line number of the first source code.
It should be noted here that the decompression module 702 and the traversal module 704 correspond to steps S20 to S22 in the first embodiment, and the two modules are the same as the corresponding steps in the example and application scenarios, but are not limited to the disclosure of the first embodiment. It should be noted that the modules described above as a part of the apparatus may be run in the computer terminal 10 provided in the first embodiment, and may be implemented by software or hardware.
Optionally, the vulnerability repair feature model includes at least one vulnerability repair file, and the vulnerability repair file is at least used for repairing one or more of the following vulnerabilities: structured Query Language (SQL) injection, arbitrary source code execution, variable coverage, and file containment.
Therefore, the problem that the application program safety is low due to the fact that the position of the bug cannot be effectively identified and the repaired bug parameters in the prior art is solved.
Example 3
According to the embodiment of the present application, there is also provided an embodiment of an apparatus for implementing the above method embodiment, where the apparatus provided by the above embodiment of the present application can be run on a computer terminal.
Fig. 8 is a schematic structural diagram of a vulnerability detection apparatus according to an embodiment of the present application.
As shown in fig. 8, the vulnerability detection apparatus may include an open source application address crawler engine 802, a resource availability analysis engine 804, a download engine 806, a file decompression engine 808, a file change analysis engine 810, and a core vulnerability analysis engine 812.
The first part is to monitor the source code change in time and analyze the bug files.
Aiming at the special conditions of file name randomization, download link randomization and the like existing in application release of a large number of internet application programs, the open-source application address crawler engine 802 regularly maintains the crawling update of each application URL pool and writes the crawling update into a database for subsequent use; the resource availability analysis engine 804 reads from a URL pool maintained by the open source application address crawler engine 802, judges the resource availability, eliminates the influence on the performance under the condition that the resource is unavailable, and marks available resources and writes the available resources into a database; after the above operations are completed, the download engine 806 crawls the source code files corresponding to the applications according to the URLs. Judging whether the source code file is stored in a file resource pool in a database or not, if not, newly building a file and a directory, and recording a Hash value of the source code file; and if the Hash value is stored in the file resource pool and recorded, judging whether the Hash value is consistent with the Hash value of the original source code file in the database. And when the two hash values are inconsistent, determining that the file change condition exists.
When the Hash value of the source code file is inconsistent with the Hash value of the original source code file, the file decompression engine 808 is started to decompress different versions (i.e., the source code file and the original source code file) of the same application. After the decompression is completed, the file change analysis engine 810 starts to work, the file change analysis engine 810 traverses the source code file and the original source code file, compares the change of each file, and records the line number, the content and the like of the change. The contents of the specific change file and the like are written into the database. And backing up the application of the old version, overwriting the application of the old version with the application of the new version, ending the analysis pool, and waiting for next crawling.
And the second part is core automatic vulnerability identification analysis and parameter positioning.
When a file discrepancy is compared, the core vulnerability analysis engine 812 is started. By traversing the first source code and the second source code, for example traversing: php, c, asp, aspx, java, ruby, python, etc. may be compiled or parsable files. And respectively matching the first source code and the second source code with a backdoor feature library, performing suspicious backdoor scanning identification, and judging whether the first source code and the second source code are maliciously implanted into a backdoor. And traversing all different rows through a sequence Matcher library of difflib, and judging whether the file is an operation of adding, deleting and modifying. And traversing the first source code by using the sequence Matcher library through the changed file. Establishing a vulnerability repair characteristic model, wherein the vulnerability repair characteristic model comprises the following steps: SQL injection, any code execution, variable coverage, file inclusion and other vulnerability repair files, then the first source code is analyzed to a character string, the fact that the first source code is added with functions, assignment and other operations compared with the second source code is judged, changed variables and the like are recorded, content change is matched with the vulnerability repair characteristic model, and vulnerabilities repaired by the second source code are accurately identified.
Through the two parts, whether the source code file and the original source code file are implanted into a backdoor or not can be accurately identified, which vulnerabilities repaired by the source code file are analyzed, and a large amount of manpower is prevented from being wasted for vulnerability analysis.
Example 4
Embodiments of the present application also provide a storage medium. Optionally, in this embodiment, the storage medium may be configured to store a program code executed by the vulnerability detection method provided in the first embodiment.
Optionally, in this embodiment, the storage medium may be located in any one of computer terminals in a computer terminal group in a computer network, or in any one of mobile terminals in a mobile terminal group.
Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: acquiring a source code file of a target application, wherein the source code file comprises identification information of the target application; searching whether the identification information is stored in a database or not, and extracting an original source code file corresponding to the identification information from the database under the condition that the identification information is stored in the database; judging whether the source code file is the same as the original source code file or not; if the source code files are different, acquiring a first source code which is different from the original source code file in the source code file; and matching the first source code with a pre-established vulnerability repair characteristic model to determine the vulnerability repaired by the first source code.
Optionally, the storage medium is further arranged to store program code for performing the steps of: if not, acquiring a second source code which is different from the source code file in the original source code file; and respectively matching the first source code and the second source code with a pre-established backdoor feature library to determine whether the first source code and the second source code are maliciously implanted into the backdoor.
Optionally, reading a Hash value in the source code file and a Hash value in the original source code file; judging whether the Hash value in the source code file is the same as the Hash value in the original source code file or not; if the Hash value in the source code file is the same as the Hash value in the original source code file, the source code file is the same as the original source code file; and if the Hash value in the source code file is different from the Hash value in the original source code file, the source code file is different from the original source code file.
Optionally, the obtaining the source code file of the target application includes: crawling a download address of a target application; resolving a uniform positioning identifier URL of the target application from the download address; and downloading the source code file according to the URL.
Optionally, the source code file and the original source code file are decompressed respectively; and traversing the decompressed source code file and the decompressed original source code file, and comparing whether each subfile in the decompressed source code file is the same as each subfile in the decompressed original source code file to obtain a first source code and record the line number of the first source code.
Optionally, in this embodiment, the storage medium may include, but is not limited to: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.
Optionally, the specific example in this embodiment may refer to the example described in embodiment 1 above, and this embodiment is not described again here.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
In the above embodiments of the present application, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
In the embodiments provided in the present application, it should be understood that the disclosed technology can be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, a division of a unit is merely a division of a logic function, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method of the embodiments of the present application. And the aforementioned storage medium includes: a U disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk, which can store program source codes.
The foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.
Claims (10)
1. A vulnerability detection method is characterized by comprising the following steps:
acquiring a source code file of a target application, wherein the source code file comprises identification information of the target application;
searching whether the identification information is stored in a database or not, and extracting an original source code file corresponding to the identification information from the database under the condition that the identification information is stored in the database;
judging whether the source code file is the same as the original source code file or not;
if the source code files are different, acquiring a first source code which is different from the original source code file in the source code file;
matching the first source code with a pre-established vulnerability repair characteristic model, and determining the repair position, the repair operation type and the parameters of the vulnerability repaired by the first source code; the vulnerability repair characteristic model comprises at least one vulnerability repair file, and the vulnerability repair file is at least used for performing vulnerability repair through one or more of the following repair operation types: structured Query Language (SQL) injection, arbitrary source code execution, variable coverage, and file containment.
2. The method of claim 1, wherein after determining whether the source code file is the same as the original source code file, the method further comprises:
if the source code files are different, second source codes which are different from the source code files in the original source code files are obtained;
and respectively matching the first source code and the second source code with a pre-established backdoor feature library to determine whether the first source code and the second source code are maliciously implanted into a backdoor.
3. The method of claim 1, wherein determining whether the source code file is the same as the original source code file comprises:
reading a Hash value in the source code file and a Hash value in the original source code file;
judging whether the Hash value in the source code file is the same as the Hash value in the original source code file or not;
if the Hash value in the source code file is the same as the Hash value in the original source code file, the source code file is the same as the original source code file;
and if the Hash value in the source code file is different from the Hash value in the original source code file, the source code file is different from the original source code file.
4. The method of claim 1, wherein obtaining the source code file of the target application comprises:
crawling a download address of the target application;
resolving a uniform positioning identifier (URL) of the target application from the download address;
and downloading the source code file according to the URL.
5. The method of claim 1, wherein obtaining a first source code in the source code file that is different from the original source code file comprises:
respectively decompressing the source code file and the original source code file;
traversing the decompressed source code file and the decompressed original source code file, and comparing whether each subfile in the decompressed source code file is the same as each subfile in the decompressed original source code file to obtain the first source code and record the line number of the first source code.
6. A vulnerability detection apparatus, comprising:
the system comprises a first acquisition unit, a second acquisition unit and a third acquisition unit, wherein the first acquisition unit is used for acquiring a source code file of a target application, and the source code file contains identification information of the target application;
the searching unit is used for searching whether the identification information is stored in a database or not, and extracting an original source code file corresponding to the identification information from the database under the condition that the identification information is stored in the database;
the judging unit is used for judging whether the source code file is the same as the original source code file or not;
a second obtaining unit, configured to obtain, if the source code files are different from each other, a first source code in the source code file that is different from the original source code file;
the detection unit is used for matching the first source code with a pre-established vulnerability repair characteristic model and determining the repair position, the repair operation type and the parameters of the vulnerability repaired by the first source code; the vulnerability repair characteristic model comprises at least one vulnerability repair file, and the vulnerability repair file is at least used for performing vulnerability repair through one or more of the following repair operation types: structured Query Language (SQL) injection, arbitrary source code execution, variable coverage, and file containment.
7. The apparatus of claim 6,
the second obtaining unit is further configured to obtain, if the source code files are different from each other, a second source code in the original source code file, which is different from the source code file;
the detection unit is further configured to match the first source code and the second source code with a pre-established backdoor feature library, respectively, and determine whether the first source code and the second source code are maliciously implanted into a backdoor.
8. The apparatus according to claim 6, wherein the judging unit includes:
the reading module is used for reading the Hash value in the source code file and the Hash value in the original source code file;
the judging module is used for judging whether the Hash value in the source code file is the same as the Hash value in the original source code file or not; if the Hash value in the source code file is the same as the Hash value in the original source code file, the source code file is the same as the original source code file; and if the Hash value in the source code file is different from the Hash value in the original source code file, the source code file is different from the original source code file.
9. The apparatus of claim 6, wherein the first obtaining unit comprises:
the crawling module is used for crawling a download address of the target application;
the analysis module is used for analyzing the uniform positioning identifier URL of the target application from the download address;
and the downloading module is used for downloading the source code file according to the URL.
10. The apparatus of claim 6, wherein the second obtaining unit comprises:
the decompression module is used for respectively decompressing the source code file and the original source code file;
and the traversal module is used for traversing the decompressed source code file and the decompressed original source code file, and comparing whether each subfile in the decompressed source code file is the same as each subfile in the decompressed original source code file to obtain the first source code and record the line number of the first source code.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510855801.0A CN106815135B (en) | 2015-11-30 | 2015-11-30 | Vulnerability detection method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510855801.0A CN106815135B (en) | 2015-11-30 | 2015-11-30 | Vulnerability detection method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106815135A CN106815135A (en) | 2017-06-09 |
| CN106815135B true CN106815135B (en) | 2021-04-06 |
Family
ID=59156512
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510855801.0A Active CN106815135B (en) | 2015-11-30 | 2015-11-30 | Vulnerability detection method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106815135B (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109214188B (en) * | 2017-06-30 | 2022-05-27 | 阿里巴巴集团控股有限公司 | Vulnerability analysis method and device and data processing method and device |
| CN109977675B (en) * | 2017-12-28 | 2022-08-16 | 超聚变数字技术有限公司 | Open source software identification method and device |
| CN108399318B (en) * | 2018-01-31 | 2020-09-08 | 北京顶象技术有限公司 | Executable file generation method, executable file execution method and electronic equipment |
| CN109684847B (en) * | 2018-09-07 | 2023-05-23 | 平安科技（深圳）有限公司 | Automatic repairing method, device, equipment and storage medium for script loopholes |
| CN109918285B (en) * | 2018-12-28 | 2022-08-09 | 奇安信科技集团股份有限公司 | Security identification method and device for open source software |
| CN109948334B (en) * | 2019-03-26 | 2024-02-23 | 深信服科技股份有限公司 | Vulnerability detection method and system, electronic equipment and storage medium |
| CN110348219A (en) * | 2019-06-13 | 2019-10-18 | 晶晨半导体(上海)股份有限公司 | Version comparison method, system, computer equipment and readable storage medium storing program for executing |
| CN111666564B (en) * | 2020-05-14 | 2024-02-02 | 平安科技（深圳）有限公司 | Application program safe starting method and device, computer equipment and storage medium |
| CN113341901B (en) * | 2021-06-25 | 2022-04-01 | 青岛沃柏斯智能实验科技有限公司 | Multi-equipment integrated control method and system based on experimental process |
| CN117235744B (en) * | 2023-11-14 | 2024-02-02 | 中关村科学城城市大脑股份有限公司 | Source file online method, device, electronic equipment and computer readable medium |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070016894A1 (en) * | 2005-07-15 | 2007-01-18 | Sreedhar Vugranam C | System and method for static analysis using fault paths |
| KR100916329B1 (en) * | 2007-11-01 | 2009-09-11 | 한국전자통신연구원 | Device and Method for Inspecting Vulnerability of Software |
| US8336034B2 (en) * | 2009-04-30 | 2012-12-18 | Nec Laboratories America, Inc. | Modular bug detection with inertial refinement |
| CN101706749B (en) * | 2009-11-18 | 2011-12-21 | 电子科技大学 | Comprehensive processing method based on software safety defect detection |
| CN103577319A (en) * | 2012-08-07 | 2014-02-12 | 腾讯科技（深圳）有限公司 | Source code file detection method, source code file detection device and file release system |
| CN104298923B (en) * | 2014-09-28 | 2018-01-02 | 北京奇虎科技有限公司 | Leak type identification method and device |
| CN104573525B (en) * | 2014-12-19 | 2017-10-31 | 中国航天科工集团第二研究院七〇六所 | A kind of specific information service software leak repair system based on white list |
| CN104699611B (en) * | 2015-03-18 | 2017-07-28 | 北京航空航天大学 | A kind of defect information extracting method that pattern is changed based on open source software defect code |
-
2015
- 2015-11-30 CN CN201510855801.0A patent/CN106815135B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN106815135A (en) | 2017-06-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106815135B (en) | Vulnerability detection method and device | |
| CN106295348B (en) | Vulnerability detection method and device for application program | |
| CN107657177B (en) | Vulnerability detection method and device | |
| KR101582601B1 (en) | Method for detecting malignant code of android by activity string analysis | |
| CN112039900B (en) | Network security risk detection method, system, computer device and storage medium | |
| CN113835713B (en) | Source code packet downloading method, device, computer equipment and storage medium | |
| CN111835756A (en) | APP privacy compliance detection method and device, computer equipment and storage medium | |
| CN107632901A (en) | A kind of self-repair method and device of application program operation exception | |
| CN114386032A (en) | Firmware detection system and method for power Internet of things equipment | |
| CN112363937A (en) | Method and device for testing differential coverage rate, computer equipment and storage medium | |
| CN115033894A (en) | Software component supply chain safety detection method and device based on knowledge graph | |
| CN104036193B (en) | Local cross-domain vulnerability detection method and device for application program | |
| CN108494728B (en) | Method, device, equipment and medium for creating blacklist library for preventing traffic hijacking | |
| CN113961936A (en) | Trusted white list construction method, system and device and computer equipment | |
| CN106529281A (en) | Executable file processing method and device | |
| CN111290747B (en) | Method, system, equipment and medium for creating function hook | |
| CN113591079B (en) | Method and device for acquiring abnormal application installation package and electronic equipment | |
| CN112579330B (en) | Processing method, device and equipment for abnormal data of operating system | |
| CN113297583B (en) | Vulnerability risk analysis method, device, equipment and storage medium | |
| CN113031995B (en) | Rule updating method and device, storage medium and electronic equipment | |
| CN114417347A (en) | Vulnerability detection method, device, equipment, storage medium and program of application program | |
| CN110377499B (en) | Method and device for testing application program | |
| CN107203706B (en) | APP internal permission detection method and device | |
| CN110704483A (en) | User routing process positioning method, device, storage medium and device | |
| CN109284609B (en) | Method and device for virus detection and computer equipment |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |