Using the same query language for static and dynamic application security testing tools

Abstract

A computer program is evaluated for security vulnerabilities by formulating a query in a query language and receiving into a memory of a computer source code of the computer program to be analyzed, preparing a data flow graph from the source code, and determining that the query is satisfied by an analysis of the data flow graph. Alternatively, the computer program is evaluated by collecting runtime events during an execution of binary code and determining that the query is satisfied by an analysis of the runtime events. In either case a security vulnerability is reported.

Description

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to vulnerability assessment of computer software. More particularly, this invention relates to a query language for use in tools for static and dynamic security testing of computer software.

2. Description of the Related Art

The meanings of certain acronyms and abbreviations used herein are given in Table 1.

TABLE 1
Acronyms and Abbreviations
API  Application Programming Interface
CFG  Control Flow Graph
DAST Dynamic Application Security Testing
DOM  Document Object Model
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
IAST Interactive Application Security Testing
J2EE Java ® 2 Enterprise Edition
J2SE Java 2 Standard Edition
JSON JavaScript Object Notation
PTQL Program Trace Query Language
SAST Static Application Security Testing
SQL  Structured Query Language
URL  Uniform Resource Locator
XSS  Cross-Site Scripting

Enterprise security solutions have historically focused on network and host security, e.g., using so-called “perimeter protection” techniques. Despite these efforts, application level vulnerabilities remain as serious threats. Detection of such vulnerabilities has been attempted by lexical analysis of source code. This typically results in large numbers of false positive indications. Line-by-line code analysis has been proposed. However, this has proved to be impractical, as modern software suites typically have thousands of lines of code. Indeed, even in relatively compact environments, such as Java 2 Standard Edition (J2SE), Java 2 Platform, Java 2 Enterprise Edition (J2EE), a runtime module may include thousands of classes.

One technique for detection of vulnerabilities is exemplified by U.S. Patent Application Publication No. 2006/0253841, entitled “Software Analysis Framework”. This technique involves decompilation to parse executable code, identifying and recursively modeling data flows, identifying and recursively modeling control flow, and iteratively refining these models to provide a complete model at the nanocode level.

Another approach is proposed in U.S. Patent Application Publication No. 2004/0255277, entitled “Method and system for Detecting Race Condition Vulnerabilities in Source Code”. Source code is parsed into an intermediate representation. Models are derived for the code and then analyzed in conjunction with pre-specified rules about the routines to determine if the routines possess one or more of pre-selected vulnerabilities.

Static analysis of program code is disclosed in U.S. Patent Application Publication No. 2005/0015752, entitled “Static Analysis Based Error Reduction for Software Applications”. A set of analyses sifts through the program code and identifies programming security and/or privacy model coding errors. A further evaluation of the program is then performed using control and data flow analyses.

Commonly assigned U.S. Pat. No. 9,128,728 to Siman, which is herein incorporated by reference, discloses an automatic tool that analyzes application source code for application level vulnerabilities. The tool integrates seamlessly into the software development process, so vulnerabilities are found early in the software development life cycle, when removing the defects is far cheaper than in the post-production phase. Operation of the tool is based on static analysis, but makes use of a variety of techniques, for example, methods for dealing with obfuscated code.

An example of static analysis combined with dynamic analysis to detect malware is found in U.S. Patent Application Publication No. 201110239294 by Kim et al. The proposed system includes a script decomposition module for decomposing a web page into scripts, a static analysis module for statically analyzing the decomposed scripts in the form of a document file, a dynamic analysis module for dynamically executing and analyzing the decomposed scripts, and a comparison module for comparing an analysis result of the static analysis module and an analysis result of the dynamic analysis module to determine whether the decomposed scripts are malicious scripts. The system and method is said to recognize a hidden dangerous hypertext markup language (HTML) tag irrespective of an obfuscation technique for hiding a malicious script in a web page and thus can cope with an unknown obfuscation technique.

A number of query languages are known in the art for source code analysis, for example the language CxQuery. A description of the language CxQuery is available as the document Checkmarx CxQuery Language API Guide, V8.6.0, available on the Web site of the Assignee hereof, and which is herein incorporated by reference.

One language, known as Program Trace Query Language (PTQL), is adapted to dynamic analysis. PTQL is described in the document Goldsmith et al., Relational Queries Over Program Traces, OOPSLA'05, Oct. 16-20, 2005, San Diego, Calif. PTQL, which is based on relational queries over program traces, enables programmers to write queries about program behavior. A PTQL query can be executed on-line, with the aid of a compiler to instrument the program.

Application instrumentation is widely used for monitoring software performance. Dynamic security tools use this sort of instrumentation for monitoring security events. These events are collected during application runtime and are analyzed in order to determine whether an application is vulnerable. Techniques for instrumentation-based dynamic security testing of this sort are described, for example, in PCT Patent Document WO2016108162, filed Dec. 24, 2015, whose disclosure is incorporated herein by reference.

SUMMARY OF THE INVENTION

According to disclosed embodiments of the invention, a query language is adapted to configure and operate static and dynamic application security testing tools to detect application security vulnerabilities. Static Application Security Testing (SAST) involves analysis of source code. Dynamic Application Security Testing (DAST) finds security weaknesses and vulnerabilities in a running application, by employing fault injection techniques on an app, such as feeding malicious data to the software in order to identify common vulnerabilities, such as SQL injection and cross-site scripting. Another testing method, Interactive Application Security Testing (IAST) combines elements of both SAST and DAST. IAST places an agent within an application and performs its analysis in real-time, anywhere in the development process. SAST and IAST are employed in both static and dynamic testing tools to detect static vulnerabilities and dynamic security-related events. Vulnerabilities are reported in a common format by the static and dynamic security testing tools.

There is provided according to embodiments of the invention a computer-implemented method, which is carried out by formulating a query in a query language. The method is further carried out in a first mode of operation by receiving into a memory of a computer source code of a computer program to be analyzed, preparing a data flow graph from the source code, and making a first determination that the query is satisfied by an analysis of the data flow graph. Alternatively, the method is carried out in a second mode of operation by collecting runtime events during an execution of binary code of the computer program, making a second determination that the query is satisfied by an analysis of the runtime events, and responsively to the first determination or the second determination reporting a security vulnerability in the computer program.

According to a further aspect of the method, a format of the query is invariant when implemented in either the first mode of operation or in the second mode of operation.

Yet another aspect of the method is carried out in the first mode of operation by organizing the source code into a first object model and generating a first data flow model from the first object model, and in the second mode of operation by organizing the runtime events into a second object model, generating a second data flow model from the second object model, and subjecting the first data flow model or the second data flow model to the query.

According to still another aspect of the method, the first data flow model includes a first data flow graph and the second data flow model includes a second data flow graph.

According to an additional aspect of the method, organizing the runtime events includes supplying details of a Hypertext Transfer Protocol (HTTP) request, the details including a Uniform Resource Locator (URL), an input, and a header body.

According to another aspect of the method, organizing the runtime events includes supplying a file name, a line number and a method name.

According to one aspect of the method, collecting runtime events includes instrumenting the binary code at points of input and output of the computer program.

One aspect of the method is carried out by applying a first vulnerability detector to input data at the points of input, and applying a second vulnerability detector to the input data at the points of output, wherein the first vulnerability detector and the second vulnerability detector are responsive to syntax of the input data that is characteristic of an attack pattern.

There is further provided according to embodiments of the invention a data processing system for detecting security vulnerabilities in a computer program including a processor, a memory accessible to the processor, and an I/O facility linked to the processor, wherein execution of the program instructions cause the processor to perform the steps of: accepting via the I/O facility a query in a query language, and in a first mode of operation receiving via the I/O facility into the memory source code of a computer program to be analyzed, preparing a data flow graph from the source code, making a first determination that the query is satisfied by an analysis of the data flow graph, and in a second mode of operation receiving via the I/O facility binary code of the computer program, executing the binary code in the processor and collecting runtime events during the execution of the binary code, making a second determination that the query is satisfied by an analysis of the runtime events, and responsively to the first determination or the second determination reporting a security vulnerability in the computer program.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a better understanding of the present invention, reference is made to the detailed description of the invention, by way of example, which is to be read in conjunction with the following drawings, wherein like elements are given like reference numerals, and wherein:

FIG. 1 is a block diagram of a system for processing computer program code, in accordance with a disclosed embodiment of the invention;

FIG. 2 is a control flow graph in accordance with a disclosed embodiment of the invention;

FIG. 3 is a data flow graph in accordance with a disclosed embodiment of the invention; and

FIG. 4 is a diagram outlining the application of a query language in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the various principles of the present invention. It will be apparent to one skilled in the art, however, that not all these details are necessarily always needed for practicing the present invention. In this instance, well-known circuits, control logic, and the details of computer program instructions for conventional algorithms and processes have not been shown in detail in order not to obscure the general concepts unnecessarily.

Documents incorporated by reference herein are to be considered an integral part of the application except that, to the extent that any terms are defined in these incorporated documents in a manner that conflicts with definitions made explicitly or implicitly in the present specification, only the definitions in the present specification should be considered.

Definitions.

The term “vulnerability” refers to a section of program source or object code, which when executed, has the potential to allow external inputs to cause improper or undesired behavior. Examples of vulnerabilities include buffer overflow, race conditions, and privilege escalation.

“Control flow” refers to a logical execution sequence of program instructions beginning, logically, at the beginning, traversing various loops and control transferring statements (branches), and concluding with the end or termination point of the program.

A “control flow graph” (CFG) is a graphical representation of paths that might be traversed through a program during its execution. Each node in the graph represents a basic block, i.e., a straight-line piece of code without any jumps or jump targets; jump targets start a block, and jumps end a block. Directed edges are used to represent jumps in the control flow.

“Data flow” refers to the process within the program whereby variables and data elements, i.e., data that is stored in program memory either dynamically or statically on some external memory unit, are read from or written to memory. Data flow includes the process whereby variables or data inputs or outputs are defined by name and content and used and/or modified program execution. Data flow may be graphically represented as a “data flow graph”.

A “sanitizer” as used herein refers to a procedure for correcting or eliminating user input to prevent insertion of invalid data.

The terms “source” refers to the beginning of an attack vector (typically an input). The term “sink” refers to the destination or target of the attack, e.g., a database, file system or output.

System Overview.

Turning now to the drawings, reference is initially made to FIG. 1, which is a block diagram of a system 10 for processing computer program code, in accordance with a disclosed embodiment of the invention. The system 10 typically comprises a general purpose or embedded computer 12, which is provided with conventional memory and I/O facilities, and programmed with suitable software for carrying out the functions described hereinbelow. Thus, although portions of the system 10 are shown as comprising a number of separate functional blocks, these blocks are not necessarily separate physical entities, but rather represent different computing tasks or data objects stored in a memory that is accessible to the processor. These tasks may be carried out in software running on a single processor, or on multiple processors. The software may be provided to the processor or processors on non-transitory media, such as CD-ROM or non-volatile memory, or may be retrieved from storage over data networks. Alternatively or additionally, the system 10 may comprise a digital signal processor or hard-wired logic. The system 10 may include a display 14, enabling an operator to interact with the system, typically via a graphical user interface.

Program code to be evaluated for security vulnerabilities comprises inputs to the system 10. The program code may be of two kinds: source code 16 and binary code 18. The binary code 18 may comprise object code modules or executable code. The system 10 is capable of testing security vulnerabilities of both the source code 16 and binary code 18. Queries 20 that detect various types of security vulnerabilities are input by an operator and initially processed in a query input module 22. The queries 20 are written in a query language, referred to herein as the “unified query language”, which is discussed below. The query input module 22 submits the queries 20 to query processor 28, which directs them to either a static testing tool 24 or a dynamic testing tool 26. The query input module 22, query processor 28, static testing tool 24 and dynamic testing tool 26 may execute in the computer 12 (or in other computers in a distributed environment). The dynamic testing tool 26 can be the tool disclosed in commonly assigned application Ser. No. 15/535,732, entitled Code Instrumentation for Runtime Application Self-Protection, which is herein incorporated by reference.

SAST.

The static testing tool 24 applies queries 20 to the source code 16, is parsed and organized into a code data model″, such as a hierarchical Document Object Model (DOM). Some tools, such as the SAST tool described in the above-noted U.S. Pat. No. 9,128,728, also build data and control flow graphs. The code data model, including any data flow graphs, form part of a combined data model, which is used by both static analysis module 30 and dynamic analysis module 32.

Reference is now made to FIG. 2, which is a simplified invocation-aware single method control flow graph 34, of the sort produced by the static testing tool 24 (FIG. 1) in accordance with a disclosed embodiment of the invention. The control flow graph 34 has nodes 36, 38 representing a prolog and an epilog, respectively. A stub 40 for the called function, func2( ), is included, because in this example source code is unavailable for the called function func2( ).

Reference is now made to FIG. 3, which is a data flow graph 42 of the sort produced by the static testing tool 24 (FIG. 1) in accordance with a disclosed embodiment of the invention. A data flow graph describes data flow within a single method. Each time a value is assigned to a variable, the influencing object and the location of the assignment is recorded. As result, a graph can be constructed, in which the data flow nodes are variables in a specific location, and connections represent dependency. The graph is transitive. Thus, a backward transitive closure computed at a specific location retrieves all influencing variables. It will be noted that each node is directed to a node that affects or influences it. For example, in node 44, the assigned value of the variable “c” is influenced by an assignment to a variable “a” in node 46.

Construction of the control flow graph 34 and data flow graph 42 is described in further detail in the above-noted U.S. Pat. No. 9,128,728.

DAST.

DAST approaches the application as a “black box,” and attempts to find vulnerabilities by bombarding the application during runtime with potentially harmful inputs. The dynamic testing tool 26 operates on the binary code 18, for example by recompiling and instrumenting the binary code 18 by known techniques to accommodate the queries 20. For example, code instrumentation and selected inputs may be injected by an interactive application security testing (IAST) agent in order to track relevant points in the input flow. When the binary code is executed in an execution module 48 the flow of the program is captured. Runtime events are collected and analyzed in the dynamic analysis module 32.

One suitable method of dynamically detecting program vulnerabilities is disclosed in the above-noted application Ser. No. 15/535,732. Briefly, instrumentation is targeted at two specific points in the program flow:

(1) Inputs at which the program receives data from users or other data sources; and

(2) Outputs at which the program submits queries or other instructions to sensitive targets, such as databases or file systems, or HTML outputs of Web applications.

During runtime, the instrumented application gets inputs and creates outputs as part of its regular workflow. Each input data that arrives at an instrumented input (source) point is checked by one or more vulnerability sensors, which examine the input for syntax that is characteristic of attack patterns, such as SQL injection, cross-site scripting (XSS), file path manipulation, and JavaScript Object Notation (JSON) injection. Matching of regular expressions may be used for this purpose. When an input is identified as potentially malicious by one of these sensors, it is saved in a cache for a certain period of time (for example, one minute) or until the cache is full. Both cache capacity and saving time duration are configurable. For each saved input, the cache also holds a flag indicating the vulnerabilities to which the input may be relevant, along with other pertinent metadata, such as time, stack trace, and context. Aside from caching the suspicious input, the application workflow continues without interruption.

When the application workflow arrives at an instrumented output, the cache of recent inputs is checked again by vulnerability detectors that are applicable to the specific target of the output. For example, an SQL injection detector may be invoked for database targets, an XSS detector for HTML outputs, and a file manipulation detector for file system APIs. Depending on the type of target, the detector applies appropriate detection logic to the relevant cached inputs in order to detect potentially harmful patterns using detection logic that is appropriate for the target. When the logic finds an input that matches the detection criteria for the current target, an alert is raised, and other preventive action may be taken as well, such as blocking or cleansing the input or even halting the application entirely. If the context of the flow from the input to the output is known, relevant malicious inputs found by the vulnerability sensors are passed only to the appropriate detectors for the relevant targets.

Reports.

Referring again to FIG. 1, the outputs of the static analysis module 30 and dynamic analysis module 32 contribute to vulnerability reports 50, which are contributed by the static analysis module 30 and the dynamic analysis module 32, and may be presented on the display 14 or transmitted to another I/O device (not shown).

The extended data models of both SAST & IAST may be correlated, using the unified query language, as each data model has its own “blind spots” and its own advantages. The query exploits both in order to get improved results. The run-time results of dynamic IAST can be used in order to validate SAST results, which are sometimes doubtful. The combined vulnerability reports 50 add valuable information for the software developer in proving that vulnerabilities identified by SAST have actually been fixed.

On the other hand, queries in SAST can extend coverage by analyzing code areas that are not accessed during IAST, as well as adding awareness of potentially vulnerable code areas and guiding the tester to extend IAST testing to cover such areas. The use of a single query language can reduce or eliminate the need for manual comparisons of SAST and IAST results.

Query Language.

The unified query language provided by embodiments of the present invention enables users to define their own procedures in a generic and flexible way. The same query format and rules are used for both static and dynamic testing systems, i.e., the format of the query is invariant when applied to any or all of SAST, DAST or IAST. However, the implementation of the queries and rules differ between the dynamic and static testing methods. For example, a query for SQL injection vulnerabilities in the unified query language results in an analysis of different type of data received from the static and dynamic tools.

The scheme for identifying such vulnerabilities applies to each type of data. The scheme is shown in FIG. 4, which is a diagram outlining the application of a common query language to expose vulnerabilities by SAST and IAST techniques. In upper branch 52 of the diagram, source code 54 is conditioned for SAST and application of query language 56 by construction of an object-oriented model, DOM 58 of the source code 54 by assigning respective identifiers to member variables. Based on the DOM 58 a control flow graph (not shown) and a control dependence graph (not shown) can be prepared and a data flow graph, DFG 60 derived from the control flow graph. The control flow graph, control dependence graph and data flow graph, or combinations and subcombinations thereof are analyzed to identify security vulnerabilities in the source code 54. Details of this process are known from the above-noted U.S. Pat. No. 9,128,728.

In lower branch 62 events 64 are collected at run-time of a program 66 prepared for execution from the source code 54. The events 64 are represented in a normalized format, comparable to the elements of the DFG 60 and analyzed for taint propagation in block 68. The result is a mutually compatible format for analysis of the source code 54 and the events 64. Queries submitted in the query language 56 may be addressed to an analysis of the DFG 60 or to the taint propagation analysis in block 68 or both of them. A query processor, discussed below, directs the queries to the appropriate analysis tool. The query language 56 is agnostic as to whether its queries concern the DFG 60 or the block 68.

For example, to look for SQL injection vulnerabilities, the user might define and apply the following query:

result=inputs.influencedAndNot Sanitized(db, sanitizers), where db is data being analyzed.

The same procedures in the query language are applied to databases containing both static and dynamic test results, for example queries of the form:

sources.influencingOnAndNotSanitized(sinks, sanitizers).

The data captured by dynamic testing, i.e., runtime testing, includes a data flow that can be reproduced during tests. Such tests can be manually initiated, automated, or can be a record in a production environment. In any case the tests can be analyzed by queries written in the unified query language in order to find security vulnerabilities.

Normalization of Data.

To apply the same query language to both SAST and IAST results, it is necessary that data provided by both testing system will be in a proper form for querying. The following sections will present some examples in this regard.

Regarding SAST, the following exemplary queries are directed to the DOM:

Query 1.

inputs=All.FindByMemberAccess(“HttpServerRequest.getQueryString”);

Query 1 finds in the source code all calls to method getQueryString in the instance of API HttpServerRequest.

Query 2.

• • db=All.FindByMemberAccess(“jdbc.exec”);

Query 2 finds in the source code all calls to method exec in an instance of the API jdbc.

Query 3.

replace=All.FindByMemberAccess(“String.replace”, “′”);

Query 3 finds in the source code all calls to the method replace of a method String, which replace an apostrophe in a string of characters.

Regarding IAST, queries evaluate events reported by the instrumented application during runtime. As in the case of SAST, events collected by IAST are organized in a DOM and a data flow model is produced based on the DOM for purposes of querying. The events are triggered and reported at instrumented locations in the code. Thus, for example, to run Query 1 on IAST events, the method HttpServerRequest.getQueryString should be instrumented prior to searching for query results. For this reason, applying the unified query language to the IAST tool should not only invoke a search for events after analyzing the application at runtime (post-action), but should also define the instrumentation of the application (pre-action). If a user writes a query like Query 1, then the dynamic testing tool 26 (FIG. 1) automatically generates instrumentation prior to running the application. Only after running the instrumented application, when relevant events have arrived, is the query actually applied and results analyzed.

To find some types of vulnerabilities, such as SQL Injection, using SAST, it is possible to use both the DOM and the Data Flow Graph, and to detect a vulnerability if there is a path between the node of an input API and the node of a database (DB) API that does not go through a node having a sanitizer API. Thus, to detect an SQL injection vulnerability, Queries 1-3 can first be applied to the DOM model in order to find relevant APIs of inputs, DB and sanitizers. All three queries produce a search of the DOM to find all code elements satisfying the queries.

After performing any portion of Queries 1-3, the following query can then be used to search for a path between the input API and of DB API that does not go through a sanitizer node:

Query 4.

• • result=inputs. InfluencingAndNotSanitized(db, replace);

In IAST there is no source code, and thus there is no DOM or Data Flow Graph built from the source code as for SAST. Therefore, in an embodiment of the present invention, the IAST data model is normalized to supply data in a form very similar to SAST, so that SAST queries can run without modification. The IAST Data Flow Graph is built not from the source code, but rather from instrumentation events that IAST creates during run-time of the application.

For example, when the code in Listing 1 is executed:

Listing 1
String s1 = “abc”;
String s2 = s1.toUpperCase( );

and there is instrumentation at the entry point of the method String.toUpperCase, the dynamic testing tool 26 will register a new event involving an application call to the method ‘toUpperCase’ with a value of ‘abc’.

Specifically, for the above example of detecting SQL Injection vulnerabilities, the dynamic testing tool 26 instruments the APIs of inputs, DB and sanitizers so when they are called, the dynamic testing tool 26 receives notifications. The SAST query presented above for SQL Injection vulnerabilities defines IAST instrumentation for three APIs:

• • API 1: HttpServerRequest.getQueryString.
  • API 2: jdbc.exec.
  • API 3: String.replace.

The query processor 28, upon receiving Query 4, instructs the dynamic testing tool 26 to instrument APIs 1-3. Now when the application runs with this instrumentation, events are generated each time one of these three APIs is called. These events contain metadata indicating, which API was called and with what parameter values. For example, when API 3 (String.replace) is called, the dynamic testing tool 26 generates an event reporting the call and the parameter values. Applying Query 4 can indicate if API String.replace was triggered on an apostrophe. After receiving all events from a run of the instrumented application, the dynamic analysis module 32 can correlate them in order to determine, for example, whether there is a reported event associated with input API 1 (HttpServerRequest.getQueryString) and a reported event associated with invocation of API 2 (jdbc.exec), without a reported event associated with replacement of an apostrophe by the method replace in API 3. In such a combination, the dynamic analysis module 32 would report an SQL injection vulnerability.

In a more specific scenario regarding Query 4, the dynamic analysis module 32 may process the following events:

• • 1. HttpServerRequest.getQueryString, param1=‘name’, return=‘Alex’ (meaning that the call to HttpServerRequest.getQueryString was executed with a parameter ‘name’ and it returned ‘Alex’).
  • 2. jdbc.exec, param1=‘select * from t where name=‘ALEX’’ (meaning that the call to jdbc.exec was executed with a parameter of an SQL statement).

When the dynamic analysis module 32 analyzes these events, it reports an SQL injection vulnerability, since there are events involving input and data without the subsequent sanitizer of a replace event. The processor can determine that the value ‘Alex’ was received via the input API and possibly was changed before being incorporated in an SQL statement by applying techniques of data taint propagation as described, e.g., in the document Dynamic Taint Propagation, Brian Chess et al., (21 Feb. 2008), available online. Data taint propagation provides a flow of connected events, including, for example, an ordered sequence of events representing the actual data flow from a source (like input) to sink (like a database) and all data propagators between them. In this example, the dynamic analysis module 32 would detect that ‘ALEX’ inside the SQL statement flowed from the value ‘Alex’ that was received from an input.

The dynamic testing tool 26 provides not only the events in executed methods, but also the sequence of calls connected to the propagation of the values.

Listing 2
String s1 = “abc”;
String s2 = s1.toUpperCase( );
String s3 = s2 + “def”;

When the code in Listing 2 is executed a trace would show that ‘abc’ was changed into ‘ABC’ by ‘ the method toUpperCase’ and then was concatenated with ‘def’ to eventually produce the string ‘ABCdef’.

A data propagator is a method that propagates a value from its inputs (parameters) to its output (return). For example the method ‘toUpperCase’ in Listing 2 is a data propagator. There are many propagators in the flow of data during execution of a program. When data enters an application from an external source (such as a user input), a source API is triggered to supply the data and mark it as “tainted.” Any data received from the outside is assumed to be tainted. Any propagator will propagate the taint of data it receives, with the exception of special sanitizer propagators: Once a flow passes through a sanitizer, the presumption that the data is tainted is overcome, and the data is regarded as untainted. However, if tainted data is received at the sink, it means that there is a flow from the source to the sink that has not passed through sanitization. Tainted data at the sink constitutes a security vulnerability.

Now by using instrumentation for methods of sources, sinks and propagators and using taint propagation analysis. To accomplish this, the dynamic testing tool 26 can extract sequences of method calls representing a flow of data from a source to a sink. Such flows contain nodes with method call information and edges representing propagation from one node to another.

Listing 3
String input = request.getQueryString(“name”);
String s = input.substring(1);
s = s.toUpperCase( );
s = “select * from t where name = “‘ + s + ’””;
jdbc.exec(s);

For example, the code in Listing 3 produces the following sequence of events:

• • request.getQueryString→String.substring→String.toUpperCase→concat→jdbc.exec.

This sequence is similar to a data flow graph, since it has the form of a connected graph in which nodes contain source commands, such as input and Output APIs, and there is a directed edge between two nodes if there is a data flow between the two corresponding commands.

We again consider queries 1-4, which are reproduced in Listing 4, but now in the context of IAST. SAST and IAST are not generally conducted simultaneously. Thus, query processor 28 is instructed in a given session to direct queries such as queries 1-4 to the dynamic testing tool 26, rather than the static testing tool 24.

Listing 4
inputs =
All.FindByMemberAccess(“HttpServerRequest.getQueryString”);
db = All.FindByMemberAccess(“jdbc.exec”);
replace = All.FindByMemberAccess(“String.replace”, “’”);
result = inputs.InfluencingAndNotSanitized(db, replace);

The queries of Listing 4 search for sequences of events starting from an input API (getQueryString), not passing through a sanitizer API (replace), and ending with the DB API (exec) (not shown in Listing 4). The syntax of the queries of Listing 4 is the same as in the SAST application applied to queries 1-4, but a different, complementary search is invoked when these queries are applied to runtime events. By instrumenting sources, sinks and propagators and using taint propagation techniques, it is possible to create a sequence of events in a format substantially identical to the SAST Data Flow Graph, and thus use the same queries for both SAST and DAST.

Example.

The following is an example of how an SAST Query Language, such as the above-mentioned language CxQuery, can be used in querying IAST results, without changing the query syntax. For this purpose, the dynamic testing tool 26 should supply the following data in connection with relevant events:

1). Information concerning an HTTP request containing URL, inputs, headers body, as shown in Listing 5.

2.) Information regarding data propagation, such as file name, line, method name, type name, and other propagation information

Listing 5
“url”:
“http://10.0.0.128:8090/WebGoat/attack?Screen=101829144&men
u=1100”,
“httpMethod”: “POST”,
“httpHeaders”:”content-length=22
referer=http://cxiast.ddns.net:8090/WebGoat/start.mvc accept-
language=en-US, en; q=0.8
cookie=JSESSIONID=3A69A5CCC5015995ACE9D1D551777AD7
origin=http://cxiast.ddns.net:8090 host=cxiast.ddns.net:8090 x-
requested-with=XMLHttpRequest connection=keep-alive content-
type=application/x-www-form-urlencoded; charset=UTF-8 accept-
encoding=gzip, deflate accept=*/* user-agent=Mozilla/5.0
(Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/55.0.2883.87 Safari/537.36”,
“httpBody”:
“Screen=101829144&menu=1100&station=102&SUBMIT=Go!”,
“httpParamName”: “station

Listing 6 is a trace of data provided by an IAST tool such as the dynamic testing tool 26 on which an SQL injection query can be run and can detect the presence of an SQL injection vulnerability. The format of the data in Listing 6 is normalized to the format of data used in SAST analysis. Thus, IAST queries input to query input module 22 in a query language such as CxQuery, can be processed by the query processor 28 and the dynamic analysis module 32, just as the query processor 28 and static analysis module 30 treat SAST queries.

The trace in Listing 6 contains four steps, starting from input and ending with DB. Based on data collected from the monitored application during runtime by IAST instrumentation, the query processor 28 is able to apply the query language, determine that dynamic testing tool 26 is appropriate for testing, and cause the presence of a vulnerability to be detected by the dynamic analysis module 32.

Listing 6
{
“sequenceId”: 0,
“file”: “org/owasp/webgoat/session/ParameterParser.java”,
“line”: 503,
“methodName”: “getParameterValues”,
“typeName”: “javax.servlet.ServletRequest”,
“value”: “102”,
“taintedStartIndex”: 0,
“taintedEndIndex”: 2,
“codeSnippet”: “ String[ ] values =
this.request.getParameterValues(name);”,
“paramValue”: “station”
},
{
“sequenceId”: 1,
“file”: “org/owasp/webgoat/lessons/SqlNumericInjection.java”,
“line”: 105,
“methodName”: “append”,
“typeName”: “java.lang.StringBuilder”,
“value”: “SELECT * FROM weather_data WHERE station = 102”,
“taintedStartIndex”: 43,
“taintedEndIndex”: 45,
“codeSnippet”: “ query = “SELECT * FROM weather_data WHERE
station = “ + this.station;”,
“paramValue”: “102”
},
{
“sequenceId”: 2,
“file”: “org/owasp/webgoat/lessons/SqlNumericInjection.java”,
“line”: 105,
“methodName”: “toString”,
“typeName”: “java.lang.StringBuilder”,
“value”: “SELECT * FROM weather_data WHERE station = 102”,
“taintedStartIndex”: 43,
“taintedEndIndex”: 45,
“codeSnippet”: “ query = “SELECT * FROM weather_data WHERE
station = “ + this.station;”
},
{
“sequenceId”: 3,
“file”: “org/owasp/webgoat/lessons/SqlNumericInjection.java”,
“line”: 118,
“methodName”: “executeQuery”,
“typeName”: “java.sql.Statement”,
“value”: “SELECT * FROM weather_data WHERE station = 102”,
“taintedStartIndex”: 43,
“taintedEndIndex”: 45,
“codeSnippet”: “ ResultSet results = statement.executeQuery(query);”,
“paramValue”: “SELECT * FROM weather_data WHERE station = 102”
}

It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof that are not in the prior art, which would occur to persons skilled in the art upon reading the foregoing description.

Claims

1. A computer-implemented method for detecting security vulnerabilities in a computer program, comprising the steps of: receiving, into a memory of a computer, source code of at least one computer program to be analyzed;preparing a first data flow graph from the source code of one or more of the at least one computer program, using a static testing analysis;defining instrumentation for specific runtime event collection for the computer program during execution utilizing a unified query language;applying the instrumentation to one or more of the at least one computer program;preparing a second data flow graph from collected runtime events obtained from executing the instrumented one or more of the at least one computer program;normalizing results from the generated static testing analysis and from the execution of the instrumented one or more of the at least one computer program;applying one or more user received queries to the results, wherein the user received queries are in a query language; anddisplaying in a reporting manner, identified security vulnerabilities in one or more of the at least one computer program, wherein the identified security vulnerabilities are based on the results of the user received queries.

2. A data processing system for detecting security vulnerabilities in a computer program comprising: a processor;a memory accessible to the processor storing program instructions and data objects therein; andan I/O facility linked to the processor;wherein execution of the program instructions cause the processor to perform the steps of:accepting via the I/O facility queries in a query language;receiving via the I/O facility into the memory source code of at least one computer program to be analyzed;preparing a first data flow graph from the source code of one or more of the at least one computer program, using a static testing analysis;defining instrumentation for specific runtime event collection for the computer program during execution utilizing a unified query language;applying the instrumentation to one or more of the at least one computer program;preparing a second data flow graph from collected runtime events obtained from executing the instrumented one or more of the at least one computer program;normalizing results from the generated static testing analysis and from the execution of the instrumented one or more of the at least one computer program;applying one or more user received queries to the results, wherein the user received queries are in a query language; anddisplaying in a reporting manner, identified security vulnerabilities in one or more of the at least one computer program, wherein the identified security vulnerabilities are based on the results of the user received queries.

3. The system according to claim 2, wherein preparing the second data flow graph comprises organizing the collected runtime events in a hierarchical Document Object Model (DOM) and producing the second data flow graph based on the DOM.

4. The system according to claim 2, wherein defining the instrumentation comprises defining the instrumentation of the one or more of the at least one computer program responsive to a received query, which is applied to the second data flow graph after executing the instrumented one or more of the at least one computer program.

5. The system according to claim 2, wherein preparing the second data flow graph comprises preparing the second data flow graph in a form very similar to the form of the first data flow graph using the static testing tool, such that queries prepared for the form of the first data flow graph can run on the second data flow graph without modification.

6. The system according to claim 2, wherein collecting runtime events comprises generating an event each time an instrumented Application Programming Interface (API) is called in running the program and collecting for each event an indication of the API called and parameter values with which the API was called.

7. The system according to claim 2, wherein preparing the second data flow graph comprises forming a graph in which nodes contain source commands and a directed edge is placed between two nodes if a data flow occurred between the two corresponding commands of the nodes.

8. The system according to claim 2, wherein applying the received queries comprises applying a specific query to both the first and second data flow graphs.

9. The method according to claim 1, wherein preparing the second data flow graph comprises organizing the collected runtime events in a hierarchical Document Object Model (DOM) and producing the second data flow graph based on the DOM.

10. The method according to claim 1, wherein defining the instrumentation comprises defining the instrumentation of the one or more of the at least one computer program responsive to a received query, which is applied to the second data flow graph after executing the instrumented one or more of the at least one computer program.

11. The method according to claim 1, wherein preparing the second data flow graph comprises preparing the second data flow graph in a form very similar to the form of the first data flow graph using the static testing tool, such that queries prepared for the form of the first data flow graph can run on the second data flow graph without modification.

12. The method according to claim 1, wherein collecting runtime events comprises generating an event each time an instrumented Application Programming Interface (API) is called in running the program and collecting for each event an indication of the API called and parameter values with which the API was called.

13. The method according to claim 1, wherein preparing the second data flow graph comprises forming a graph in which nodes contain source commands and a directed edge is placed between two nodes if a data flow occurred between the two corresponding commands of the nodes.

14. The method according to claim 1, wherein applying the received queries comprises applying a specific query to both the first and second data flow graphs.

15. The method according to claim 1, wherein applying the instrumentation comprises instrumenting at points of input and output of the computer program.

16. The system according to claim 2, wherein applying the instrumentation comprises instrumenting at points of input and output of the computer program.