[Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.
Advances in Electrical and Computer Engineering
WAPTT - Web Application Penetration Testing
Tool
Zoran ĐURIĆ
Faculty of Electrical Engineering, University of Banjaluka, 78000 Banja Luka,
Bosnia and Herzegovina
zoran.djuric@etfbl.net
1
Abstract—Web applications vulnerabilities allow attackers
to perform malicious actions that range from gaining
unauthorized account access to obtaining sensitive data. The
number of reported web application vulnerabilities in last
decade is increasing dramatically. The most of vulnerabilities
result from improper input validation and sanitization. The
most important of these vulnerabilities based on improper
input validation and sanitization are: SQL injection (SQLI),
Cross-Site Scripting (XSS) and Buffer Overflow (BOF). In
order to address these vulnerabilities we designed and
developed the WAPTT (Web Application Penetration Testing
Tool) tool - web application penetration testing tool. Unlike
other web application penetration testing tools, this tool is
modular, and can be easily extended by end-user. In order to
improve efficiency of SQLI vulnerability detection, WAPTT
uses an efficient algorithm for page similarity detection. The
proposed tool showed promising results as compared to six
well-known web application scanners in detecting various web
application vulnerabilities.
Index Terms—databases, security, vulnerabilities, web sites,
web applications.
I. INTRODUCTION
The main reason for most of the web applications
vulnerabilities is the lack of, or failure of, proper client input
validation and sanitization. These vulnerabilities can be
classified as input manipulation, and the most important are:
SQL Injection (SQLI), Cross-Site Scripting (XSS), and
Buffer Overflow (BOF) [1-3]. Web applications
vulnerabilities, like SQLI, XSS and BOF, are acknowledged
problems with thousands of them reported each year [4].
These vulnerabilities allow attackers to perform different
malicious actions that range from obtaining sensitive data
(such as social security numbers, credit card numbers, etc.)
to gaining unauthorized account access. Section II gives a
detail explanation of these vulnerabilities.
There are different techniques for the identification of
web applications vulnerabilities. The two most important are
[5]:
 static security analysis. This technique is based on
analyzing the source code of the application looking for
potential security vulnerabilities. This approach is
known as “whitebox” approach.
 dynamic security analysis. This technique is based on
discovering security vulnerabilities in web application
by testing the application from the point of view of the
attacker. This approach is known as “blackbox”
approach.
Both techniques can be performed manually or by using
Digital Object Identifier 10.4316/AECE.2014.01015
1582-7445 © 2014 AECE
Volume 14, Number 1, 2014
automated tools.
Dynamic security analysis tools are automated tools that
probe web applications for security vulnerabilities, without
access to source code of the applications. Although there are
limitations of these tools, in comparison with static security
analysis tools, dynamic security analysis tools also have
some advantages [4]. Dynamic security analysis is
independent of the application source code and platforms
and provides a promising scalable method for web
application security [4-6].
It is important to mention that static and dynamic
approaches can be combined [7-10]. Still, the focus of our
research is a dynamic approach in the identification of web
applications vulnerabilities, i.e. our primary goal was to
develop a reliable web application penetration testing tool
(black-box vulnerability scanner). Section III gives an
overview of some of the existing web application
penetration testing tools and discusses their advantages and
disadvantages.
Section IV describes the approach that we used for black-
box testing of web applications, which is implemented in
WAPTT (Web Application Penetration Testing Tool) tool.
This approach consists of the following five phases: web
crawling, application entry point’s detection and extraction,
testing, analysis, and report generation.
The WAPTT implementation is described in detail in
Section V. A very important property of this tool is that it is
modular, and can be easily extended by end-user. Also,
WAPTT uses an efficient algorithm for page similarity
detection, needed for SQLI vulnerability detection.
Evaluation of the web application scanner tools is always
challenging. Before concluding the paper, we compared
WAPTT against six well-known web application scanners.
The evaluation process and obtained results are described in
detail and presented in Section VI.
II. WEB APPLICATIONS VULNERABILITIES
In current web development practices, input validation
and sanitization routines are very often placed by developers
manually in an ad-hoc way [6]. This can be either
incomplete or erroneous, and thus introduce vulnerabilities
into the web application. Missing input validation and
sanitization allows malicious input to flow into trusted web
contents. Similarly, faulty sanitization allows malicious user
input to bypass the validation procedure. A web application
which fails to achieve the input validity property is
vulnerable to a class of attacks, which are referred to as
input validation attacks. These types of attacks embed
93
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
malicious contents within HTTP (HyperText Transfer
Protocol) requests, which are utilized by the web application
and executed, currently or later. Examples of input
validation attacks include XSS, SQLI, BOF, etc. They are
distinguished by the locations where malicious contents get
executed.
In this section, the three most popular input validation
attacks are described.
A. XSS
XSS vulnerability occurs when a web application accepts
client-supplied input that contains JavaScript code, and
includes that invalidated input in a resulting HTML (Hyper
Text Markup Language) page sent to the client. This way
potentially malicious JavaScript code can be executed inside
client’s web browser.
XSS is one of the most common security vulnerabilities in
web applications today [11]. On the other hand, this should
not be the case as XSS is relatively easy to find and
relatively easy to fix. XSS vulnerabilities can have various
consequences such as sensitive data tampering or theft,
account hijacking, web worms spread and remote
controlling of client’s web browser.
There are two main types of XSS: reflected (also known
as first-order, or Type 1 XSS) and persistent XSS (also
known as stored, second-order, or Type 2 XSS).
Reflected XSS (first-order XSS). A reflected XSS
vulnerability results from the web application inserting
client-supplied input, or part of that input, in the HTML
page that it renders. This way malicious JavaScript code is
executed inside web browser of the client which initiated
XSS attack. Because of the nature this XSS type, an attacker
must use other communication channels to distribute this
attack to the legitimate clients of particular web application.
For example, the attacker can use phishing email to
convince a victim to click on a disguised URL that contains
malicious JavaScript code. In order to prevent reflected XSS
attacks, applications need to reject input values that may
contain JavaScript code.
Persistent XSS (second-order XSS). A persistent XSS
vulnerability results from the application storing the
attacker’s input (or part of that input) in a database, and then
later retrieving it from the database and inserting it in an
HTML page that is displayed to multiple victims. It is harder
to prevent persistent XSS than reflected XSS, because
applications need to reject or sanitize input values that may
contain JavaScript code, as well as to use different
techniques to reject or sanitize input values that may contain
SQL code and are used in database commands.
Persistent XSS is much more damaging than reflected
XSS. This is mainly because the phishing technique or other
social engineering techniques are not required (the attacker
can directly supply the malicious input without tricking
users into clicking on a URL that contains malicious
JavaScript code), and because a single malicious JavaScript
code inserted once into a database can be executed in
browsers of many victims.
B. SQL Injection
SQLI occurs when an attacker attempts to change the
semantics of a legitimate SQL statement by inserting new
SQL keywords, operators and statements (or their parts) into
94
Volume 14, Number 1, 2014
the original SQL statement through unvalidated
(unsanitized) input. There are many variants of SQL. Most
dialects are based on the ANSI standard SQL-92 [12]. The
typical unit of execution in the SQL language is the query, a
collection of statements that are aimed at retrieving data
from the database or manipulating records in the database.
An SQL query typically results in a single result set that
contains the query results. Apart from data retrieval and data
manipulation, SQL statements can also modify the structure
of database using DDL (Data Definition Language)
statements [12].
There are different types of SQLI attacks. SQLI includes,
but is not limited, to attacks based on tautologies, injected
additional statements, exploiting untyped parameters, stored
procedures, overly descriptive error messages, alternate
encodings, length limits, second-order injections and
injection of “UNION SELECT”, “ORDER BY” and
“HAVING” clauses. A detailed explanation of different
forms of SQLI attacks and ways in which they can be
exploited are given in Section IV. Similar explanations are
also available in the public domain [13, 14].
It is very important to notice that SQLI vulnerabilities can
also be divided into two sub-classes: first-order and second-
order, for the same reason as dividing the XSS classification
[4]. It is important to notice that second-order attacks are
very hard to detect.
C. Buffer Overflow
A buffer overflow occurs when an application tries to
store more data in a buffer than it was intended to hold. As
buffers are created to contain a finite amount of data, the
extra information - which can’t be put in a buffer - can
overflow into adjacent buffers, corrupting or overwriting the
valid data held in them.
Many types of buffer overflow exist. For example, a
parameter overflow means that the attacker is able to supply
data as a parameter to the execution of an application. When
the application expands the supplied data, if the size of the
parameter is not correctly checked, it may exceed a set limit
allowing the attacker to overflow the buffer and write data
into memory.
Buffer overflow can have various consequences such as
DoS (Denial of Service), information disclosure, loss of
integrity, and complete admin access.
III. EXISTING WEB APPLICATION PENETRATION TESTING
TOOLS
Most academic research on tools for detection of web
applications vulnerabilities has been static source code
analysis, with a focus on detecting XSS and SQLI via
modeling checking analysis, information flow, or via their
combination [4]. Work by Wassermann [15], Lam [16],
Kiezun [2], Jovanovic [17], and Huang [18] all fall into this
category.
Unlike static source code analysis, dynamic security
analysis does not require the application’s source code.
Dynamic security analysis tools (Web vulnerability
scanners, black-box scanners) crawl and scan for web
application vulnerabilities, usually by using software agents.
These tools perform attacks against web application under
testing. The responses are later analyzed in order to detect
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
any existing vulnerabilities. This type of testing is also
known as penetration testing.
Currently, there is a wide range of tools that can be used
to detect vulnerabilities in web applications. Besides white-
box and black-box tools, there are also a hybrid tools which
combine static source code analysis and dynamic security
analysis techniques. Hybrid tools, as well as white-box tools
are out of the scope of this paper. Although it is difficult to
generate precise attack input that can reveal input
manipulation vulnerabilities, without exact knowledge about
the internal structure of the application, this is one of the
main tasks that black-box tools should do.
Kals et. al. [19] implemented dynamic security analysis
tool SecuBat for SQLI and XSS detection, while McAllister
et. al. [21] implemented tool utilizing user interactions to
generate more effective test cases targeting reflected and
stored XSS. Maggi et. al. discussed techniques to reduce
false positives in automated intrusion detection, which is
applicable to black-box scanning [22].
Besides tools described in research papers, there are also
commercial and open-source tools. Some of the most
popular commercial vulnerability scanners are Acunetix
Web Vulnerability Scanner, HP Webinspect and IBM
Rational AppScan . All three can detect SQLI, XSS and
BOF vulnerabilities, as well as other vulnerabilities.
Also, there is a wide range of open-source scanners such
as vega, w3af, wapiti, Nikto and BurpSuite. Vega can detect
SQLI, XSS, inadvertently disclosed sensitive information,
and other vulnerabilities. It is GUI-based (Graphical User
Interface) tool written in Java, and runs on Linux, OS X, and
Windows. Vega can be extended using its JavaScript API.
W3af (Web Application Attack and Audit Framework) is a
free open source web application scanner designed and
implemented for finding and exploiting web application
vulnerabilities. Wapiti is also web application scanner
designed and implemented to audit the security of web
applications. It does not provide a GUI for the moment and
must be used from a terminal. Both w3af and wapiti are
written in Python. These tools don’t rely on a vulnerability
database like Nikto do. Nikto performs comprehensive tests
against web servers for multiple items. It will test a
web/application server in the quickest time possible, as it is
not designed as an overly stealthy tool.
Existing Web application scanners are usually based on
pre-defined rules to detect potential security vulnerability in
the tested web application. Most of today’s Web application
scanners focus on security-vulnerability detection using
known defects recorded in vulnerability databases, such as
OSVDB (Open Source Vulnerability Database). For
example, OSVDB is used by Wikto and Nikto2, two open-
source Web application scanners. These scanners use
OSVDB to scan for possible existence of directories and
files that malicious users usually try to find and treat as an
entry point (for example /admin directory) [4]. Similarly,
some scanners like Accunetix and Wikto use Google
Hacking Database to search for signatures of online
websites.
Besides these database-based detections, some of the
most popular scanners provide rule-based SQL and XSS
injection detection capabilities, i.e. they have a huge
attacking vectors base, through which they can construct
Volume 14, Number 1, 2014
hundreds or thousands of attacking exploits. Examples of
these scanners are AppScan, ZAP Proxy (OWASP Zed
Attack Proxy Project) and Paros Proxy. AppScan also uses
Google Hacking Database.
All of these tools try to identify all points in a web
application that can be used to inject malicious code. They
build attacks that target these points and monitor how the
application responses to the generated attacks.
Assessment of results collected during SQL injection test
is not so simple task. Still, some tools use very naive
techniques for test-result assessment. For example, AppScan
is capturing error messages such as “OleDbException” to
determine whether an SQL error happens, while Paros Proxy
searches for “SQL”, ”ODBC”, “JDBC” and similar strings
[25]. Such an approach can cause high number of false
alarms. Paros Proxy reported 48 high-risk alerts for
MvnForum, but all of them were false alarms because
MvnForum uses search engine optimization technologies
such as adding popular keywords (including “JDBC” and
“MySQL”) in meta tags of every page [4].
IV. OUR APPROACH
Based on advantages and disadvantages of existing web
application scanners, the objectives for WAPTT tool are
created. The most important objective for WAPTT tool is
efficient web applications vulnerabilities detection,
especially those vulnerabilities resulting from improper
input validation and sanitization. Besides that, WAPTT tool
should be modular, and easily extensible by end users. There
is no modular vulnerability scanner known to the author that
can be easily extended by end user.
Web Application entry
points detection and Testing
crawling
extraction
YES
Report Authentication Analysis
generation bypassed?
NO
Figure 1. Our dynamic security analysis approach.
Our dynamic security analysis approach is based on
simulation of attacks against web applications, and is
performed as black-box testing approach. Thus the scope of
analysis is limited to HTTP responses received from the
server side. Similarly, as per the reported designs commonly
found in other systems [19], our dynamic security analysis
approach comprises the following phases (Figure 1): web
crawling, application entry points detection and extraction,
testing, analysis, and report generation.
A. Phase 1 – Web crawling
Identification of all pages being part of the tested web
application is crucial for dynamic security analysis, as
attacks could be launched only against recognized
application entry points [23]. This is why we try to explore
all the available web pages by visiting all the links. This task
can be done automated (using web crawlers), manually or
semi-automated.
95
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
Web crawler can be configured to use valid user
credentials (e.g. valid username and password). This allows
the web crawler to go beyond the login web page and
explore all web application pages. Similarly, if login form
can be successfully bypassed, the web crawler will also
explore all web application pages (Figure 1). Web crawler
can be configured in such a way to recognize and avoid
visiting links that will logoff the crawler or destroy the
current session. This feature is implemented in a generic
way using regular expression to create the set of links to be
ignored.
In many cases, automated web crawling of the web
application will not be complete. The reason for this is that
automated web crawler does not reach all the application
HTML pages because modern web applications use partial
page refresh, asynchronous requests and can have various
authentication and authorization mechanisms. As an
addition to the automated web crawling, we perform the
manual navigation to explore all possible scenarios. All
HTML pages identified in this phase will serve as an input
into Phase 2.
B. Phase 2 – Application entry point’s detection and
extraction
The parts of the web pages visited in Phase 1 which are of
interest for our approach are application entry points.
Generally, the main disadvantage [24] of automated
penetration testing tools is poor coverage of application
entry points. This is why, in Phase 2, we try to extract all
application entry points from pages visited in Phase 1.
Application entry points are mainly forms with their
elements (and constrains) which are filled by end users.
Also, we collect all anchors/links with parameters, i.e. GET
parameters.
To extract all application entry points and collect the list
of them, along with their constraints, all web pages visited
in Phase 1 should be parsed and analyzed. Each web page is
analyzed in order to detect and extract all the forms and
anchors/links with parameters. The forms are parsed to
discover their elements. Every form element may contain
some predefined constraint(s). The most important
constraints for our approach are constraints of:
 <form> element: method (specifies how to send form-
data – using HTTP GET or HTTP POST method) and
action (specifies where to send form-data), and
 <input> element: disabled (specifies that an <input>
element should be disabled), max (specifies the
maximum value for an <input> element), maxlength
(specifies the maximum number of characters allowed),
min (specifies the minimum value for an <input>
element), multiple (specifies that a user can enter more
than one value), pattern (specifies a regular expression
that an <input> element's value is checked against),
readonly (specifies that an input field is read-only),
required (specifies that an input field must be filled out
before submitting the form), value (specifies the value
of an <input> element).
Although not all of this constraints are supported in all
today’s web browsers, we use all of them as an important
information for generation of HTTP requests sent to the web
application during testing phase (Phase 3).
96
Volume 14, Number 1, 2014
Regarding anchors/links with parameters, we parse every
anchor/link end extract all parameters and their values.
C. Phase 3 – Testing
In Phase 3 we simulate attacks against tested web
application. For every application entry point we generate
one set of valid parameter values. WAPTT uses these valid
values to generate HTTP request. The result of this request
is reference HTML page. Additionally, for every application
entry point we generate many sets of malicious or incorrect
parameter values. More precisely, we create parameter
values which violate predefined constraints of parameters.
Also, we use predefined attack patters as parameter values.
Malicious or incorrect parameter values are used by
WAPTT to generate additional HTTP requests. The results
of these requests are additional HTML pages, which are,
along with the reference HTML page, used in Phase 4.
The way the malicious or incorrect parameter values are
generated (for one application entry point) is different for
every type of vulnerability we are checking for.
Consequently, the sets of malicious or incorrect parameter
values are different for every type of vulnerability WAPTT
checks for. Now, we will describe the way these values are
created for every type of vulnerability.
1) SQLI attack parameter values
There are some study works on SQLI vulnerability
detection and many tools have been developed and used, for
example, WebInspect [8], Pangolin, WVS [10], WebScarab
[13], AppScan [14] nad Nikto. All these tools take the
approach of SQLI vulnerability detection similar to the tool
we implemented.
Based on type of a parameter value detected in Phase 2,
we create different attack patterns. Generally, for text type
parameters, we use attack patterns that require a single
quotation mark. A small subset of these attack patters is
given in Figure 2.
admin' --
' or 1=1--
') or '1'='1--
' UNION SELECT 1, 'admin', 'xz', 1—
Figure 2. A small subset of SQL attack patterns with a single quotation
mark.
Similarly, for integer type parameters, we use attack
patterns that doesn’t require a single quotation mark. A
small subset of these attack patters is given in Figure 3.
1 OR 1=1--
1; drop table test --
1; drop table test; create table test (name
varchar(10)) --
1; delete from test;--
Figure 3. A small subset of SQL attack patterns without a single quotation
mark.
There are numerous variations of each SQLI attack type.
This is why we present only a few most important supported
by WAPTT.
Tautologies. The most common usages of tautology-
based attacks are authentication bypassing and data
extraction, although it can be used for identifying injectable
parameters also. WAPTT tries to exploit an injectable field
that is used in a SQL query WHERE clause. For example,
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
for bypassing login form WAPTT uses “‘ or 1=1 --“ attack
pattern and it’s variants (taken from WAPTT attack
pattern’s database). This way an SQL statement related to
user login process can become as follows:
SELECT * FROM users WHERE username=’’ or 1=1
-- AND password=’’
Because “--” is the SQL comment operator and because
“1=1” always evaluates to true, inserted attack pattern
transforms the entire WHERE clause into a tautology and
the complete query evaluates to true.
Illegal/Logically Incorrect Queries. This type of attack
can be used for injectable parameters identification,
database finger-printing and data extraction. WAPTT tries
to modify original statements in such a way that the
resulting statements will be logically incorrect. These
statements will be rejected, and error messages will be
returned from the database. Sometimes these error messages
include useful debugging information, like database name,
table and field names. WAPTT inserts rubbish input or SQL
tokens in the original statement in order to produce syntax
errors, type mismatches, or logical errors. For example, in
order to make a type mismatch error WAPTT can add single
quotation mark onto valid integer. This way a corresponding
SQL statement can become as follows:
SELECT * FROM users WHERE user_id = 145’;
The error message produced by this query can contain
very useful information including a whole incorrect SQL
statement, database server type and version, etc.
Union queries. This type of attack can be used for
authentication bypassing and data extraction. By inserting a
statement of the form UNION SELECT
<the_rest_of_inserted_query>, WAPTT tries to cheat the
application into returning data from a table different from
the one that was intended by the application developer.
More precisely, the result of this attack is the union of the
results of the original SQL query and the results of the
inserted SQL query. For example, for data extraction from
known database table WAPTT uses “ ’ UNION SELECT
<known_field_name> FROM <known_table_name>” attack
pattern and it’s variants (there can be more than one known
field name). This way a corresponding SQL statement can
become as follows:
SELECT first_name, second_name FROM users
WHERE username=’’ UNION SELECT
credit_card_number, expiration_date FROM
credit_card -- AND password=’’
In this example, inserted attack pattern changes the
semantics of the original statement. As a consequence, the
database would take the results of both queries, union them,
and then return them to the application.
PiggyBacked Queries. This type of attack can be used
for data extraction, data addition or modification, denial of
service and remote commands execution. During execution
of this attack, WAPTT tries to inject additional query
besides the original query. As the result of this attack, the
database receives multiple SQL queries. For example, for
dropping of a known database table WAPTT uses “'; DROP
TABLE <known_table_name>--” attack pattern. This way a
corresponding SQL statement can become as follows:
SELECT * FROM users WHERE username=’’; DROP
TABLE users -- AND password=’’
In this example, two SQL statements will be executed in
Volume 14, Number 1, 2014
one query, if there is a support for execution of multiple
queries in one statement.
Inference attack. This type of attack can be used for data
extraction, identification of injectable parameters and
database schema determination. Typical attack techniques
that are based on inference are: blind injection and timing
attack. When performing inference attack, WAPTT injects
different commands into the application and then “observes”
application responses. By detecting when the application
behaves the same and when its behavior changes, WAPTT
can “conclude” whether certain parameters are vulnerable,
as well as additional information about the values in the
database. In a case of blind SQLI, when statement injected
by WAPTT evaluates to true, the application continues to
function normally, but when statement injected by WAPTT
evaluates to false, the returning page differs significantly
from the normally-functioning page.
For example, to detect injectable parameter using blind
SQLI WAPTT uses following partial statements:
“<known_legal_value(s)_of_parameter(s)> ’ and/or 1=0 --“
and “<known_legal_value(s)_of_parameter(s)> ’ and/or 1=1
--“. This way, based on the original SQL statement, we can
get two SQL statements as follows:
SELECT first_name, second_name, address FROM
users WHERE username=’ <known_legal_value_of
_parameter>’ and 1=0 --AND password=’’
SELECT first_name, second_name, address FROM
users WHERE username=’ <known_legal_value_of
_parameter>’ and 1=1 --AND password=’’
Suppose we have a secure application and that the input
value for username is validated correctly. Then, both
statements will return the same result meaning that
username parameter is not vulnerable. On the other hand, if
we have an unsecure application (that doesn’t validate
correctly the input value for username) these two statements
will return different results meaning that username
parameter is vulnerable to injection.
Detection of second-order SQLI. As it is already
mentioned, second-order SQLI attacks are very hard to
detect. Some tools, even in cases when they successfully
perform second-order SQLI, can’t detect it. WAPTT does
second pass off all pages in order to find injected strings in
resulting HTML code. It is also very important to notice that
in some situations, where successfully executed SQLI attack
changes values of database fields which are not shown in
any application HTML page, there is no way to detect this
successful execution.
2) XSS attack parameter values
Based on previous researches and projects [11], we
created a long list of XSS attack patterns. A small subset of
these attack patters is given in Figure 4. WAPTT database
contains over 100 XSS attack patterns. In this phase
(Testing phase), valid values are replaced by malicious
values taken from WAPTT database. Usage of this set of
values may result in an attack if supplied to a vulnerable
input parameter.
It is very important to mention that SQLI and XSS attack
patters can be added to the WAPTT database, according to
WAPTT user needs. This is how WAPTT attack database is
97
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
easily extensible and why WAPTT can execute different
SQLI and XSS attacks.
1. "><SCRIPT>alert(String.fromCharCode(88,83,83))
</SCRIPT>
2. ></SCRIPT>">'><SCRIPT>alert(String.fromCharCode
(88,83,83))</SCRIPT>
3. '';!--"<XSS>=&{()}
4. <SCRIPT SRC=http://s-cube.etfbl.net/xss.js>
</SCRIPT>
Figure 4. A small subset of XSS attack patterns.
3) Buffer overflow attack parameter values
Similarly as for SQLI and XSS attacks, WAPTT
generates parameter values needed to perform BOF attack.
This process is very simple. For every parameter in every
application entry point, WAPTT will generate very long
random string (e.g., 10 000 random characters or more). The
size of this string can be configured by WAPTT user.
Evading detection technique
In order to avoid detection by defensive coding practices,
as well as many automated prevention techniques, WAPTT
can modify the injected text, by using three alternate
encoding methods: ASCII, hexadecimal and Unicode.
WAPTT uses alternate encodings when launching attacks
that were unsuccessful in the first pass. More precisely, for
every unsuccessful attack, WAPTT will launch three new
attacks, where the injected text is modified using three
different encoding methods.
D. Phase 4 - Analysis
In Phase 4 we analyze every HTTP response received
from the web application. Every HTTP response is scanned
for indications of vulnerability. The way we analyze HTTP
responses is different for every type of vulnerability
WAPTT checks for.
Detection of SQL Injection. As it is already mentioned,
in Phase 3 we simulate attacks against tested web
application, and as a result we get one reference HTML
page and additional HTML pages. Every additional HTML
page is analyzed and compared with the reference page.
If web application returns a 500 error status code for set
of malicious or incorrect parameter values, then we classify
the application as potentially vulnerable to attack in
question. Also, the resulting page is additionally analyzed in
order to find valuable information in error message (as
described in section “Illegal/Logically Incorrect Queries”).
If web application does not return error status code, then
we compare resulting page with the reference page. A web
application is not vulnerable if the returned page of an
invalid input is structurally similar to the reference page. If
the returned page of an invalid input is structurally similar to
the reference page, we classify the application as potentially
vulnerable to attack in question (Figure 5).
This applies to all SQLI types, except for special variant
of tautologies, i.e. for SQLI authentication bypass variant of
tautology attack, when user logon credentials are known by
WAPTT in advance. In this case structural similarity
between the reference page (obtained by using valid logon
credentials) and returned page of a malicious input means
that the attack was successful.
As it can be seen, a challenging task during the process of
98
Volume 14, Number 1, 2014
result analysis is to determine whether two HTML pages
look structurally similar. Two HTML pages are structurally
similar if they have similar layout when observed in a
browser [25]. To address this challenge, we extract HTML
tag sequences from two pages and compare the similarity of
these HTML tag sequences. We opted to use this approach
as the structure of an HTML page greatly depends on the
HTML tag sequence. Also, two HTML pages may be
structurally similar, but have different values in some tags.
They can also contain additional tags that are invisible when
we open the pages in a browser. For example, generated
account information page is different for every account, but
all pages for account information’s are still structurally
similar to each other.
Figure 5. Detection of SQL Injection.
Based on such observations we modified our SCSDS [26]
tool to assess the similarity of HTML pages. We named the
tool HSDT - HTML Similarity Detection Tool.
A previous study [27] determined the similarity between
two text files by computing the longest common
subsequence (LCS algorithm), using dynamic programming.
This algorithm has been widely used in diff, YAP and YAP
2 programs since it was introduced in 1978 [25]. A modified
version of this algorithm is used in PIUIVT [25] - Longest
Common Tag Subsequence (LCTS). LCTS operates on
HTML tag sequences, instead of pure HTML code.
Based on our findings in [26] we decided to use a much
more reliable algorithm for similarity detection – RKR-GST
(Running Karp-Rabin Greedy String Tiling) [28, 29, 30], as
well as Winnowing algorithm. As it can be seen in the
Kleiman and Kowaltowski paper [28, 29], there are few
situations in which the Winnowing algorithm gives better
results than the RKR-GST algorithm. In order to get good
enough results in every situation we decided to use both
algorithms for similarity detection.
Similarly to PIUIVT, HSDT treats HTML pages as
sequences of HTML tags. Tags are represented as a series of
tokens. Our similarity detection approach comprises the
following 5 phases: pre-processing, tokenization, exclusion,
similarity measurement, and final similarity calculation.
In the first phase, HSDT removes pure text nodes and
context-related tag attributes, such as href, src, alt, and title.
In the second phase, conversion of the HTML code into
tokens is done. Every HTML tag is replaced by its
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
corresponding token. For example, body and table tags are
replaced with <BODY> and <TABLE> tokens, respectively.
In the exclusion phase a HTML template code (which can
generate many false positives) can be identified and
excluded. HSDT creates a tokenized version of template
code, in the same way as it creates a tokenized version of the
HTML code in the tokenization phase. In the exclusion
phase, all findings of the tokenized version of template code
or its parts are removed from the input token sequence. For
this purpose, HSDT uses the RKR-GST algorithm. It is
important to mention that one of the advantages of the RKR-
GST algorithm is that token subsequences can be found
independent of their position in the token sequence. This
phase is optional, but it can be used to ignore the template
code during the similarity detection phase, and reduce the
similarity between non-similar pages.
In the similarity measurement phase HSDT computes the
similarity for two HTML pages under comparison, using
RKR-GST and Winnowing algorithms. In HSDT the RKR-
GST similarity measure of HTML token sequences a and b
is calculated by using the following formula (formula 1):
2*coverage
sim(a, b) 
length(a)  length(b)
where coverage is the length of all matches, and length is
the number of HTML tokens in the token sequence. Similar
to RKR-GST, the Winnowing similarity measure of
fingerprint sets a and b is calculated using the following
formula:
2* setSize(c)
sim(a, b) 
setSize(a)  setSize(b)
where setSize is the size of a set, and set c is intersection
of sets a and b.
The final similarity calculation is based on similarity
measure values obtained from the similarity detection
algorithms, and their weight factors. The overall similarity
measure between two HTML code files a and b is calculated
using the following formula (formula 3):
wR * simR  wW * simW
sim(a, b) 
2 list of domains specified in advance, are visited. This way,
where simR and simW are similarity measure values
obtained from RKR-GST and Winnowing similarity
detection algorithms, and wR and wW are weight factors of
those algorithms.
If the overall similarity measure value is larger than the
threshold value specified by the user, then the corresponding
pair of HTML code files is marked as similar. Different web
applications have different web page styles and the
threshold may need to adjust. Also, weight factors of RKR-
GST and Winnowing algorithms can be adjusted.
Detection of XSS. Detection of XSS vulnerability is more
straightforward than that for SQLI vulnerability. The reason
for this is that XSS attacks produce an observable side effect
in the generated HTML, namely the injected XSS attack
patterns. The resulting HTML output pages are checked for
presence of XSS attack patterns. When the malicious XSS
attack pattern is present in the output page, the WAPTT has
found a case in which the application does not properly
validate input before sending it back to clients. This is
Volume 14, Number 1, 2014
reported as XSS vulnerability.
Still, there is a complication in detection of XSS
vulnerability in a case when attack appears on different page
- in a case of stored XSS. This makes it difficult to identify
the corresponding application entry point through which the
XSS attack pattern was injected. To address this issue, we
set the src attribute value of <SCRIPT> tag to unique,
specifically encoded value. The value of src attribute is of
the following form “ID.js”, where ID is the unique number
of HTTP requests WAPTT sent. This number uniquely
identifies application entry point and XSS attack pattern. If
this <SCRIPT> tag appears on any output page during
penetration testing (i.e., during second pass off all pages),
WAPTT detects his presence and uses ID value to correlate
the successful attack with the corresponding application
entry point and XSS attack pattern.
Detection of Buffer Overflow. Detection of Buffer
Overflow vulnerability is the simplest of all vulnerabilities
WAPTT checks for. When the HTTP response code
returned from the web/application server is 500 (Internal
Server Error), or when there is no response from the server,
then this is reported as a potential Buffer Overflow
(1) vulnerability.
E. Phase 5 - Report generation
In Phase 5 we generate a report about found security
vulnerabilities in tested web application. WAPTT can
generate reports in different formats.
V. IMPLEMENTATION
(2)
The proposed approach is implemented as a prototype
tool, WAPTT. The WAPTT tool is written in Java and
performs automated penetration testing for discovering
SQLI, XSS and BufferOverflow vulnerabilities. The high-
level architecture of WAPTT is shown in Figure 6.
The web crawler module is responsible for the Web
crawling phase of the penetration testing process. This can
be done automated, manually (operator’s activity is recorded
by a proxy) or semi-automated (web crawler asks for
operator’s assistance). During automated web crawling
(3) process only pages that are in the base URL, or that are on a
leaving of tested web application and crawling of other
websites is avoided. The web crawler runs until all the
accessible web pages on target domain (domains) are
parsed. Because automated web crawling of the web is
usually incomplete, as an addition to this process, we can
perform the manual navigation to explore all possible
scenarios. During the manual navigation, Web crawler
works in proxy mode. While in proxy mode, Web crawler
intercepts the web pages that are sent from the client. These
pages, as well as those already identified during automated
web crawling will serve as an input for EAP detector and
extractor.
EAP detector and extractor module detects all application
entry points - forms with their elements (and constrains)
which are filled by end users and anchors/links with
parameters, in a manner as described in the Section IV,
subsection B. The output of this module is forwarded to the
attack generator module.
Attack generator module consists of several submodules -
99
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]

Advances in Electrical and Computer Engineering Volume 14, Number 1, 2014

one submodule for every vulnerability WAPTT checks for. [34]. Also, these web applications are often used for
Currently, there are three submodules: SQLI, XSS and BOF, demonstration of capabilities of web application scanners.
as it is shown in Figure 6. These submodules simulate Some of the vendors are aware of this and have pre-
attacks against tested web application in a manner as programmed their tools to report the vulnerabilities of these
described in the Section IV, subsection C. The output of applications [35]. The scanner may discover vulnerabilities
these submodules is forwarded to the analyzer module. on these applications but this has no predictive value for
how it will perform for other applications [35].
These are the reasons why we didn’t use these
applications, i.e. why we decided to use three vulnerable
web applications developed by 6 experienced master
students and 2 teaching assistants. Two applications were
developed using Java technologies: JSP (Java Server Pages)
and JSF (Java Server Faces). Both applications run on
Apache Tomcat 7.0.27. JSP application uses MS SQL
Server 2008 as a database server, while JSF application uses
MySQL 5.5.25. Third application was developed using PHP.
This application runs on Apache 2.2.3 and uses MySQL
5.0.77 as the backend data source. JSP application is
vulnerable on 4 SQLI attacks (3 first-order SQLI and 1
second-order SQLI), 1 second-order XSS and 1 BOF attack.
JSF application is vulnerable on 4 SQLI attacks (1 first-
order SQLI, 1 second-order SQLI and 2 blind SQLI attacks)
Figure 6. The high-level architecture of WAPTT.
and 2 XSS attacks (1 first-order XSS and 1 second-order
XSS), while PHP application is vulnerable on 3 SQLI
Analyzer module also consists of submodules - one
attacks (1 first-order SQLI, 1 second-order SQLI and 1 blind
submodule for every vulnerability WAPTT checks for.
SQLI attack) and 1 first-order XSS attack.
Also, currently there are three submodules: SQLI, XSS and
We tested each of these applications with six existing web
BOF analyzer submodules (Figure 6). These submodules
vulnerability scanners, as well as with our own tool -
analyze every HTTP response received from the web
WAPTT. The scanners that we used were w3af, Nikto,
application (i.e., from the web/application server) for
wapiti, vega, ZAP and Acunetix (Acunetix was the only
indications of vulnerability, in a manner as described in the
commercial tool available to us at the time of writing this
Section IV, subsection D.
paper). All of them are listed in the list of the most popular
The storage and reporter module is responsible for storing
Web-vulnerability scanners (http://sectools.org/tag/web-
the results generated by each of the analyzer submodules, as
scanners/). Each scanner is capable of crawling web pages
well as for report generation. Currently, this module
inside application, as well as filling out discovered HTML
supports two storing destinations: XML files and database
forms. All scanners can check for SQLI and XSS, but wapiti
tables. Still, WAPTT can generate reports in different
and Vega can’t detect BOF.
formats such as XML, HTML or PDF for reading or
All three applications have vulnerable login forms. A
publishing in different environments.
valid username/password combination or login sequence
It is important to notice that every attack generator
was not given to any of the seven scanners. The results of
submodule has corresponding analyzer submodule. In order
running the scanners against our three vulnerable
to extend WAPTT to check for some new vulnerability, a
applications are given in Table I.
new attack generator and analyzer submodules should be
written. TABLE I. THE RESULTS OF RUNNING THE SCANNERS AGAINST THREE
Also, it is important to mention that WAPTT tool meets VULNERABLE APPLICATIONS
almost all WASC (Web Application Security Consortium) tool \ FO SO BL FO SO
BOF
evaluation criteria for web application scanners. These vuln. XSS XSS SQLI SQLI SQLI
criteria published by WASC are organized in 8 categories w3af 0/1/0 0/0/0 0/0/0 2/1/1 0/0/0 0/0/0
[31]: protocol support, authentication, session management, Nikto 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0
crawling, parsing, testing, command and control, and wapiti 0/1/1 1/0/0 0/2/1 0/0/0 0/0/0 0/0/0
reporting. As this tool is not designed for parsing the vega 0/0/0 0/0/0 0/0/0 0/1/0 0/0/0 0/0/0
following content types: VBScript, ActiveX objects, Java ZAP 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0 0/0/0
applets, Flash and CSS (Cascading style sheets), it is Acuneti
0/1/1 0/0/0 0/1/1 2/1/1 0/0/0 0/0/0
obvious why it doesn’t meet all evaluation criteria from the x
parsing category of WASC evaluation criteria [31]. WAPT
0/1/1 1/0/0 0/2/1 2/1/1 1/0/0 1/0/0
T
VI. ANALYSIS VULN
0/1/1 1/1/0 0/2/1 3/1/1 1/1/1 1/0/0
S
There are a number of web applications designed to teach
application developers, programmers, architects and security The three values in a table cell (separated by “/”)
professionals about security concepts and secure software, represent numbers of discovered vulnerabilities against JSP,
such as WebGoat [32], Hacme Bank [33] and AltoroMutual
JSF and PHP applications, respectively. These values are

100
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
given for first-order XSS (denoted as FO XSS), second-
order XSS (denoted as SO XSS), blind SQLI (denoted as BL
SQLI), first-order SQLI (denoted as FO SQLI), second-
order SQLI (denoted as SO SQLI), and buffer overflow
(denoted as BOF) attacks. The last table row contains the
actual number of vulnerabilities in our JSP, JSF and PHP
applications, respectively.
One of the benefits of developing three web applications
to test the scanners is the ability for us to measure the false
negatives of the scanners. An ideal scanner would be able to
detect all vulnerabilities. In fact, the students and teaching
assistants (who developed these applications) knew all
vulnerabilities, while the automated scanners did not found
all of them. WAPTT discovered 12 from a total of 16
vulnerabilities, Acunetix discovered 8 vulnerabilities, wapiti
discovered 6 vulnerabilities, w3af discovered 5
vulnerabilities, and vega discovered only 1 vulnerability.
Nikto and ZAP did not discover any of vulnerabilities in any
of three applications.
As it can be seen, all first-order XSS vulnerabilities were
discovered by wapiti, Acunetix and WAPTT. W3af didn’t
discovered XSS in PHP application, while other tools
(Nikto, vega and ZAP) didn’t discover any of XSS
vulnerabilities. Wapiti and WAPTT discovered one second-
order XSS vulnerability (in JSP application). Second-order
XSS vulnerability in JSF application was not discovered by
any of the tools. All blind SQLI vulnerabilities were
discovered by wapiti and WAPTT. Acunetix discovered 2
out of 3 blind SQLI vulnerabilities, while other tools (Nikto,
vega and ZAP) didn’t discover any of blind SQLI
vulnerabilities. Vega only discovered first-order SQLI
vulnerability in JSF application. W3af, Acunetix and
WAPTT didn’t discover only one first-order SQLI
vulnerability (in JSP application). Other tools (Nikto, wapiti
and ZAP) did not discover any of first-order SQLI
vulnerabilities in any of three applications. WAPTT
discovered 1 out of 3 second-order SQLI vulnerabilities. All
other tools did not discover any of second-order SQLI
vulnerabilities in any of three applications. It is important to
mention that w3af tool successfully executed one second-
order SQLI attack against JSF application, but it failed to
detect that successful execution. Additionally, Nikto and
ZAP didn’t find all of application pages, because they didn’t
pass the login forms of tested applications. BOF
vulnerability (in JSP application) is discovered only by
WAPTT tool.
It is important to mention, that there were two false
positive detections by w3af tool. W3af reported two false
SQLI vulnerability detections, one in JSP and one in JSF
application. Wapiti, as well as Vega, reported false SQLI
vulnerability detection in JSF application. Also, it is
important to notice that one of first-order SQLI
vulnerabilities (in JSP application) and two second-order
SQLI vulnerabilities were not detected by any scanner.
There were no false XSS and BOF vulnerability detections
by any of tools.
VII. CONCLUSION
Number of reported web applications vulnerabilities is
increasing dramatically. Most of them result from improper
or none input validation by the web application.
Volume 14, Number 1, 2014
This paper describes penetration test tool designed for
dynamic security analysis of web applications called
WAPTT. This tool is designed to exploit forms and anchors
with parameters. The main goal of this tool is to generate
test inputs and assess test results of testing from the client
side. Compared to six well-known web application scanners,
WAPTT showed promising results in detecting various web
application vulnerabilities. Moreover, compared to these
scanners, WAPTT detected the same or greater number of
vulnerabilities in every tested application for every type of
vulnerability.
When compared to the well-known state-of-the-art web
application scanners, WAPTT has one extra feature, which
is modularity, which enables end-users to easily extend this
tool. Also, this is one of the promising areas of extension to
this work. It would be interesting to implement some
additional attack generator and analyzer submodules in
order to support detection of new types of web application
vulnerabilities. It is important to mention that WAPTT uses
an efficient algorithm for page similarity detection, needed
for SQLI vulnerability detection. Also, the WAPTT tool
meets almost all WASC evaluation criteria (organized in 8
categories) for web application scanners.
Because WAPTT uses two similarity detection algorithms
in process of page similarity detection (needed for SQLI
vulnerability detection) and because WAPTT makes two
passes off all pages (needed for detection of second-order
SQLI and second-order XSS attacks), it is obvious that this
tool can be slower as compared to other web application
scanners. This is why a speed performance improvement of
WAPTT is needed and will be investigated in the future
work. There are some other limitations to WAPTT that
should be addressed in the future work. An efficient,
intuitive and easy accessible user interface is critical to wide
adoption. This is why we are developing a new user
interface for WAPTT in the form of a rich internet
application.
REFERENCES
[1] H. Shahriar, M. Zulkernine. Automatic Testing of Program Security
Vulnerabilities, 33rd Annual IEEE International Computer Software
and Applications Conference, pp. 550 - 555, 2009.
[2] A. Kiezun, P. J. Guo, K. Jayaraman, and M. D. Ernst, “Automatic
creation of SQL injection and cross-site scripting attacks”, in
ICSE’09, Proceedings of the 30th International Conference on
Software Engineering, Vancouver, BC, Canada, May 20–22, 2009.
[3] T. Scholtea, D. Balzarottib, E.Kirda, “Have things changed now? An
empirical study on input validation vulnerabilities in web
applications”, Computers & Security, vol. 31, pp. 344-356, 2012.
[4] J. Bau, E. Bursztein, D. Gupta, J. Mitchell, “State of the Art:
Automated Black-Box Web Application Vulnerability Testing”,
Proceedings of the 2010 IEEE Symposium on Security and Privacy,
pp. 332-345, 2010.
[5] N. Antunes, N. Laranjeiro, M. Vieira, H. Madeira, “Effective
Detection of SQL/XPath Injection Vulnerabilities in Web Services”,
IEEE SCC 2009, pp. 260-267, 2009.
[6] X. Li and Y. Xue, “A Survey on Web Application Security”,
Technical report, Vanderbilt University, 2011.
[7] W. G. Halfond and A. Orso, “AMNESIA: Analysis and Monitoring
for NEutralizing SQL-Injection attacks”, Proceedings of the 20th
IEEE/ACM international Conference on Automated software
engineering, pp. 174-183, 2005.
[8] Y.-W. Huang, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo,
“Securing Web application code by static analysis and runtime
protection”, Proceedings of the 13th international conference on
World Wide Web, pp. 40 - 52, 2004.
[9] M. Lam, M. Martin, B. Livshits, and J. Whaley, “Securing Web
applications with static and dynamic information flow tracking”,
101
 [Downloaded from www.aece.ro on Saturday, March 31, 2018 at 18:13:05 (UTC) by 178.171.108.125. Redistribution subject to AECE license or copyright.]
Advances in Electrical and Computer Engineering
Proceedings of the ACM SIGPLAN symposium on Partial evaluation
and semantics-based program manipulation, pp. 3-12, 2008.
[10] M. Martin and M. Lam, “Automatic generation of XSS and SQL [23]
injection attacks with goal-directed model checking”, Proceedings of
the 17th conference on Security symposium, pp. 31-43, 2008.
[11] OWASP Top 10 2013, https://www.owasp.org/index.php/Top_10
_2013 [24]
[12] Information Technology Industry Council NCITS. SQL-92 standard.
http://www.ncits.org/, 1992.
[13] C. Anley, Advanced SQL Injection in SQL Server Applications, [25]
http://www.nextgenss.com/papers/ advanced sql injection.pdf
[14] C. Anley,(more) Advanced SQL Injection, http://www.nextgenss.
com/ papers/more advanced sql injection.pdf [26]
[15] G. Wassermann and Z. Su, “Sound and precise analysis of web
applications for injection vulnerabilities,” SIGPLAN Not., vol. 42, no.
6, pp. 32–41, 2007. [27]
[16] M. S. Lam, M. Martin, B. Livshits, and J. Whaley, “Securing web
applications with static and dynamic information flow tracking,” in
PEPM ’08: Proceedings of the 2008 ACM SIGPLAN symposium on [28]
Partial evaluation and semantics based program manipulation. New
York, NY, USA: ACM, pp. 3–12, 2008.
[17] N. Jovanovic, C. Kruegel, and E. Kirda, “Pixy: A static analysis tool
for detecting web application vulnerabilities (short paper),” IEEE [29]
Symposium on Security and Privacy, pp. 258–263, 2006.
[18] Y.-W. Huang, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo,
“Securing web application code by static analysis and runtime [30]
protection,” Proceedings of the 13th international conference on World
Wide Web. New York, NY, USA: ACM, pp. 40–52, 2004.
[19] S. Kals, E. Kirda, C. Kruegel, and N. Jovanovic, “Secubat: a web [31]
vulnerability scanner”, Proceedings of the 15th international
conference on World Wide Web, pp. 247–256, 2006.
[20] S. McAllister, E. Kirda, and C. Kruegel, “Expanding Human
Interactions for In-Depth Testing of Web Applications”, 11th [32]
Symposium on Recent Advances in Intrusion Detection, Boston, MA,
2008. [33]
[21] S. Mcallister, E. Kirda, and C. Kruegel, “Leveraging user interactions
for in-depth testing of web applications,” Proceedings of the 11th [34]
international symposium on Recent Advances in Intrusion Detection, [35]
pp. 191–210, 2008.
[22] F. Maggi, W. K. Robertson, C. Krugel, and G. Vigna, “Protecting a
moving target: Addressing web application concept drift”,
102
Volume 14, Number 1, 2014
Proceedings of the 12th International Symposium on Recent
Advances in Intrusion Detection, pp. 21–40, 2009.
Y.-W. Huang, S.-K. Huang, T.-P. Lin, Ch.-H. Tsai, “Web application
security assessment by fault injection and behavior monitoring”,
Proceedings of the 12th international conference on World Wide
Web, pp. 148-159, 2003.
A. Wiegenstein, F. Weidemann, M. Schumacher, S. Schinzel, “Web
Application Vulnerability Scanners - a Benchmark”, Virtual Forge
GmbH, 2006.
N. Li, T. Xie, M. Jin, C. Liu, “Perturbation-based user-input-
validation testing of web applications”, Journal of Systems and
Software, vol. 83, pp. 2263-2274, 2010.
Z. Djuric, D. Gasevic, “A Source Code Similarity System for
Plagiarism Detection”, The Computer Journal, vol. 56, pp. 70-86,
2013.
J.W. Hunt, M.D. McIlroy, “An Algorithm for Differential File
Comparison”, Technical Report SECLAB-05–04, Bell Laboratories,
1976.
A. B. Kleiman, T. Kowaltowski, “Qualitative Analysis and
Comparison of Plagiarism-Detection Systems in Student Programs”,
Technical Report IC-09-08. Instituto de Computação,
UNIVERSIDADE ESTADUAL DE CAMPINAS, 2009.
M.J. Wise, “String similarity via greedy string tiling and running
Karp-Rabin matching”, Deptartment of CS, University of Sydney,
ftp://ftp.cs.su.oz.au/michaelw/doc/RKR GST.ps, 1993.
R.M Karp and M.O. Rabin, “Efficient randomized pattern-matching
algorithms”, IBM Journal of Research and Development -
Mathematics and computing, vol. 31, pp. 249-260, 1987.
Web Application Security Consortium (WASC). Web application
security scanner evaluation criteria.
http://projects.webappsec.org/f/Web+Application+Security+Scanner+
Evaluation+Criteria+-+Version+1.0.pdf, 2011.
OWASP WebGoat Project, https://www.owasp.org/index.php/
Category:OWASP_WebGoat_Project
HackMe bank, http://www.mcafee.com/us/downloads/free-
tools/hacme-bank.aspx
AltoroMutual, http://demo.testfire.net/
L. Suto, “Analyzing the Accuracy and Time Costs of Web
Application Security Scanners”, Available: http://ha.ckers.org/
files/Accuracy_and_Time_Costs_of_Web_App_Scanners.pdf