Scalable pre-analysis for dynamic applications

Abstract

A method may include dividing code into trusted components and untrusted components, and identifying a dynamic call in a first component of the code. The first component may be an untrusted component. The method may also include extracting dynamic information from the dynamic call, and using the dynamic information and metadata describing the dynamic behavior of the code to identify a target of the dynamic call. The target may correspond to a second component of the code. The method may also include determining that the target matches the dynamic call, and in response to determining that the target matches the dynamic call, adding an edge from the dynamic call to the target to a call graph generated from the code.

Description

Background Art

[0001] Large-scale software applications often contain dynamically generated content or links between software components. For example, Servlets, Java Beans, and Java Server Pages (JSPs) can be combined to create dynamically generated HTML pages, where the underlying program elements can be exposed through parameters passed when calling. The dynamic nature of such applications poses challenges when performing static analysis. For example, without understanding the dynamic behavior of the application, it is impossible to fully generate a call graph that models the execution path through the application (for example, when performing static analysis). In addition, an incomplete call graph can interfere with the identification of security vulnerabilities. Conventional methods for modeling execution paths in the presence of dynamic behavior include custom analysis and manual configuration of static analysis tools, which results in a lot of additional work and complexity. Summary of the Invention

[0002] This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to help limit the scope of the claimed subject matter.

[0003] In general, in one aspect, one or more embodiments relate to a method that includes partitioning code into trusted components and untrusted components, and identifying a dynamic call in a first component of the code. The first component is one of the untrusted components. The method also includes extracting dynamic information from the dynamic call, and using the dynamic information and metadata describing the dynamic behavior of the code to identify a target of the dynamic call. The target corresponds to a second component of the code. The method also includes determining that the target matches the dynamic call, and in response to determining that the target matches the dynamic call, adding an edge from the dynamic call to the target to a call graph generated from the code.

[0004] In general, in one aspect, one or more embodiments relate to a system that includes a repository configured to store code, metadata describing the dynamic behavior of the code, and a call graph generated from the code, a memory coupled to a processor, and a code splitter that executes on the processor and uses the memory, the code splitter configured to partition the code into trusted and untrusted components. The system also includes a static rewriter that executes on the processor and uses the memory, the static rewriter configured to identify a dynamic call in a first component of the code. The first component is one of the untrusted components. The static rewriter is further configured to extract dynamic information from the dynamic call and use the dynamic information and the metadata to identify a target of the dynamic call. The target corresponds to a second component of the code. The static rewriter is further configured to determine that the target matches the dynamic call and, in response to determining that the target matches the dynamic call, add an edge from the dynamic call to the target to the call graph generated from the code.

[0005] In general, in one aspect, one or more embodiments relate to a non-transitory computer-readable medium comprising instructions that, when executed by a processor, perform: partitioning code into trusted and untrusted components, and identifying a dynamic call in a first component of the code. The first component is one of the untrusted components. The instructions further perform: extracting dynamic information from the dynamic call, and using the dynamic information and metadata describing the dynamic behavior of the code to identify a target of the dynamic call. The target corresponds to a second component of the code. The instructions further perform: determining that the target matches the dynamic call, and in response to determining that the target matches the dynamic call, adding an edge from the dynamic call to the target to a call graph generated from the code.

[0006] Other aspects of the invention will become apparent from the following description and appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A system according to one or more embodiments of the present invention is shown.

[0008] Figure 2 and Figure 3 A flow chart according to one or more embodiments of the present invention is shown.

[0009] Figure 4A 、 Figure 4B 、 Figure 4C 、 Figure 4D 、 Figure 4E and Figure 4F Examples according to one or more embodiments of the present invention are shown.

[0010] Figure 5A and Figure 5B A computing system according to one or more embodiments of the invention is shown. DETAILED DESCRIPTION

[0011] Now, the specific embodiment of the present invention will be described in detail with reference to the accompanying drawings. For consistency, the same elements in various drawings are represented by the same reference numerals.

[0012] In the following detailed description of the embodiments of the present invention, various specific details are set forth in order to provide a more thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0013] Throughout the application, ordinal numbers (e.g., first, second, third, etc.) may be used as adjectives for elements (i.e., any noun in the application). The use of ordinal numbers does not imply or create any particular ordering of elements, nor does it limit any element to only a single element, unless explicitly disclosed, such as by using the terms "before," "after," "single," and other such terms. Rather, the use of ordinal numbers is to distinguish elements. As an example, a first element is different from a second element, and a first element may encompass more than one element and be after (or before) a second element in the ordering of elements.

[0014] In general, embodiments of the present invention are directed to methods, systems, and computer-readable media for analyzing code with dynamic behavior. The code can be analyzed for security vulnerabilities, including vulnerabilities such as SQL injection or cross-site scripting attacks. In one or more embodiments, the code is divided into trusted components and untrusted components. The analysis can focus on the untrusted components, thereby improving scalability. Scalability can be further improved by replacing calls to trusted components with stubs. In one or more embodiments, the analysis uses metadata external to the code that configures the code's dynamic behavior to match dynamic calls with targets (e.g., methods or functions). In one or more embodiments, a dynamic call is a statement whose runtime behavior depends on information external to the code. For example, a dynamic call can correspond to an architecture specification (e.g., an interface or package), and the target can implement the architecture specification. Other examples of dynamic calls include reflective calls (e.g., the invoke method of the Java reflection tool). The metadata can name the components (e.g., classes) of the code to be used when implementing the architecture specification.

[0015] Edges from dynamic calls to matching targets can be added to the call graph generated from the code. Thus, using metadata to resolve dynamic calls to targets without executing the code can make the call graph more accurate and complete. If metadata is missing or the dynamic call cannot be matched, then by leveraging environment variables (e.g., Java Classpath variables) to search for matching targets, the call graph can be over-approximated by adding edges from the dynamic call to multiple possible targets.

[0016] Figure 1 FIG. 1 shows a computer system (100) according to one or more embodiments of the present invention. Figure 1 As shown in FIG, a computer system (100) includes a repository (102), a code splitter (104), a translator (106), a processor (108), and a static rewriter (110). In one or more embodiments, the computer system (100) employs a Figure 5A and the computing system (500) described in the accompanying description below, or in the form of a computer system (500) with respect to Figure 5B In one or more embodiments, the processor (108) is configured to receive a signal from a client device (526) as described above. Figure 5A and the form of the processor (502) described in the accompanying description below.

[0017] In one or more embodiments, the repository (102) can be any type of storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, or any other storage mechanism). Additionally, the repository (102) can include multiple different storage units and / or devices. The multiple different storage units and / or devices may or may not be of the same type or located at the same physical site.

[0018] In one or more embodiments, the repository (102) includes code (112). In one or more embodiments, the code (112) can be any collection of source code that includes various software components. That is, the code (112) can be any collection of computer instructions (e.g., statements) written in a human-readable programming language. The code (112) can be converted into binary machine code by a compiler. The compiled machine code can then be executed by a processor (e.g., contained in the computer system (100)) to execute the software components generated from the code (112). In one or more embodiments, the code (112) can be any collection of object code (e.g., generated by a compiler) or another form of code (112). For example, the code (112) can be an archive file that packages the compiled components.

[0019] In one or more embodiments, the code (112) includes a trusted component (114) and an untrusted component (116). In one or more embodiments, the trusted component (114) is a portion of the code (112) that is considered safe. Libraries and frameworks can be examples of trusted components (114). In one or more embodiments, static analysis of the code (112) can omit analysis of the trusted component (114). In one or more embodiments, a trusted component (114) is any portion of the code (112) that is exempt from analysis of the code (112).

[0020] In one or more embodiments, an untrusted component (116) is a portion of the code (112) that is considered potentially unsafe. For example, the untrusted component (116) may include user-defined code. In one or more embodiments, the untrusted component (116) includes a portion of the code (112) that receives input from an external source and / or sends output to an external source (e.g., code that may be vulnerable to external attacks). For example, the untrusted component (116) may include code that dynamically generates web pages such as Java Server Pages (JSP). The untrusted component (116) may be any portion of the code (112) that is not part of the trusted component (114).

[0021] In one or more embodiments, the trusted components (114) and / or untrusted components (116) are defined based on user settings (126). For example, the user settings (126) may specify a directory in a file system of the computer system (100) that includes the trusted components (114) and another directory in the file system that includes the untrusted components (116).

[0022] In one or more embodiments, the trusted component (114) and the untrusted component (116) include a dynamic call (118). In one or more embodiments, a dynamic call (118) is a statement whose runtime behavior depends on information external to the code (112). The dynamic call (118) can be a reflective call, such as a method call supported by a reflection capability that enables the code to modify its structure and / or behavior at runtime. For example, the Java reflection tool provides reflective calls, such as the method invoke. In one or more embodiments, the runtime behavior of the dynamic call (118) depends on metadata (122) and / or environment variables (124). In one or more embodiments, the metadata (122) and / or environment variables (124) can be used to resolve a target for the dynamic call (118). The target of the dynamic call (118) can be a method, a function, a procedure, etc.

[0023] In one or more embodiments, the dynamic call (118) may correspond to an architectural specification of the code (112). The architectural specification may specify a behavior without specifying how the behavior is implemented. In one or more embodiments, the behavior of the architectural specification may be implemented in different ways using different components of the code (112). An example of an architectural specification is an interface, as shown in the following code snippet:

[0024] public interface A {public String getMsg();}

[0025] The interface A shown above does not specify an implementation for the abstract method getMsg, only that any implementation of getMsg by any concrete method will generate a string output. There can be different components in the code that implement interface A in different ways. For example, different classes can include different concrete methods that implement the abstract method getMsg to generate different string outputs. The concrete methods that implement the abstract method can be called target methods. The class that actually implements interface A at runtime can depend on external information (e.g., metadata (122) and / or environment variables (124)). Another example of an architecture specification is an abstract class that does not define an implementation for its abstract methods.

[0026] In one or more embodiments, the call graph (120) includes nodes that each correspond to a statement in the code (112). Control flow between statements can be indicated via edges between the nodes. In one or more embodiments, the call graph (120) can be part of an intermediate representation of the code (112) that is compiled into executable machine code. In one or more embodiments, static analysis (e.g., security analysis) can be performed on the intermediate representation of the code (112).

[0027] In one or more embodiments, the call graph (120) includes zero or more edges between each dynamic call (118) and zero or more potential targets of the dynamic call (118). For example, depending on external information such as metadata (122) and / or environment variables (124), the potential targets may be called at runtime as a result of invoking the dynamic call (118).

[0028] In one or more embodiments, the metadata (122) includes any information used to configure the dynamic (e.g., runtime) behavior of the code (112). There can be a specific process associated with each piece of metadata (122) that is used to resolve the dynamic behavior of the code (112). In one or more embodiments, the metadata (122) can be used to identify the target of the dynamic call (118). For example, the metadata (122) can name a component (e.g., a class) to be used when implementing the architecture specification of the code (112). In one or more embodiments, the metadata (122) is external to the code (112). For example, the metadata (122) can be stored in a file (e.g., an Extensible Markup Language (XML) file) separate from the code (112). When evaluating potential targets for use at runtime to implement the architecture specification, the metadata (122) can be matched with framework-related annotations (such as the Spring Framework's @Autowired and @Component annotations).

[0029] In one or more embodiments, the environment variable (124) is a parameter of the computer system (100). For example, the environment variable (124) can be a search path (e.g., a Java Classpath variable) that specifies one or more locations in the file system of the computer system (100). The search path can be used when attempting to resolve a class name to a target that implements a corresponding class. More generally, the environment variable (124) can indicate a context to use when resolving names referenced in the code (112). For example, the environment variable (124) can indicate a namespace to use when resolving a class name, method name, or variable name referenced in the code (112).

[0030] In one or more embodiments, the user settings (126) are parameters of the computer system (100) that are configurable by the user. For example, the user settings (126) may specify one or more locations in the file system of the computer system (100) to use when identifying trusted components (114). Similarly, the user settings (126) may specify one or more locations in the file system of the computer system (100) to use when identifying untrusted components (116). For example, the user settings (126) may specify that libraries and frameworks are untrusted components (116) (e.g., in the context of a specific static analysis).

[0031] continue Figure 1In one or more embodiments, the code splitter (104) can be implemented in hardware (e.g., circuitry), software, firmware, and / or any combination thereof. In one or more embodiments, the code splitter (104) can include functionality for dividing the code (112) into trusted components (114) and untrusted components (116). The code splitter (104) can include functionality for representing the trusted components (114) and the untrusted components (116) in a format suitable for further analysis (e.g., class files).

[0032] In one or more embodiments, the translator (106) may be implemented in hardware (e.g., circuitry), software, firmware, and / or any combination thereof. In one or more embodiments, the translator (106) may include a compiler that converts the code (112) into machine code. A compiler may be a computer program designed to convert source code or an intermediate representation written in a programming language into machine code that can be executed in a virtual machine. In one or more embodiments, the compiler includes functionality to translate the intermediate representation of a program into machine code that the virtual machine is configured to execute. For example, the compiler may include functionality to create machine code that increases the execution speed of the code (112) when executed instead of directly executing the intermediate representation. In one or more embodiments of the invention, the compiler includes functionality to perform dynamic compilation of operations or functions while the program is executing (e.g., just-in-time (JIT) compilation).

[0033] In one or more embodiments, the translator (106) may include functionality to convert (e.g., compile) one or more untrusted components (116) into an intermediate representation (e.g., an intermediate representation including a call graph (120). In one or more embodiments, the translator may translate class files corresponding to the untrusted components (116) into the intermediate representation.

[0034] continue Figure 1 In one or more embodiments, the processor (108) includes functionality to execute code (112). In one or more embodiments, the processor (108) includes functionality to execute a code splitter (104), a translator (106), and / or a static rewriter (110).

[0035] In one or more embodiments, the static rewriter (110) can be implemented in hardware (e.g., circuitry), software, firmware, and / or any combination thereof. In one or more embodiments, the static rewriter (110) can include functionality for identifying and analyzing dynamic calls (118). The static rewriter (110) can include functionality for adding one or more edges to a call graph (120) based on matching one or more targets with the dynamic calls (118).

[0036] In one or more embodiments, the static rewriter (110) may include functionality to generate an error report (128). The report (128) may include a log of dynamic calls (118) for which no matching target was found. The report (128) may be stored as a document accessible to interested entities (e.g., programmers).

[0037] Although Figure 1 The configuration of components is shown, but other configurations can be used without departing from the scope of the present invention. For example, various components can be combined to create a single component. As another example, the function performed by a single component can be performed by two or more components.

[0038] Figure 2 A flowchart is shown according to one or more embodiments of the present invention. The flowchart depicts a process for analyzing code. Figure 2 One or more steps in the above reference Figure 1 The components of the computer system (100) discussed herein (e.g., the code splitter (104), the translator (106), or the static rewriter (110)) perform. In one or more embodiments of the invention, Figure 2 One or more of the steps shown in the figure may be omitted, repeated and / or performed in parallel, or in a manner similar to that shown in the figure. Figure 2 Therefore, the scope of the present invention should not be considered limited to Figure 2 The specific arrangement of the steps shown in .

[0039] Initially, in step 200, the code is divided into trusted components and untrusted components. In one or more embodiments, the code splitter places the trusted components in a location (e.g., a directory) in the file system of the computer system indicated by a user setting. Similarly, the code splitter can place the untrusted components in a location in the file system indicated by another user setting.

[0040] In one or more embodiments, the translator can reduce the size of an untrusted component by replacing one or more calls from the untrusted component to a trusted component with a stub. For example, the translator can replace calls from the untrusted component to a web server internal that supports Java Server Pages (JSP) with a stub, since the server internals are assumed to be secure (i.e., trusted components). Eliminating further analysis of calls to trusted components can improve the performance of analyzing untrusted components without reducing the accuracy or completeness of the analysis.

[0041] In step 202, a dynamic call in a component of the code is identified. In one or more embodiments, the component is an untrusted component. That is, to improve performance, the static rewriter limits its focus to dynamic calls in untrusted components.

[0042] In one or more embodiments, the dynamic call can be a reflective call, such as a method invoke in Java. Alternatively, the dynamic call can be indicated via an architecture specification, such as an interface or package in Java. In addition, the dynamic call can be indicated via a framework-related annotation (such as the @Autowired annotation in the Spring framework). For example, a list of known reflective calls and architecture specifications (e.g., programming language-specific) and a list of known annotation keywords (e.g., framework-specific) can be used to identify the dynamic call.

[0043] In step 204, dynamic information is extracted from the dynamic call. In one or more embodiments, the dynamic information includes an identifier. For example, the identifier may correspond to the name of a potential target of the dynamic call. In one or more embodiments, the dynamic information includes a signature comprising a series of parameters, each having a type. If the dynamic information cannot be extracted from the dynamic call, the static rewriter may report an error.

[0044] In step 206, the target of the dynamic call is identified using the dynamic information and metadata describing the dynamic behavior of the code. The target may correspond to a component of the code. In one or more embodiments, the metadata includes an identifier of the component of the code that matches the identifier extracted from the dynamic call in step 204 above. For example, the target may be a method or function of a class annotated with the identifier included in the metadata.

[0045] In one or more embodiments, to improve the efficiency of processing metadata, the metadata is first pre-processed to remove information that is not relevant to the dynamic behavior of the code.

[0046] In step 208, determine that target matches dynamic call.In one or more embodiments, when target is potentially reachable within the scope of dynamic call and target has the signature that matches with the signature of the dynamic information extracted in step 204 above, target matches dynamic call.For example, when target is included in the component of the code that realizes dynamic call, target is potentially reachable within the scope of dynamic call.In one or more embodiments, when the number, position and type of the parameters of target matches the number, position and type of the parameters of dynamic information, the signature of target matches dynamic information.For example, dynamic information and matching target can specify 3 parameters, and the first two parameters are integer types, and the third parameter is a string type.

[0047] In step 210, in response to determining that the target matches the dynamic call, an edge from the dynamic call to the target is added to the call graph. The translator can generate the call graph from the code. Thus, the static rewriter can statically determine (i.e., without executing code) the call graph edge between the dynamic call and the target.

[0048] The process described in this paper was used to pre-process large-scale applications before running static security analysis. Edges added to the call graph enabled static analysis to avoid analyzing irrelevant execution paths. Furthermore, static analysis was able to identify security vulnerabilities in the code at the edges added to the call graph, making it possible to apply static analysis to applications that had previously been unanalyzed due to a lack of scalability and precision in analysis tools. The result was the identification of several security flaws that had not been detected by other methods, with a low false positive rate.

[0049] Figure 3 A flowchart is shown according to one or more embodiments of the present invention. The flowchart depicts a process for analyzing code. Figure 3 One or more steps in the above reference Figure 1 The components of the computer system (100) discussed herein (e.g., the code splitter (104), the translator (106), or the static rewriter (110)) perform. In one or more embodiments of the invention, Figure 3 One or more of the steps shown in the figure may be omitted, repeated and / or performed in parallel, or in a manner similar to that shown in the figure. Figure 3 Therefore, the scope of the present invention should not be considered limited to Figure 3 The specific arrangement of the steps shown in .

[0050] Initially, in step 302, an instruction in one of the untrusted components is selected (see the description of step 200 above). In one or more embodiments, each instruction in the untrusted component is selected in successive iterations of step 302. In one or more embodiments, the instructions selected in step 302 are limited to instructions that include entries in a keyword list known to correspond to dynamic invocations (e.g., a programming language and / or framework-specific list).

[0051] If it is determined in step 304 that the selected instruction is a dynamic call, then the following step 306 is executed. Otherwise, if it is determined in step 304 that the selected instruction is not a dynamic call, then the following step 314 is executed.

[0052] In step 306, dynamic information is extracted from the dynamic call (see the description of step 204 above).

[0053] In step 308, the metadata is used to identify the target of the dynamic call (see the description of step 206 above).

[0054] If it is determined in step 310 that the target matches the dynamic call (see the description of step 208 above), then the following step 312 is executed. Otherwise, if step 310 determines that the target does not match the dynamic call, then the following step 316 is executed. For example, the target does not match the dynamic call when the target is not reachable within the dynamic call range or the target has a signature that does not match the dynamic information extracted in step 306 above.

[0055] In step 312, an edge from the dynamic call to the target is added to the call graph (see description of step 210 above).

[0056] In step 314, if it is determined that there are additional instructions in the untrusted component that have not yet been selected, then step 302 is performed again to select another instruction.

[0057] In step 316, one or more targets of the dynamic call are identified without using metadata. That is, after failing to identify a unique target that matches the dynamic call using metadata, the static rewriter may search for multiple matching targets without using metadata. For criteria for determining when a target matches a dynamic call, see the description of step 208 above.

[0058] The search for matching targets may be performed relative to a location in the computer system's file system specified by one or more environment variables. For example, the Java Classpath environment variable may specify a directory that may be used to search for class files that may include candidate targets.

[0059] If it is determined in step 318 that one or more of the targets identified in step 316 above match the dynamic call, then the following step 322 is executed. Otherwise, if it is determined in step 318 that no target matches the dynamic call, then step 320 is executed.

[0060] In step 320, a report identifies a failure to match a target for a dynamic call. The static rewriter may generate an error report that includes the dynamic call and metadata. In one or more embodiments, the failure to match may be due to a requirement to provide additional software components at runtime. For example, the additional software components may include the intended target of the dynamic call. In one or more embodiments, in response to the failure to match, the static rewriter may request that the user explicitly specify the intended target for the dynamic call. The static rewriter may then add a call graph edge between the dynamic call and the user-provided target.

[0061] Step 314 above is then executed to continue processing instructions in the untrusted component.

[0062] In step 322, an edge from the dynamic call to each matching target is added to the call graph (see the description of step 312 above). That is, in the absence of a unique matching target identified using metadata, the static rewriter can conservatively over-approximate the call graph by adding an edge corresponding to each target that matched the dynamic call identified in step 316 above. Step 314 above is then executed to continue processing instructions in the untrusted component.

[0063] The following examples are for illustrative purposes only and are not intended to limit the scope of the present invention. Figure 4A 、 Figure 4B 、 Figure 4C and Figure 4D Implementation examples according to one or more embodiments of the present invention are shown.

[0064] Figure 4A The processing of an archive file (400) that aggregates code (402) ( Figure 1 (112)), metadata (404)(( Figure 1 (122)) and environment variables (406) ( Figure 1 (124) in). The archive file (400) includes a Java Enterprise Edition (JEE) application represented in an Enterprise ARchive (EAR) format (for example, other possible formats are Java ARchive (JAR) format, Web ARchive (WAR) format, etc.). Code Splitter (410) ( Figure 1 (104) in) divides the code (402) into application source & class files (412), library / framework class files (414), and application Java Server Page (JSP) files (416). Based on user settings indicating components that the user considers "trustworthy", the code splitter (410) assigns the application source & class files (412) to the app directory of the computer system's file system, assigns the library / framework class files (414) to the lib directory, and extracts the application JSP files (416) to the web directory. The library / framework class files (414) are trusted components ( Figure 1 (114) in). Application source & class files (412) and application JSP files (416) are untrusted components ( Figure 1 To facilitate the processing of the application JSP file (416), translator A (420a) ( Figure 1 One of the translators (106) in ) translates the application JSP file (416) into a Java class file (418).

[0065] Translator B (420b) generates an intermediate representation (422) from the application source & class files (412), library / framework class files (414) and Java class files (418). Then, as Figure 4B 、 Figure 4C and Figure 4D As shown in , the static rewriter (430) ( Figure 1 The intermediate representation (422) is modified using metadata (404) and environment variables (406) in the (110) of the embodiment. Based on user settings, the static rewriter (430) analyzes only dynamic calls in untrusted components. Finally, the intermediate representation (422) is used when performing static analysis (432).

[0066] Figure 4B 、 Figure 4C 、 Figure 4D 、 Figure 4E and Figure 4F The diagram shows an example based on Oracle Application Framework (OAF), which is a Model-View-Controller (MVC) framework built using Java Enterprise Edition (JEE) technology. Figure 4B As shown in , the metadata (450) identifies the component class (452) ExampleAMImpl, which the static rewriter will use to resolve dynamic calls. Figure 4C Code (460) is shown that includes an architecture specification (462), in this case a base class OAApplicationModuleImpl, which is extended by two different component classes (ExampleAMImpl and OtherAMImpl). Each component class defines a target (464a, 464b) that implements a doSomething method. When the application module is instantiated, the component class (452) specified by the metadata (450) is used to select the class ExampleAMImpl to implement the base class OAApplicationModuleImpl (i.e., the architecture specification (462)). In Figure 4D The application module instantiation point (466) is illustrated in FIG. Thus, based on the specification of the component class (452) ExampleAMImpl by the metadata (450), the dynamic call (468) to the doSomething method of the instantiated application module is resolved to the target A (464a).

[0067] Figure 4EThe diagram shows a scenario where metadata (450) matches a dynamic call (468). The static rewriter adds an edge connecting the dynamic call (468) and target A (464a) to the call graph (470). Thus, without executing code (460), the call graph (470) is made more accurate and complete by using metadata (450) to resolve the dynamic call (468) to target A (464a).

[0068] Figure 4F The diagram illustrates an alternative scenario where metadata (450) is missing or fails to match a dynamic call (468). In this alternative scenario, the static rewriter attempts to add edges to the over-approximated call graph (480) to consider all possible execution paths from the dynamic call (468) to potential targets (464a, 464b). The static rewriter searches the code (460) for potential targets with names and signatures that match the name and signature of the dynamic call (468) (e.g., a function with string arguments and a Boolean argument that returns a void value). Figure 4F Illustrated is the addition of an edge connecting the dynamic call (468) and two targets (464a, 464b) to the over-approximated call graph (480).

[0069] The embodiments disclosed herein may be implemented on a computing system. Any combination of mobile devices, desktops, servers, routers, switches, embedded devices, or other types of hardware may be used. For example, Figure 5A As shown in , the computing system (500) may include one or more computer processors (502), non-persistent storage (504) (e.g., volatile memory such as random access memory (RAM), cache memory), persistent storage (506) (e.g., a hard disk, an optical drive such as a compact disc (CD) drive or a digital versatile disc (DVD) drive, flash memory, etc.), a communication interface (512) (e.g., a Bluetooth interface, an infrared interface, a network interface, an optical interface, etc.), and many other elements and functions.

[0070] The computer processor(s) (502) may be an integrated circuit for processing instructions. For example, the computer processor(s) may be one or more cores or microcores of a processor. The computing system (500) may also include one or more input devices (510), such as a touch screen, a keyboard, a mouse, a microphone, a touchpad, an electronic pen, or any other type of input device.

[0071] The communication interface (512) may include a module for connecting the computing system (500) to a network (not shown) (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, a mobile network, or any other type of network) and / or another device (such as another computing device).

[0072] Additionally, the computing system (500) may include one or more output devices (508), such as a screen (e.g., a liquid crystal display (LCD), a plasma display, a touch screen, a cathode ray tube (CRT), a monitor, a projector, or other display device), a printer, an external storage device, or any other output device. One or more of the output devices may be the same as or different from the input device(s). The input and output device(s) may be connected locally or remotely to the computer processor(s) (502), the non-persistent storage device(s) (504), and the persistent storage device(s) (506). Many different types of computing systems exist, and the aforementioned input and output device(s) may take other forms.

[0073] The software instructions in the form of computer-readable program code that implement the embodiments disclosed herein may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer-readable medium, such as a CD, DVD, storage device, floppy disk, tape, flash memory, physical memory, or any other computer-readable storage medium. Specifically, the software instructions may correspond to a computer-readable program code that, when executed by (one or more) processors, is configured to implement one or more embodiments disclosed herein.

[0074] Figure 5A The computing system (500) in the embodiment may be connected to or be part of a network. For example, Figure 5B As shown in FIG, a network (520) may include multiple nodes (e.g., node X (522), node Y (524)). Each node may be connected to a computing system (such as Figure 5A ) corresponds to, or a group of nodes combined with Figure 5A . For example, the embodiments disclosed herein may be implemented on a node in a distributed system that is connected to other nodes. By way of another example, the embodiments disclosed herein may be implemented on a distributed computing system having multiple nodes, wherein each portion disclosed herein may be located on a different node within the distributed computing system. Additionally, one or more components of the aforementioned computing system (500) may be located at a remote location and connected to other components via a network.

[0075] Although Figure 5B Although not shown, a node may correspond to a blade in a server chassis that is connected to other nodes via a backplane. By way of another example, a node may correspond to a server in a data center. By way of another example, a node may correspond to a computer processor or micro-core of a computer processor with shared memory and / or resources.

[0076] Nodes in the network (520), such as node X (522), node Y (524), can be configured to provide services to client devices (526). For example, the nodes can be part of a cloud computing system. The nodes can include functionality to receive requests (526) from client devices and transmit responses to client devices (526). Client devices (526) can be computing systems such as Figure 5A ). Additionally, the client device (526) may include and / or execute all or a portion of one or more embodiments disclosed herein.

[0077] Figure 5A and 5B The computing system or group of computing systems described herein may include functionality for performing the various operations disclosed herein. For example, the computing system(s) may perform communications between processes on the same or different systems. Various mechanisms employing some form of active or passive communication may facilitate data exchange between processes on the same device. Examples of these inter-process communications include, but are not limited to, implementations of files, signals, sockets, message queues, pipes, semaphores, shared memory, message passing, and memory-mapped files. Further details regarding several of these non-limiting examples are provided below.

[0078] Based on the client-server networking model, sockets can be used as interfaces or communication channel endpoints, enabling bidirectional data transfer between processes on the same device. First, following the client-server networking model, a server process (e.g., a process providing data) can create a first socket object. Next, the server process binds the first socket object, thereby associating the first socket object with a unique name and / or address. After creating and binding the first socket object, the server process then waits and listens for incoming connection requests from one or more client processes (e.g., processes seeking data). At this point, when a client process wishes to obtain data from the server process, the client process begins by creating a second socket object. The client process then proceeds to generate a connection request, which includes at least a second socket object and a unique name and / or address associated with the first socket object. The client process then transmits the connection request to the server process. Depending on availability, the server process may accept the connection request and establish a communication channel with the client process, or the server process, busy handling other operations, may queue the connection request in a buffer until the server process is ready. The established connection notifies the client process that communication can begin. In response, the client process may generate a data request specifying the data the client process wishes to obtain. The data request is then transmitted to the server process. Upon receiving the data request, the server process analyzes the request and collects the requested data. Finally, the server process then generates a reply including at least the requested data and transmits the reply to the client process. The data may more typically be transmitted as a datagram or a stream of characters (e.g., bytes).

[0079] Shared memory refers to the allocation of virtual memory space to provide a mechanism for data to be communicated and / or accessed by multiple processes. When implementing shared memory, an initialization process first creates a shareable segment in persistent or non-persistent storage. After creation, the initialization process installs the shareable segment and then maps the shareable segment into the address space associated with the initialization process. After installation, the initialization process proceeds to identify and grant access permissions to one or more authorized processes, which can also write data to or read data from the shareable segment. Changes made to data in the shareable segment by one process can immediately affect other processes that are also linked to the shareable segment. In addition, when one of the authorized processes accesses the shareable segment, the shareable segment is mapped into the address space of that authorized process. Often, only one authorized process other than the initialization process can install the shareable segment at any given time.

[0080] Other techniques may be used to share data (such as the various data described in this application) between processes without departing from the scope of the present invention. These processes may be part of the same or different applications and may be executed on the same or different computing systems.

[0081] Figure 5A The computing systems in a system can implement and / or connect to a data repository. For example, one type of data repository is a database. A database is a collection of information configured to simplify data retrieval, modification, reorganization, and deletion. A database management system (DBMS) is a software application that provides a user interface for defining, creating, querying, updating, or otherwise managing a database.

[0082] A user or software application can submit a statement or query to the DBMS. The DBMS then interprets the statement. The statement can be a select statement, update statement, create statement, delete statement, etc. that requests information. In addition, the statement can include parameters, (one or more) identifiers, conditions (comparison operators), functions (e.g., join, full join, count, average, etc.), sorting (e.g., ascending, descending), or other parameters that specify data or data containers (databases, tables, records, columns, views, etc.). The DBMS can execute the statement. For example, the DBMS can access memory buffers, references to files, or indexes to read, write, delete, or any combination thereof in response to the statement. The DBMS can load data from persistent or non-persistent storage devices and perform calculations in response to the query. The DBMS can return (one or more) results to the user or software application.

[0083] The above description of the function only presents the Figure 5A computing systems and Figure 5B

[0066] These are just a few examples of functions performed by nodes and / or client devices in

[0067] Other functions may be performed using one or more embodiments disclosed herein.

[0084] While the present invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as disclosed herein. Accordingly, the scope of the present invention should be limited only by the claims appended hereto.

Claims

1. A computer-implemented method for analyzing a code having dynamic behavior, comprising: Divide source code into trusted and untrusted components; identifying a first dynamic call in a first component of the source code by performing static analysis of the source code without executing the source code, wherein the first component is one of the untrusted components, wherein the first dynamic call corresponds to an architectural specification of the source code; By means of the static analysis and extracting a first signature from the first dynamic call, the first signature includes a series of parameters each having a type; identifying, by the static analysis and using the first signature and first metadata including an identifier of a second component of the source code, a first target of the first dynamic call, wherein the first target is included by the second component of the source code; By the static analysis, determining that the first target implements the architecture specification, determining that the first target includes a second signature that matches the first signature; as well as In response to determining that the first target includes a second signature that matches the first signature, an edge from the first dynamic call to the first target is added to a call graph statically generated from the source code by the static analysis.

2. The computer-implemented method for analyzing code having dynamic behavior as claimed in claim 1, further comprising: A call from the first component to one of the trusted components is replaced with the stub.

3. The computer-implemented method for analyzing code having dynamic behavior of claim 1, further comprising: identifying a second dynamic call in a third component of the source code; extracting second dynamic information from the second dynamic call; failing to identify a target of a second dynamic call using the second dynamic information and second metadata describing dynamic behavior of the source code; In response to failing to identify the target, identifying one or more targets of the second dynamic call using the second dynamic information and the environment variables; determining that the one or more targets match a second dynamic call; as well as In response to determining that the one or more targets match the second dynamic call, an edge from the second dynamic call to each of the one or more targets is added to the call graph.

4. The computer-implemented method for analyzing code having dynamic behavior of claim 1, further comprising: identifying a second dynamic call in a third component of the source code; extracting second dynamic information from the second dynamic call; failing to identify a target of a second dynamic call using the second dynamic information and second metadata describing dynamic behavior of the source code; as well as In response to the failure to identify, a failure to identify the target of the second dynamic call is reported.

5. The computer-implemented method for analyzing code having dynamic behavior of claim 1, wherein dividing the source code into trusted components and untrusted components comprises: The user setting is used to identify a first location in a file system of the computer system corresponding to a trusted component and a second location in the file system corresponding to an untrusted component.

6. The computer-implemented method for analyzing code having dynamic behavior of claim 1, further comprising: Perform security analysis on source code using call graphs; as well as A security vulnerability corresponding to an edge from a first dynamic call to a first target is identified in the source code through the security analysis.

7. A computer-implemented system for analyzing code having dynamic behavior, comprising: a repository configured to store source code, first metadata including an identifier of a second component of the source code, and a call graph statically generated from the source code; a memory coupled to the processor; a code splitter, executing on the processor and using the memory, configured to partition source code into trusted components and untrusted components; as well as The static rewriter, which executes on the processor and uses memory, is configured to: identifying a first dynamic call in a first component of the source code by performing static analysis of the source code without executing the source code, wherein the first component is one of the untrusted components, wherein the first dynamic call corresponds to an architectural specification of the source code; By means of the static analysis and extracting a first signature from the first dynamic call, the first signature includes a series of parameters each having a type; identifying, by the static analysis and using the first signature and the first metadata, a first target of a first dynamic call, wherein the first target is included by a second component of the source code; By the static analysis, determining that the first target implements the architecture specification, determining that the first target includes a second signature that matches the first signature; as well as In response to determining that the first target includes a second signature that matches the first signature, an edge from the first dynamic call to the first target is added to a call graph by the static analysis.

8. The computer-implemented system for analyzing code having dynamic behavior of claim 7, further comprising a translator configured to replace a call from the first component to one of the trusted components with a stub.

9. The computer-implemented system for analyzing code having dynamic behavior of claim 7, wherein the static rewriter is further configured to: identifying a second dynamic call in a third component of the source code; extracting second dynamic information from the second dynamic call; failing to identify a target of a second dynamic call using the second dynamic information and second metadata describing dynamic behavior of the source code; In response to failing to identify the target, identifying one or more targets of the second dynamic call using the second dynamic information and the environment variables; determining that the one or more targets match a second dynamic call; as well as In response to determining that the one or more targets match the second dynamic call, an edge from the second dynamic call to each of the one or more targets is added to the call graph.

10. The computer-implemented system for analyzing code having dynamic behavior of claim 7, wherein the static rewriter is further configured to: identifying a second dynamic call in a third component of the source code; extracting second dynamic information from the second dynamic call; Failing to identify a target of the second dynamic call using the second dynamic information and the second metadata describing the dynamic behavior of the source code; and In response to the failure to identify, a failure to identify the target of the second dynamic call is reported.

11. A computer-implemented system for analyzing code with dynamic behavior as described in claim 7, wherein the memory also includes a file system, and wherein the code splitter is further configured to divide the source code into trusted components and untrusted components by using user settings to identify a first location in the file system corresponding to a trusted component and a second location in the file system corresponding to an untrusted component.

12. A non-transitory computer readable medium comprising instructions that, when executed by a processor, perform: Divide source code into trusted and untrusted components; identifying a first dynamic call in a first component of the source code by performing static analysis of the source code without executing the source code, wherein the first component is one of the untrusted components, wherein the first dynamic call corresponds to an architectural specification of the source code; By means of the static analysis and extracting a first signature from the first dynamic call, the first signature includes a series of parameters each having a type; identifying, by the static analysis and using the first signature and first metadata including an identifier of a second component of the source code, a first target of the first dynamic call, wherein the first target is included by the second component of the source code; By the static analysis, determining that the first target implements the architecture specification, determining that the first target includes a second signature that matches the first signature; as well as In response to determining that the first target includes a second signature that matches the first signature, an edge from the first dynamic call to the first target is added to a call graph statically generated from the source code by the static analysis.

13. The non-transitory computer readable medium of claim 12, further comprising instructions to: A call from the first component to one of the trusted components is replaced with the stub.

14. The non-transitory computer readable medium of claim 12, further comprising instructions to: identifying a second dynamic call in a third component of the source code; extracting second dynamic information from the second dynamic call; failing to identify a target of a second dynamic call using the second dynamic information and second metadata describing dynamic behavior of the source code; In response to failing to identify the target, identifying one or more targets of the second dynamic call using the second dynamic information and the environment variables; determining that the one or more targets match a second dynamic call; as well as In response to determining that the one or more targets match the second dynamic call, an edge from the second dynamic call to each of the one or more targets is added to the call graph.

15. The non-transitory computer readable medium of claim 12, wherein dividing the source code into trusted components and untrusted components comprises: The user setting is used to identify a first location in a file system of the computer system corresponding to a trusted component and a second location in the file system corresponding to an untrusted component.

Images