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

An example of successful attack is represented by an HTML request containing
the parameter param set to the subsequent JavaScript code:
< a href="" onclick="this.href= 'www.evil.com?data=
'%2Bdocument.cookie" > click here < /a >
When such value is appended to the response page, it alters its HTML struc-
ture (%2B is decoded as “+”), injecting a brand new link “ click here ” (i.e.,
< a > tag) which points to an external web site controlled by the attacker (i.e.,
www.evil.com ). In case such link is triggered by the legitimate user, his/her cookie
is encoded as an HTML request parameter and sent to the attacker-controlled
web site. With the stolen cookie, the attacker may pretend to impersonate the
legitimate user.
The automatic generation of input values to test such a vulnerable page can be
addressed in quite a cheap way by applying a number of different strategies. After
input generation, however, output needs to be validated, i.e. a security oracle
is required to check whether code injection has taken place. In the subsequent
sections we present our approach to use kernel methods to implement a security
oracle, i.e. to classify executions of dynamic web pages as safe executions or as
successful code injections. In the latter case, a concrete vulnerability is detected.
3ScuyOe
The goal of an XSS attack is to inject JavaScript or HTML code fragments into
a web page. Thus, consequences of a successful injection should be evident as
structural changes in the page under attack, when compared with the same page
running under normal conditions.
Web applications, however, are highly dynamic and their structure or content
may vary a lot, even without code injection. For instance, on the running example
of Figure 1, the same PHP script under harmless conditions can display different
results (number of table rows) and can take different alternative actions (showing
a table or a menu).
A web page can be represented by the parse tree of the corresponding HTML
code, thus injection of malicious code corresponds to a change in the parse tree
with respect to the intended structure. Figure 2 shows the parse trees of three
HTML outputs of the running example: Figure 2(a) and (b) show the parse trees
of safe executions that contain, respectively, a table with three rows and a menu
with tree links. Figure 2(c), instead, represents the parse tree of the same page
under attack, a menu with two intended links and, in addition, a malicious link.
By looking at Figure 2, we can observe that the intrinsic variability of safe exe-
cutions (e.g., between (a) and (b)) can be wider than the variability due to code
injection (e.g., between (b) and (c)). So, a similarity metric may not be adequate
to detect successful attacks. The security oracle should distinguish between those
variations that are safe due to the dynamic behavior of the application under
test and those variations caused by code injection due to successful attacks.
The classifier must be trained with instances of parse trees taken from both the