CN116415244A

CN116415244A - Project code testing method and device, storage medium and electronic device

Info

Publication number: CN116415244A
Application number: CN202310268275.2A
Authority: CN
Inventors: 林清; 张军昌; 魏东; 安童乐
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2023-03-15
Filing date: 2023-03-15
Publication date: 2023-07-11

Abstract

The application discloses a test method and device of project codes, a storage medium and an electronic device, wherein the test method comprises the following steps: importing a project file of a target project to be tested, and generating a starting command interface of the project file of the target project; carrying out static code analysis on a project file of a target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability; importing the project file of the target project into a warehouse container through a starting command interface so as to deploy a test environment of the project file of the target project; in a deployed test environment, calling an interface corresponding to each candidate vulnerability according to the request data corresponding to each candidate vulnerability to verify each candidate vulnerability, and obtaining a verification result of each candidate vulnerability.

Description

Project code testing method and device, storage medium and electronic device

Technical Field

The present invention relates to the field of software testing, and in particular, to a method and apparatus for testing project codes, a storage medium, and an electronic apparatus.

Background

At present, the code audit technology belongs to an advanced penetration test service in a white box test, and is used as an analysis method aiming at discovering security holes, program errors and source codes violating program coding specifications, so that the code audit technology is a key for ensuring network security.

In the related art, when performing code audit, a third party provided code testing tool (code audit tool) is generally used to perform static scan analysis on a source code file to determine risk points in the source code file. However, in the test mode of the project code, the test result depends on the scanning rule configured in the code test tool, the configuration of the scanning rule depends on experience of an executive, and false alarm occurs when the configuration of the scanning rule is inaccurate.

As is clear from the above, the test method of the item code in the related art has a problem of high false alarm rate of the test result due to the configuration of the scan rule based on experience.

Disclosure of Invention

The embodiment of the application provides a test method and device for item codes, a storage medium and an electronic device, which at least solve the problem of high false alarm rate of test results caused by configuration of scanning rules based on experience in the test method for the item codes in the related technology.

According to an aspect of the embodiments of the present application, there is provided a method for testing item codes, including: importing a project file of a target project to be tested, and generating a starting command interface of the project file of the target project; carrying out static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability; importing the project file of the target project into a warehouse container through the starting command interface so as to deploy a test environment of the project file of the target project; and in the deployed test environment, calling an interface corresponding to each candidate vulnerability according to the request data corresponding to each candidate vulnerability to verify each candidate vulnerability, so as to obtain a verification result of each candidate vulnerability.

According to another aspect of the embodiments of the present application, there is also provided a test device for project codes, including: the execution unit is used for importing a project file of a target project to be tested and generating a starting command interface of the project file of the target project; the first analysis unit is used for carrying out static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability; the importing unit is used for importing the project file of the target project into a warehouse container through the starting command interface so as to deploy a test environment of the project file of the target project; and the verification unit is used for verifying each candidate vulnerability according to the request data corresponding to each candidate vulnerability and calling an interface corresponding to each candidate vulnerability in the deployed test environment to obtain a verification result of each candidate vulnerability.

In an exemplary embodiment, the execution unit includes: the importing module is used for importing the project file of the target project to be tested; the identification module is used for identifying an item frame of the target item and a starting configuration item of the target item from a configuration file corresponding to the target item; the first generation module is used for generating the starting command interface of the project file of the target project according to the project framework of the target project and the starting configuration item of the target project.

In an exemplary embodiment, the first parsing unit includes: the analysis module is used for carrying out static code analysis on the project file of the target project to obtain the set of candidate vulnerabilities, and carrying out static code analysis on the project file of the target project to obtain an interface request of the project file of the target project; and the second generation module is used for generating request data corresponding to each candidate vulnerability according to the interface request corresponding to each candidate vulnerability in the interface requests of the project files of the target projects.

In one exemplary embodiment, the parsing module includes at least one of: the screening submodule is used for screening component vulnerabilities existing in a group of project components according to the component version of each project component in the group of project components of the project file of the target project to obtain a group of component vulnerabilities; the first analysis submodule is used for analyzing the parameter entering mode of each native device in the set of native devices of the project file of the target project to obtain a set of native device loopholes existing in the set of native devices; the second analysis submodule is used for analyzing the database inquiry modes in the project files of the target project and determining database inquiry mode loopholes existing in the target project to obtain a group of database inquiry mode loopholes, wherein the database inquiry mode loopholes comprise at least one of the following steps: there is a mapping relation of the injection holes, and there is a database operation statement of the injection holes.

In an exemplary embodiment, the apparatus further comprises: the second analysis unit is used for analyzing the device call links of the project files of the target project after the static code analysis is carried out on the project files of the target project to obtain the group of candidate vulnerabilities, so as to obtain a device call relation diagram corresponding to the target project; the searching unit is used for searching device call links corresponding to each candidate vulnerability in the device call relation diagram; the removing unit is used for removing the candidate loopholes with abnormal corresponding device call links from the group of candidate loopholes to obtain the updated group of candidate loopholes.

In one exemplary embodiment, the parsing module includes: the extraction submodule is used for extracting the request devices in the project file of the target project to obtain a group of request devices; an identifying sub-module, configured to identify a uniform resource identifier corresponding to each requesting device in the set of requesting devices according to architecture information of the target item and configuration information of an item root path of the target item; an updating sub-module, configured to update, when a first abnormal request device that cannot identify a corresponding uniform resource identifier exists in the group of request devices, the uniform resource identifier corresponding to the first abnormal request device; a correction sub-module, configured to correct, in a case where a second abnormal request device including a parameter of a vulnerability at an interface of a corresponding request body exists in the set of request devices, the parameter of the vulnerability at the interface of the request body of the second abnormal request device; and the generation sub-module is used for generating an interface request of the project file of the target project according to the group of request devices.

In one exemplary embodiment, the authentication unit includes: the execution module is configured to execute, in the deployed test environment, the following vulnerability verification operation with each candidate vulnerability as a current candidate vulnerability, to obtain a verification result of each candidate vulnerability, where, when the following vulnerability verification operation is executed, request data corresponding to the current candidate vulnerability is current request data, and an interface corresponding to the current candidate vulnerability is a current interface: adding a vulnerability verification script corresponding to the current candidate vulnerability to the current request data to obtain updated current request data; in the deployed test environment, calling the current interface according to the updated current request data; under the condition that the current interface returns a response result corresponding to the updated current request data, determining a verification result of the current candidate vulnerability according to the response result returned by the current interface, wherein the verification result of the current candidate vulnerability is used for indicating the availability of the current candidate vulnerability; generating a current feature library corresponding to the test environment after calling the current interface under the condition that the current interface does not return a response result corresponding to the updated current request data; and determining a verification result of the current candidate vulnerability by comparing the current feature library with a reference feature library, wherein the reference feature library is a feature library corresponding to the test environment before the current interface is called, and the verification result of the current candidate vulnerability is used for indicating the availability of the current candidate vulnerability.

According to yet another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium having a computer program stored therein, wherein the computer program is configured to execute the test method of the item code described above when running.

According to still another aspect of the embodiments of the present application, there is further provided an electronic device including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the test method of the item code by the computer program.

In the embodiment of the application, a mode of determining risk points of a project file by combining static analysis and dynamic verification is adopted, and a starting command interface of the project file of a target project to be tested is generated by importing the project file of the target project; carrying out static code analysis on a project file of a target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability; importing the project file of the target project into a warehouse container through a starting command interface so as to deploy a test environment of the project file of the target project; in a deployed test environment, each candidate vulnerability is verified according to the request data corresponding to each candidate vulnerability and the interface corresponding to each candidate vulnerability, so that a verification result of each candidate vulnerability is obtained.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the description of the embodiments or the prior art will be briefly described below, and it will be obvious to those skilled in the art that other drawings can be obtained from these drawings without inventive effort.

FIG. 1 is a schematic diagram of a hardware environment of an alternative project code testing method according to an embodiment of the present application;

FIG. 2 is a flow chart of an alternative project code testing method according to an embodiment of the present application;

FIG. 3 is a flow chart of another alternative project code testing method according to an embodiment of the present application;

FIG. 4 is a flow chart of a method of testing an alternative project code according to an embodiment of the present application;

FIG. 5 is a flow chart of a method of testing a further alternative project code according to an embodiment of the present application;

FIG. 6 is a flow chart of a method of testing a further alternative project code according to an embodiment of the present application;

FIG. 7 is a block diagram of an alternative project code testing apparatus according to an embodiment of the present application;

fig. 8 is a block diagram of an alternative electronic device according to an embodiment of the present application.

Detailed Description

In order to make the present application solution better understood by those skilled in the art, the following description will be made in detail and with reference to the accompanying drawings in the embodiments of the present application, it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, shall fall within the scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise 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.

According to one aspect of the embodiments of the present application, a method for testing project codes is provided. Alternatively, in the present embodiment, the above-described test method of item codes may be applied to a hardware environment including the terminal device 102 and the server 104 as shown in fig. 1. As shown in fig. 1, the server 104 is connected to the terminal device 102 through a network, and may be used to provide services (such as application services, etc.) to the terminal device 102 or clients installed on the terminal device, and a database may be provided on the server or independent of the server, for providing data storage services to the server 104. The terminal device 102 may be a test terminal for performing program code testing.

The network may include, but is not limited to, at least one of: wired network, wireless network. The wired network may include, but is not limited to, at least one of: a wide area network, a metropolitan area network, a local area network, and the wireless network may include, but is not limited to, at least one of: WIFI (wireless fidelity), bluetooth.

The test method of the project code in the embodiment of the present application may be executed by the server 104, may be executed by the terminal device 102, or may be executed by both the server 104 and the terminal device 102. Taking the processing method of the picture resource performed by the server 104 in this embodiment as an example, fig. 2 is a schematic flow chart of an optional testing method of the project code according to an embodiment of the present application, as shown in fig. 2, the flow of the method may include the following steps:

Step S202, importing a project file of a target project to be tested, and generating a starting command interface of the project file of the target project.

The test method of project code in the present embodiment can be applied to a scenario of inspection and analysis of security flaws in source code. The source code here may be the code of the most original program written, such as Java (an object oriented programming language) code. Inspection and analysis of security flaws in source code, i.e. code auditing, mainly checks whether there are security hazards or non-canonical encodings in the source code to reduce errors as much as possible before software release.

In the prior art, the code audit technology belongs to an advanced penetration test service in a white-box test, and mainly carries out semiautomatic audit according to a security coding specification, and most code audit tools adopt a mode of statically analyzing source code files (for example, jar (java package file format) packages, war (webappationresource, all files including Web application programs) packages or class (class file generated by compiling java source files) files. For example, as shown in fig. 3, the static code security check method encapsulates an executable program inside a CodeQL (code query language) engine, communicates with a call interface through a call module, and submits parameters in Json (javascript object notation, a lightweight data exchange format). The CodeQL engine analyzes the Json parameters to complete preliminary configuration, performs data flow analysis and stain analysis on the codes according to rules, and outputs scanning results. However, the method only uses a third-party open source tool to perfect scanning rules for codes, and relies on experience of an executive and perfection of a rule base.

In the related art, there is also a method for completing code audit by a bytecode technology, as shown in fig. 4, the method includes: scanning byte codes in a Jar packet or a War packet through an ASM (Java byte code control framework) to acquire a method calling relationship in the packet, and calling a child method by a father method; performing reverse topology sequencing on the method call relationship to generate a directed acyclic graph of the method relationship; analyzing the relation between the return value of each method and the parameters, and marking the parameters with stains; analyzing whether parameters of the child method are affected by parameters of the father method or not, and acquiring a 'stain' transfer relation; and finally searching the whole method call relation diagram according to an input entry (source) and a vulnerability method (sink) provided by a user, and finding out a method call chain from the input entry to the vulnerability method. However, when the ASM is used for analyzing the byte codes, the method only focuses on the method information, the class information and the inheritance information, does not focus on the configuration file of the item, and ignores the risk points where the configuration can occur.

The existing audit mode is limited in that whether the vulnerability can be utilized cannot be independently verified, the dependence on manpower is strong, errors are easy to generate in estimating the vulnerability risk value, and therefore the false alarm rate of the audit result is high and the accuracy is low. In addition, in the prior art, the auditing work on related projects is not comprehensive enough, so that determined risk points are not accurate enough.

In order to at least partially solve the technical problems, static analysis can be performed on source codes and configurations of the whole item, and vulnerability availability is dynamically verified in a constructed warehouse container after the static analysis is completed, so that comprehensive analysis and verification of risk points of the whole item are realized, and false alarm rate of test results is reduced.

In this embodiment, for a target item that needs code audit, a project file of the target item to be tested may be imported in the analysis device, and a start command interface of the project file of the target item may be generated. Here, the start command interface of the project file of the target project may be used to transmit the analysis result of the static analysis to the warehouse container for dynamic verification.

Alternatively, a code receiving module may be provided in the analysis device for manual introduction of the project file by the user. The above-mentioned manner of importing the project file of the target project to be tested may be manually imported by the user. The project files of the target project may include, but are not limited to, jar, war, and compression packages, and Web profiles of the project files, such as Web xml, pon xml, and the like.

Step S204, performing static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability.

For the imported project file, in this embodiment, static code analysis may be performed on the project file of the target project to obtain a set of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the set of candidate vulnerabilities. Here, the request data corresponding to each candidate vulnerability may be used to verify each candidate vulnerability by invoking an interface corresponding to each candidate vulnerability. Here, the candidate vulnerability may be any vulnerability obtained by performing static analysis on the project file of the target project, or may be a vulnerability that satisfies a preset condition, for example, a vulnerability that cannot be determined whether to be available, or may be a condition that needs to be satisfied by other preconfigured vulnerabilities to be verified.

Alternatively, the above-described static code parsing may be performed by an analysis module in the analysis apparatus. The set of candidate vulnerabilities may include a plurality of different types of vulnerabilities, such as component vulnerabilities, native method vulnerabilities, injection vulnerabilities, and the like. Here, the native method vulnerability may be a vulnerability caused by misuse of an existing method of an authority, and the injection vulnerability may be a vulnerability that an attacker may find an injection point by constructing a malicious sentence and destroy a target according to the injection point for a breach, and may include, but is not limited to, an SQL (StructuredQuery Language, a database language) injection vulnerability.

Step S206, importing the project file of the target project into the warehouse container through the start command interface to deploy the test environment of the project file of the target project.

After generating the start command interface of the project file of the target project, the project file of the target project can be imported into the warehouse container through the start command interface to deploy the test environment of the project file of the target project. Here, the test environment of the project file of the target project may be an environment for performing dynamic verification of candidate vulnerabilities of the project file. Here, the test environment of the project file of the deployment target project may be a process performed before, after, or a set of candidate vulnerabilities are determined, which is not limited in this embodiment.

Optionally, the warehouse container may be constructed according to a file type of a project file of the target project, so as to ensure that a testing environment of the constructed warehouse container can normally perform dynamic verification of candidate vulnerabilities of the target file. By the method for automatically deploying the test environment, the code auditing time can be effectively saved.

Step S208, in the deployed test environment, calling an interface corresponding to each candidate vulnerability according to the request data corresponding to each candidate vulnerability to verify each candidate vulnerability, thereby obtaining a verification result of each candidate vulnerability.

When a group of candidate vulnerabilities are dynamically verified, an interface corresponding to each candidate vulnerability is called according to request data corresponding to each candidate vulnerability in a deployed test environment to verify each candidate vulnerability, so that a verification result of each candidate vulnerability is obtained.

Optionally, before dynamic verification is performed, request data related to the determined candidate vulnerability and the project file of the target project and corresponding to the candidate vulnerability may be imported into a warehouse container, so as to complete verification of the candidate vulnerability.

Optionally, when verifying the candidate vulnerability, a verification script determined according to the candidate vulnerability may be added to the corresponding request data, a corresponding request is completed in the test environment by using a test tool, and whether the candidate vulnerability exists is determined according to a result of a request response or a change of the test environment after the request is completed.

Through the steps, importing a project file of a target project to be tested, and generating a starting command interface of the project file of the target project; carrying out static code analysis on a project file of a target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability; importing the project file of the target project into a warehouse container through a starting command interface so as to deploy a test environment of the project file of the target project; in a deployed test environment, each candidate vulnerability is verified by calling an interface corresponding to each candidate vulnerability according to request data corresponding to each candidate vulnerability, so that a verification result of each candidate vulnerability is obtained, the problem that the test method of the project code in the related technology has high false alarm rate of the test result caused by configuration based on experience of a scanning rule is solved, the false alarm rate of the test result is reduced, and the accuracy of code audit is improved.

In one exemplary embodiment, a start command interface for importing a project file of a target project to be tested and generating the project file of the target project includes:

s11, importing a project file of a target project to be tested;

s12, identifying an item frame of the target item and a starting configuration item of the target item from a configuration file corresponding to the target item;

s13, generating a starting command interface of the project file of the target project according to the project framework of the target project and the starting configuration item of the target project.

Because the configuration files generally store environment settings required for starting the project, the identification of the relevant frames and the starting of the configuration items can be performed according to the writing specification rules of the configuration files corresponding to the project files of the target project. In this embodiment, when generating the start command interface of the project file of the target project, the project file of the target project to be tested may be imported, and the project frame of the target project and the start configuration item of the target project may be identified from the configuration file corresponding to the target project. Here, the profile may be a type of file such as web.

In this embodiment, after identifying the project frame of the target project and the start configuration item of the target project, the start command interface of the project file of the target project may be generated according to the project frame and the start configuration item.

Alternatively, importing the project file of the target project into the warehouse container may refer to importing the architecture, startup parameters, dependencies, SQL, etc. of the project into the warehouse container. Correspondingly, the generated starting command interface of the project file of the target project can comprise the architecture, the dependence, SQL, the starting parameters and the like of the project.

For example, importing project files including, but not limited to, jar, war and compressed package, identifying a framework and a start configuration item according to the writing specification rules of a Web (World Wide Web) configuration file (such as Web. Xml, pon. Xml), reserving a project start command interface I1, wherein I1 comprises the architecture, dependency, SQL, start parameters and the like of the project.

According to the method and the device, the project framework and the starting configuration item are determined according to the configuration file corresponding to the target project, so that a starting command interface of the project file of the target project is generated, and the comprehensiveness of code audit of the project file can be improved.

In one exemplary embodiment, static code parsing is performed on a project file of a target project to obtain a set of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the set of candidate vulnerabilities, including:

S21, carrying out static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities, and carrying out static code analysis on the project file of the target project to obtain an interface request of the project file of the target project;

s22, according to the interface request corresponding to each candidate vulnerability in the interface requests of the project files of the target projects, request data corresponding to each candidate vulnerability is generated.

For a set of candidate vulnerabilities of a project file of a target project and request data corresponding to each candidate vulnerability in the set of candidate vulnerabilities, in this embodiment, the set of candidate vulnerabilities of the project file of the target project and the interface request in the project file of the target project may be determined by performing static code analysis on the project file of the target project.

Alternatively, the interface request of the project file of the target project obtained by performing static code analysis on the project file of the target project may be all interface requests related to the project file of the target project.

Because the request data in this embodiment is mainly used for verifying candidate vulnerabilities, in this embodiment, the request data corresponding to each candidate vulnerability may be generated according to an interface request corresponding to each candidate vulnerability in the interface requests of the project file of the target project.

Optionally, the interface request corresponding to each candidate vulnerability in the set of candidate vulnerabilities may be screened from all interface requests related to the project file of the target project, and then the request data may be generated.

According to the method and the device for verifying the candidate vulnerabilities, the candidate vulnerabilities and the request data are determined from the project files in the static analysis process, so that the accuracy and the efficiency of the follow-up verification of the candidate vulnerabilities can be improved.

In one exemplary embodiment, static code parsing is performed on a project file of a target project to obtain a set of candidate vulnerabilities, including at least one of:

s31, screening component vulnerabilities existing in a group of project components according to the component version of each project component in the group of project components of the project file of the target project to obtain a group of component vulnerabilities;

s32, analyzing the parameter entering mode of each native method in a set of native methods of the project file of the target project to obtain a set of native method vulnerabilities existing in the set of native methods;

s33, analyzing a database query mode in a project file of the target project, and determining database query mode loopholes existing in the target project to obtain a group of database query mode loopholes, wherein the database query mode loopholes comprise at least one of the following: there is a mapping relation of the injection holes, and there is a database operation statement of the injection holes.

Since many different types of loopholes may exist in the project file of the target project, in order to improve the comprehensiveness and accuracy of the risk point analysis of the project file, the loopholes which may exist in the project file of the target project may be analyzed from different angles.

In this embodiment, component vulnerabilities existing in a group of item components may be screened according to a component version of each item component in the group of item components of the item file of the target item, to obtain a group of component vulnerabilities.

Alternatively, since the lib (library) directory is a shared library required by the program on the root filesystem, which stores shared files required by the root filesystem program to run, when each item component in a set of item components of the item file of the target item is determined, all item components can be determined directly from the information under the lib directory in the item file.

Optionally, the component vulnerability may be screened by forming a version list of the component version of each item component in the set of item components, importing the version list into an existing vulnerability library, and comparing the version list with the generated version list to screen out the component vulnerability.

For example, analyzing all the dependent and component versions under the lib directory in the Jar/War/compressed package to form a version list, importing the latest CVE (CommonVulnerailites & Exposures, common vulnerability disclosure)/CNVD (China national VulnerailyDatabase, national information security vulnerability sharing platform)/CNNVD (China national VulnerailyDataBaseInformationSecurity) vulnerability library, comparing the version list generated by the items, screening the components with vulnerabilities and recording.

In this embodiment, the parameter entering mode of each native method in the set of native methods of the project file of the target project may be analyzed to obtain a set of native method vulnerabilities existing in the set of native methods. Here, the native method is a method implemented in a language other than Java, that is, a foreign method. The native methods involved in this embodiment may be some common native methods, and may include, but are not limited to, run time ()/ProcessBuilder etc. for executing system commands, reverse serialization operations readObject/partusobject etc., newFile ()/unzip/FileInputStream/FileOutputStream etc. for file operations, and newURL ()/rettemplate () for URL (Uniform ResourceLocator) jumps, etc.

In this embodiment, the database query mode in the project file of the target project may be analyzed, so as to determine the database query mode loopholes existing in the target project, and obtain a set of database query mode loopholes. Here, the database query pattern vulnerability may include at least one of: there is a mapping relation of the injection holes, and there is a database operation statement of the injection holes.

Optionally, when parsing the database query manner, it may be determined whether an ORM (object relational mapping) framework is used according to the features of the project file. Since the ORM framework uses metadata to describe the details of the object and relationship mapping, and the metadata is typically in XML format, when determined to be the ORM framework, the SQL statement may be extracted by identifying the XML node ID value. If the object file is not an ORM framework, it can be determined that the object file uses a native JDBC (JavaDataBase Connectivity, java language connection database) database, and then possible vulnerabilities can be determined by analyzing a field splicing mode and a parameter entering mode.

For example, whether the project file uses the current mainstream ORM framework, such as Hibernate, myBatis, myBatis-Plus, can be judged according to the characteristics, if yes, the XML node ID value is identified, if the model is the native JDBC, the field splicing mode and the parameter entering mode are analyzed, and therefore the mapping relation or SQL statement of the suspected SQL injection loophole in the project file is determined.

Alternatively, for the persistence of the set of component vulnerabilities described above, a component vulnerability base L1 may be generated. Correspondingly, a set of native method vulnerabilities can be generated into a native method vulnerability base L2, and a set of database query mode vulnerabilities SQL vulnerability base L3.

According to the method and the device, candidate vulnerabilities of the project file are determined through different angles and methods, so that more comprehensive audit of the project file can be ensured, and the safety of the project file is improved.

In an exemplary embodiment, after performing static code parsing on the project file of the target project to obtain a set of candidate vulnerabilities, the method further includes:

s41, analyzing a method call link of a project file of a target project to obtain a method call relation diagram corresponding to the target project;

s42, searching a method call link corresponding to each candidate vulnerability in the method call relation diagram;

S43, removing the candidate loopholes with abnormal corresponding method call links from the candidate loopholes to obtain an updated candidate loopholes.

After the candidate loopholes of the project files of the target project are determined through static analysis, the method call links of the project files of the target project can be analyzed, and according to the result of determining the candidate loopholes, the method call relations are traversed reversely to find out the reasons of the loopholes, and further the authenticity of the candidate loopholes is determined.

In this embodiment, the method call link of the project file of the target project may be parsed to obtain the method call relationship diagram corresponding to the target project.

Optionally, when parsing the method call link, all method information, class information, inheritance information, reload/rewrite information, interface class implementation information and the like obtained in the byte code can be analyzed to determine the call and called relationship between the methods, thereby forming a method call relationship graph.

In this embodiment, a method call link corresponding to each candidate vulnerability may be found in the method call relationship graph, and candidate vulnerabilities with anomalies in the corresponding method call links are removed from a set of candidate vulnerabilities, so as to obtain an updated set of candidate vulnerabilities. Here, for the candidate vulnerability corresponding to the abnormal method call link, it can be determined to be a true vulnerability without subsequent dynamic verification.

Alternatively, for a method call link in which an exception exists, and its corresponding candidate vulnerability, a pollution chain base L4 may be generated.

According to the method and the device for determining the availability and the existence reasons of the part of candidate vulnerabilities, the availability and the existence reasons of the part of candidate vulnerabilities can be rapidly determined by analyzing the method call links of the project files, so that the efficiency of code audit is improved.

In one exemplary embodiment, performing static code parsing on a project file of a target project to obtain an interface request of the project file of the target project, including:

s51, extracting a request method in a project file of a target project to obtain a group of request methods;

s52, identifying a uniform resource identifier corresponding to each request method in a group of request methods according to the architecture information of the target item and the configuration information of the item root path of the target item;

s53, when a first abnormal request method which cannot identify the corresponding uniform resource identifier exists in a group of request methods, updating the uniform resource identifier corresponding to the first abnormal request method;

s54, under the condition that a second abnormal request method containing the parameters of the loopholes at the interfaces of the corresponding request bodies exists in the group of request methods, correcting the parameters of the loopholes at the interfaces of the request bodies of the second abnormal request method;

S55, generating an interface request of the project file of the target project according to a group of request methods.

In order to avoid errors in verification of candidate vulnerabilities caused by abnormal conditions such as logic errors in interface requests in project files, in this embodiment, when the project files of the target project are statically analyzed, the request method, the requested uniform resource identifier and the request body in the project files of the target project can be analyzed, and when the abnormal conditions are determined, the abnormal conditions can be corrected in time.

In this embodiment, a request method in a project file of a target project may be extracted to obtain a set of request methods, and a uniform resource identifier corresponding to each request method in the set of request methods is identified according to architecture information of the target project and configuration information of a project root path of the target project.

Optionally, for the determined uniform resource identifier URI (UniformResourceIdentifier), the uniform resource identifier may be analyzed according to the architecture information and the project root path configuration information in the aforementioned start command interface, and the accuracy of the subset URL of the URI may be detected to determine whether there is an anomaly.

In the case where there is a first abnormal request method in which the corresponding uniform resource identifier cannot be identified in the set of request methods, the uniform resource identifier corresponding to the first abnormal request method may be updated. Here, the updating of the uniform resource identifier corresponding to the first exception request method may be modified by manual intervention.

And under the condition that a second abnormal request method containing the parameters of the loopholes at the interfaces of the corresponding request bodies exists in the group of request methods, correcting the parameters of the loopholes at the interfaces of the request bodies of the second abnormal request method.

Alternatively, the analysis of the request body described above may be to analyze code logic and the entry format at the request body interface to determine if a parameter is missing or a vulnerability exists.

In this embodiment, after updating and correcting all the cases where there is an abnormality, an interface request of the project file of the target project may be generated according to a set of request methods.

For example, analyzing a request method, such as POST/GET/PUT/DELETE (request mode), analyzing the URI of the current method according to the architecture information and the project root path configuration information in I1, detecting the accuracy of the URL, and providing manual intervention modification for the unrecognized URI; analyzing code logic at the interface, analyzing the Content-Type of the input format, adding parameters which are necessary to exist in judgment or annotation, adding parameters with loopholes, and generating a complete HTTP request according to the updated result. In addition, the packet base L5 may be generated according to all the determined interface requests.

By analyzing and correcting the interface request, the embodiment can avoid influencing the implementation of verification of candidate vulnerabilities, thereby improving the accuracy of vulnerability identification.

In an exemplary embodiment, in a deployed test environment, according to request data corresponding to each candidate vulnerability, invoking an interface corresponding to each candidate vulnerability to verify each candidate vulnerability, so as to obtain a verification result of each candidate vulnerability, including:

s61, in a deployed test environment, taking each candidate vulnerability as a current candidate vulnerability to execute the following vulnerability verification operation to obtain a verification result of each candidate vulnerability, wherein when the following vulnerability verification operation is executed, the request data corresponding to the current candidate vulnerability is current request data, and the interface corresponding to the current candidate vulnerability is a current interface:

adding the vulnerability verification script corresponding to the current candidate vulnerability into the current request data to obtain updated current request data;

in a deployed test environment, calling a current interface according to updated current request data;

under the condition that the current interface returns a response result corresponding to the updated current request data, determining a verification result of the current candidate vulnerability according to the response result returned by the current interface, wherein the verification result of the current candidate vulnerability is used for indicating the availability of the current candidate vulnerability;

Under the condition that the current interface does not return a response result corresponding to the updated current request data, generating a current feature library corresponding to the test environment after the current interface is called; and determining a verification result of the current candidate vulnerability by comparing the current feature library with a reference feature library, wherein the reference feature library is a feature library corresponding to a test environment before the current interface is called, and the verification result of the current candidate vulnerability is used for indicating the availability of the current candidate vulnerability.

For each candidate vulnerability of a group of candidate vulnerabilities, performing vulnerability verification operation by taking each candidate vulnerability as a current candidate vulnerability in a deployed test environment to obtain a verification result of each candidate vulnerability. In the vulnerability verification operation, the request data corresponding to the current candidate vulnerability may be the current request data, and the interface corresponding to the current candidate vulnerability may be the current interface.

The vulnerability verification operation may be: adding the vulnerability verification script corresponding to the current candidate vulnerability into the current request data to obtain updated current request data; in a deployed test environment, calling a current interface according to updated current request data; and under the condition that the current interface returns a response result corresponding to the updated current request data, determining a verification result of the current candidate vulnerability according to the response result returned by the current interface. Here, the verification result of the current candidate vulnerability may be used to indicate availability of the current candidate vulnerability.

Optionally, the vulnerability verification script corresponding to the current candidate vulnerability may be a vulnerability verification script that is included in a evidence library after PoC (profofconcept, providing evidence for views, that is, a sentence or a string of codes or scripts that can trigger the vulnerability and verify the existence of the vulnerability, etc.) is generated according to the generated L1, L2, L3, and L4, and then the evidence library L0 is verified.

Under the condition that the current interface does not return a response result corresponding to the updated current request data, generating a current feature library corresponding to the test environment after the current interface is called; and determining the verification result of the current candidate vulnerability by comparing the current feature library with the reference feature library. Here, the reference feature library may be a feature library corresponding to a test environment before the current interface is invoked, and the verification result of the current candidate vulnerability may be used to indicate availability of the current candidate vulnerability.

Alternatively, the reference feature library may be a feature library generated by analyzing the container environment of the current warehouse container after constructing the warehouse container, importing related data in the start command interface, and verifying that the project is complete. The reference feature library and the current feature library may each include the number of files under the website root directory, file attributes, and file MD5 (Message-DigestAlgorithm 5, a cryptographic hash function) values, etc.

Optionally, after importing the relevant data in the start command interface in the warehouse container, the project may be started to verify the integrity of the project operation, thereby implementing analysis of risk points of the configuration file of the target project file.

Optionally, before adding the vulnerability verification script corresponding to the current candidate vulnerability to the current request data, the method further comprises: in a deployed test environment, the current interface is called according to the current request data to verify whether the current interface responds normally or not, and verification of the current candidate vulnerability is performed after the current interface responds normally.

For example, after the license library L0 is imported into the warehouse container, an initial analysis operation may be performed without adding the vulnerability verification script in L0, analyzing the request data in L0, completing an automatic request by using an API test tool, verifying the validity of the interface request (i.e., whether the verification interface can normally respond), adding the vulnerability verification script in L0 to the request data, and completing multiple automatic requests by using the API test tool until all vulnerability verification scripts are traversed. Judging the existence (i.e. availability) of the loopholes from the response result according to the request and response result, analyzing the container environment after the test is completed, comparing the generated feature library F2 with the feature library F1, and confirming the availability of the specific loopholes (e.g. file operation loopholes). And combining a CVSS scoring system and an availability analysis result to obtain a final code audit report.

According to the embodiment, the candidate loopholes are dynamically verified in the constructed warehouse container, so that the false alarm rate of the loopholes can be reduced, and in addition, feature contrast is introduced when the availability of the loopholes is verified, so that the evidence of the loophole verification is clearer.

The test method of the project code in the embodiment of the present application is explained below in conjunction with an alternative example. The alternative example provides a Java code auditing method and device based on static analysis and dynamic verification, which acquire risk points in configuration files and verify through analysis of various configuration files appearing in projects, and under the condition, a main stream framework can be subjected to coverage test, so that the global coverage of a code auditing range is realized. Through automatic deployment test environment, the availability of dynamic verification vulnerability is realized, and the false alarm rate of static code audit can be effectively reduced. In addition, the authenticity and the legality of the vulnerability verification can be effectively improved through the feature comparison of the file systems before and after the test.

As shown in fig. 5, the auditing apparatus of the project code in this alternative example may include the following modules: the system comprises a code receiving module, a request analysis module, a vulnerability analysis module, a pollution chain analysis module, a data storage module, an execution module, a feature library module, a verification module, a scoring module and a reporting module. The code receiving module is used for manually importing project files, jar, war, compression packages and the like by a user, the request analysis module is used for analyzing a request method, a request URI, a request body and the like of an interface in a code, the vulnerability analysis module is used for analyzing a dangerous method, SQL sentences, a dependent library version and the like, the pollution chain analysis module is used for analyzing a method call link, a call relation diagram and the like, the data storage module is used for storing risk data, a final report, a license PoC and the like, the execution module comprises functions of container generation, environment construction, system function verification and the like, the feature library module is used for temporarily storing two feature values, analyzing the feature values, the verification module is used for verifying the availability of a vulnerability, the API test tool is integrated, the scoring module is used for integrating the CVSS scoring tool, the manual intervention interface is provided, and the reporting module is used for generating a code audit report. As shown in fig. 6, the flow of the test method of the project code in this alternative example may include the following steps:

Step 1, importing a project file and generating a starting command interface.

And 2, analyzing project file dependencies, threat methods, SQL sentences and the like to generate weak points into a basic library.

And 3, analyzing interfaces, request modes, URIs, request bodies and the like to generate a data packet basic library.

And 4, analyzing a method call link to generate a pollution chain base.

And 5, generating an evidence library according to the steps 2, 3 and 4.

And 6, constructing a warehouse container and deploying an operation environment.

And 7, starting the project, and verifying the operation integrity of the project.

And 8, generating a feature library according to the environment of the current container.

And 9, importing an evidence library and performing security analysis and test.

And step 10, generating a feature library according to the tested container environment, and confirming the availability of the loopholes.

And 11, combining the CVSS scoring system and the availability to provide a final risk analysis report.

By the optional example, both the source code file and the configuration file are analyzed in the code audit process, so that the range of code audit can be increased. In addition, the availability of the loopholes is dynamically verified through automatic deployment of a test environment, so that the false alarm rate of static code audit can be reduced.

It should be noted that, for simplicity of description, the foregoing method embodiments are all expressed as a series of action combinations, but it should be understood by those skilled in the art that the present application is not limited by the order of actions described, as some steps may be performed in other order or simultaneously in accordance with the present application. Further, those skilled in the art will also appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily required in the present application.

From the description of the above embodiments, it will be clear to a person skilled in the art that the method according to the above embodiments may be implemented by means of software plus the necessary general hardware platform, but of course also by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as a ROM (Read-only memory)/RAM (random access memory), a magnetic disk, an optical disc), including several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method of the embodiments of the present application.

According to another aspect of the embodiments of the present application, there is also provided a test apparatus for item codes for implementing the test method for item codes described above. FIG. 7 is a block diagram of an alternative project code testing apparatus, as shown in FIG. 7, according to an embodiment of the present application, which may include:

the execution unit 702 is used for importing a project file of a target project to be tested and generating a starting command interface of the project file of the target project;

The first parsing unit 704, coupled to the executing unit 702, is configured to perform static code parsing on a project file of a target project to obtain a set of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the set of candidate vulnerabilities, where the request data corresponding to each candidate vulnerability is used to verify each candidate vulnerability by calling an interface corresponding to each candidate vulnerability;

an importing unit 706, connected to the first parsing unit 704, for importing, by activating a command interface, the project file of the target project into the warehouse container, so as to deploy a test environment of the project file of the target project;

and the verification unit 708 is connected with the importing unit 706, and is configured to invoke an interface corresponding to each candidate vulnerability according to the request data corresponding to each candidate vulnerability in the deployed test environment to verify each candidate vulnerability, so as to obtain a verification result of each candidate vulnerability.

It should be noted that, the executing unit 702 in this embodiment may be configured to execute the above-mentioned step S202, the first parsing unit 704 in this embodiment may be configured to execute the above-mentioned step S204, the importing unit 706 in this embodiment may be configured to execute the above-mentioned step S206, and the verifying unit 708 in this embodiment may be configured to execute the above-mentioned step S208.

The method comprises the steps of importing a project file of a target project to be tested through the module, and generating a starting command interface of the project file of the target project; carrying out static code analysis on a project file of a target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability; importing the project file of the target project into a warehouse container through a starting command interface so as to deploy a test environment of the project file of the target project; in a deployed test environment, each candidate vulnerability is verified by calling an interface corresponding to each candidate vulnerability according to request data corresponding to each candidate vulnerability, so that a verification result of each candidate vulnerability is obtained, the problem that the test method of the project code in the related technology has high false alarm rate of the test result caused by configuration based on experience of a scanning rule is solved, the false alarm rate of the test result is reduced, and the accuracy of code audit is improved.

In one exemplary embodiment, an execution unit includes:

The importing module is used for importing a project file of a target project to be tested;

the identification module is used for identifying an item frame of the target item and a starting configuration item of the target item from a configuration file corresponding to the target item;

the first generation module is used for generating a start command interface of a project file of the target project according to the project framework of the target project and the start configuration item of the target project.

In one exemplary embodiment, the first parsing unit includes:

the analysis module is used for carrying out static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities, and carrying out static code analysis on the project file of the target project to obtain an interface request of the project file of the target project;

the second generation module is used for generating request data corresponding to each candidate vulnerability according to the interface request corresponding to each candidate vulnerability in the interface requests of the project files of the target projects.

In one exemplary embodiment, the parsing module includes at least one of:

the screening sub-module is used for screening component vulnerabilities existing in a group of project components according to the component version of each project component in the group of project components of the project file of the target project to obtain a group of component vulnerabilities;

The first analysis submodule is used for analyzing the parameter entering mode of each native device in the set of native devices of the project file of the target project to obtain a set of native device loopholes existing in the set of native devices;

the second analysis submodule is used for analyzing the database query mode in the project file of the target project and determining database query mode loopholes existing in the target project to obtain a group of database query mode loopholes, wherein the database query mode loopholes comprise at least one of the following: there is a mapping relation of the injection holes, and there is a database operation statement of the injection holes.

In an exemplary embodiment, the above apparatus further includes:

the second analysis unit is used for analyzing the device call links of the project files of the target project after carrying out static code analysis on the project files of the target project to obtain a group of candidate vulnerabilities, and obtaining a device call relation diagram corresponding to the target project;

the searching unit is used for searching the device call links corresponding to each candidate vulnerability in the device call relation diagram;

the removing unit is used for removing the candidate loopholes with abnormal corresponding device call links from the group of candidate loopholes to obtain an updated group of candidate loopholes.

In one exemplary embodiment, the parsing module includes:

the extraction submodule is used for extracting the request devices in the project file of the target project to obtain a group of request devices;

an identification sub-module for identifying a uniform resource identifier corresponding to each requesting device in the set of requesting devices according to the architecture information of the target item and the configuration information of the item root path of the target item;

an updating sub-module, configured to update, when a first abnormal request device that cannot identify a corresponding uniform resource identifier exists in a group of request devices, the uniform resource identifier corresponding to the first abnormal request device;

a correction sub-module, configured to correct, when a second abnormal request device including a parameter of a leak at an interface of a corresponding request body exists in a group of request devices, the parameter of the leak at the interface of the request body of the second abnormal request device;

and the generation sub-module is used for generating an interface request of the project file of the target project according to the group of request devices.

In one exemplary embodiment, the authentication unit includes:

the execution module is used for executing the following vulnerability verification operation with each candidate vulnerability as the current candidate vulnerability in the deployed test environment to obtain a verification result of each candidate vulnerability, wherein when the following vulnerability verification operation is executed, the request data corresponding to the current candidate vulnerability is the current request data, and the interface corresponding to the current candidate vulnerability is the current interface:

It should be noted that the above modules are the same as examples and application scenarios implemented by the corresponding steps, but are not limited to what is disclosed in the above embodiments. It should be noted that the above modules may be implemented in software or in hardware as part of the apparatus shown in fig. 1, where the hardware environment includes a network environment.

According to yet another aspect of embodiments of the present application, there is also provided a storage medium. Alternatively, in the present embodiment, the above-described storage medium may be used for executing the program code of the test method of any of the above-described item codes in the embodiments of the present application.

Alternatively, in this embodiment, the storage medium may be located on at least one network device of the plurality of network devices in the network shown in the above embodiment.

Alternatively, in the present embodiment, the storage medium is configured to store program code for performing the steps of:

s1, importing a project file of a target project to be tested, and generating a starting command interface of the project file of the target project;

s2, carrying out static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability;

s3, importing the project file of the target project into a warehouse container through a starting command interface so as to deploy a test environment of the project file of the target project;

S4, in the deployed test environment, calling an interface corresponding to each candidate vulnerability according to the request data corresponding to each candidate vulnerability to verify each candidate vulnerability, and obtaining a verification result of each candidate vulnerability.

Alternatively, specific examples in the present embodiment may refer to examples described in the above embodiments, which are not described in detail in the present embodiment.

Alternatively, in the present embodiment, the storage medium may include, but is not limited to: various media capable of storing program codes, such as a U disk, ROM, RAM, a mobile hard disk, a magnetic disk or an optical disk.

According to still another aspect of the embodiments of the present application, there is also provided an electronic device for implementing the testing method of item codes described above, where the electronic device may be a server, a terminal, or a combination thereof.

Fig. 8 is a block diagram of an alternative electronic device, according to an embodiment of the present application, including a processor 802, a communication interface 804, a memory 806, and a communication bus 808, as shown in fig. 8, wherein the processor 802, the communication interface 804, and the memory 806 communicate with each other via the communication bus 808, wherein,

a memory 806 for storing a computer program;

The processor 802, when executing the computer program stored on the memory 806, performs the following steps:

Alternatively, in the present embodiment, the communication bus may be a PCI (PeripheralComponent Interconnect, peripheral component interconnect standard) bus, or an EISA (ExtendedIndustryStandard Architecture ) bus, or the like. The communication bus may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, only one thick line is shown in fig. 8, but not only one bus or one type of bus. The communication interface is used for communication between the electronic device and other equipment.

The memory may include RAM or may include non-volatile memory (non-volatile memory), such as at least one disk memory. Optionally, the memory may also be at least one memory device located remotely from the aforementioned processor.

As an example, the memory 806 may include, but is not limited to, an execution unit 702, a first parsing unit 704, an importing unit 706, and a verifying unit 708 in a test apparatus including the item code. In addition, other module units in the test device of the project code may be included, but are not limited to, and are not described in detail in this example.

The processor may be a general purpose processor and may include, but is not limited to: CPU (CentralProcessing Unit ), NP (network processor), etc.; but may also be a DSP (Digital SignalProcessing, digital signal processor), ASIC (application specific integrated circuit), FPGA (Field-programmable gate array) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components.

Alternatively, specific examples in this embodiment may refer to examples described in the foregoing embodiments, and this embodiment is not described herein.

It will be understood by those skilled in the art that the structure shown in fig. 8 is only schematic, and the device implementing the test method of the project code may be a terminal device, and the terminal device may be a smart phone (such as an Android mobile phone, an iOS mobile phone, etc.), a tablet computer, a palmtop computer, a mobile internet device (MobileInternet Devices, MID), a PAD, etc. Fig. 8 is not limited to the structure of the electronic device. For example, the electronic device may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in FIG. 8, or have a different configuration than shown in FIG. 8.

Those of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be implemented by a program for instructing a terminal device to execute in association with hardware, the program may be stored in a computer readable storage medium, and the storage medium may include: flash disk, ROM, RAM, magnetic or optical disk, etc.

The foregoing embodiment numbers of the present application are merely for describing, and do not represent advantages or disadvantages of the embodiments.

The integrated units in the above embodiments may be stored in the above-described computer-readable storage medium if implemented in the form of software functional units and sold or used as separate products. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause one or more computer devices (which may be personal computers, servers or network devices, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application.

In the foregoing embodiments of the present application, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In several embodiments provided in the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, such as the division of the units, is merely a logical function division, and may be implemented in another manner, for example, multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described as separate units may or may not be physically separate, and units shown 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 may be selected according to actual needs to achieve the purpose of the solution provided in the present embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The foregoing is merely a preferred embodiment of the present application and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present application and are intended to be comprehended within the scope of the present application.

Claims

1. A method for testing project codes, comprising:

importing a project file of a target project to be tested, and generating a starting command interface of the project file of the target project;

carrying out static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability;

Importing the project file of the target project into a warehouse container through the starting command interface so as to deploy a test environment of the project file of the target project;

and in the deployed test environment, calling an interface corresponding to each candidate vulnerability according to the request data corresponding to each candidate vulnerability to verify each candidate vulnerability, so as to obtain a verification result of each candidate vulnerability.

2. The method according to claim 1, wherein importing the project file of the target project to be tested and generating the start command interface of the project file of the target project comprises:

importing a project file of the target project to be tested;

identifying an item frame of the target item and a starting configuration item of the target item from a configuration file corresponding to the target item;

and generating the starting command interface of the project file of the target project according to the project framework of the target project and the starting configuration item of the target project.

3. The method of claim 1, wherein the performing static code parsing on the project file of the target project to obtain a set of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the set of candidate vulnerabilities comprises:

Performing static code analysis on the project file of the target project to obtain the set of candidate vulnerabilities, and performing static code analysis on the project file of the target project to obtain an interface request of the project file of the target project;

and generating request data corresponding to each candidate vulnerability according to the interface request corresponding to each candidate vulnerability in the interface requests of the project files of the target projects.

4. The method of claim 3, wherein the performing static code parsing on the project file of the target project to obtain the set of candidate vulnerabilities comprises at least one of:

screening component vulnerabilities existing in a group of project components according to the component version of each project component in the group of project components of the project file of the target project to obtain a group of component vulnerabilities;

analyzing the parameter entering mode of each native method in a set of native methods of the project file of the target project to obtain a set of native method vulnerabilities existing in the set of native methods;

analyzing a database query mode in a project file of the target project, and determining database query mode loopholes existing in the target project to obtain a group of database query mode loopholes, wherein the database query mode loopholes comprise at least one of the following: there is a mapping relation of the injection holes, and there is a database operation statement of the injection holes.

5. The method of claim 3, wherein after said static code parsing of the project file of the target project to obtain the set of candidate vulnerabilities, the method further comprises:

analyzing a method call link of the project file of the target project to obtain a method call relation diagram corresponding to the target project;

searching a method call link corresponding to each candidate vulnerability in the method call relation diagram;

and removing the candidate loopholes with abnormal corresponding method call links from the set of candidate loopholes to obtain the updated set of candidate loopholes.

6. A method according to claim 3, wherein said performing static code parsing on the project file of the target project to obtain an interface request for the project file of the target project comprises:

extracting a request method in a project file of the target project to obtain a group of request methods;

identifying a uniform resource identifier corresponding to each request method in the set of request methods according to the architecture information of the target item and the configuration information of the item root path of the target item;

Updating the uniform resource identifier corresponding to the first abnormal request method when the first abnormal request method incapable of identifying the corresponding uniform resource identifier exists in the group of request methods;

correcting the parameters of the loopholes at the interfaces of the request bodies of the second abnormal request methods under the condition that the second abnormal request methods containing the parameters of the loopholes at the interfaces of the corresponding request bodies exist in the group of request methods;

and generating an interface request of the project file of the target project according to the set of request methods.

7. The method according to any one of claims 1 to 6, wherein in the deployed testing environment, validating each candidate vulnerability according to the request data call corresponding to each candidate vulnerability and the interface corresponding to each candidate vulnerability, to obtain the validation result of each candidate vulnerability, includes:

in the deployed test environment, performing the following vulnerability verification operation with each candidate vulnerability as a current candidate vulnerability to obtain a verification result of each candidate vulnerability, wherein when the following vulnerability verification operation is performed, request data corresponding to the current candidate vulnerability is current request data, and an interface corresponding to the current candidate vulnerability is a current interface:

Adding a vulnerability verification script corresponding to the current candidate vulnerability to the current request data to obtain updated current request data;

in the deployed test environment, calling the current interface according to the updated current request data;

generating a current feature library corresponding to the test environment after calling the current interface under the condition that the current interface does not return a response result corresponding to the updated current request data; and determining a verification result of the current candidate vulnerability by comparing the current feature library with a reference feature library, wherein the reference feature library is a feature library corresponding to the test environment before the current interface is called, and the verification result of the current candidate vulnerability is used for indicating the availability of the current candidate vulnerability.

8. A test device for project codes, comprising:

the execution unit is used for importing a project file of a target project to be tested and generating a starting command interface of the project file of the target project;

the first analysis unit is used for carrying out static code analysis on the project file of the target project to obtain a group of candidate vulnerabilities and request data corresponding to each candidate vulnerability in the group of candidate vulnerabilities, wherein the request data corresponding to each candidate vulnerability is used for verifying each candidate vulnerability by calling an interface corresponding to each candidate vulnerability;

the importing unit is used for importing the project file of the target project into a warehouse container through the starting command interface so as to deploy a test environment of the project file of the target project;

and the verification unit is used for verifying each candidate vulnerability according to the request data corresponding to each candidate vulnerability and calling an interface corresponding to each candidate vulnerability in the deployed test environment to obtain a verification result of each candidate vulnerability.

9. A computer-readable storage medium, characterized in that the computer-readable storage medium comprises a stored program, wherein the program when run performs the method of any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that the memory has stored therein a computer program, the processor being arranged to execute the method according to any of claims 1 to 7 by means of the computer program.