Security Oracle Based on Tree Kernel Methods - Trustworthy Eternal Systems via Evolving, Software Data and Knowledge - page 36

to make a tainted value flow to a sink statement, skipping validation routines.
The data slice for the vulnerability shown in Figure 1 is composed by lines

{

1,

}

15 , because the variable $p is assigned the input data param at line 1 and it is

printed later at line 15.
On top of this information, we also collect all those control statements that
hold a control dependence on the statements in the data slices, since they are
responsible to guide the execution along to or away from a vulnerable path.
These statements are the branches to traverse in order to make a tainted value
reach a sink statement, they are called target branches . Target branches for the
example shown in Figure 1 are , where the former (4-6) is needed to

avoid the termination of the script and the latter (6-8) to skip the sanitization
of the variable $p at line 7 that would break the data slice and stop propagating
the tainted value before reaching the sink statement.
Target branches represent a vulnerability coverage criterion for the security
testing activity. A test exposes a vulnerability only when it makes the execution
take all the corresponding target branches.

{ 4-6, 6-8 }

3.2 Test Case Generation

In order to generate test cases that satisfy the vulnerability criteria defined by
static analysis, we rely on a tool we developed in previous works [1,2] that inte-
grates heuristics (Genetic Algorithms) and analytic solutions (SMT solver). Many
test case generation approaches, however, exist in the literature [18,12,13,9,8,11]
and any of them is, in principle, applicable to this context. Alternatively, test cases
can be also manually written, for example by translating the application use cases
into test cases.
It could happen, however, that the test generation phase computes just few
(or just one) test cases for each vulnerability criterion. More distinct test cases
are needed to train the classifier with an appropriate level of generality. Then, to
increase the number of total tests available, we mutate the initial set of test case(s)
by using few mutation operators that have been previously implemented.
Since the focus of this paper is on the security oracle, we will not give more
details of the test case generation part, and we will use the available tool as a
black box. More details about this phase can be found in previous works [1,2].

3.3 Attack Generation

For turning security test cases into code injection exploits, attack strings are
injected into test input data. Attack strings come from a library of fragments of
typical attacks (e.g., HTML tags containing scripts and links) that have been al-
ready used in penetration testing and in black-box fuzzing [17]. When requested,
an attack fragment is randomly chosen from the library and injected into one of
the parameter values of an original test case. Then, the newly created candidate
attack is executed to check if it still traverses all the target branches .