See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261089248

A black-box testing tool for detecting SQL injection vulnerabilities

Conference Paper · September 2013

CITATIONS READS
57 2,379

1 author:

Zoran Đurić
University of Banja Luka
23 PUBLICATIONS 300 CITATIONS

SEE PROFILE

All content following this page was uploaded by Zoran Đurić on 24 February 2021.

The user has requested enhancement of the downloaded file.

Abstract— Web applications vulnerabilities allow attackers to technique, there is also technique which is based on analyzing
perform malicious actions that range from gaining unauthorized the source code of the application looking for potential security
account access to obtaining sensitive data. The number of web vulnerabilities. These techniques also can be combined [7, 8, 9,
application vulnerabilities in last decade is growing constantly. 10].
Improper input validation and sanitization are reasons for most
of them. The most important of these vulnerabilities based on Although some researchers have shown the limitations of
improper input validation and sanitization is SQL injection black-box scanners in detecting some vulnerabilities [11, 12,
(SQLI) vulnerability. The primary focus of our research was to 13], black-box technique became widely adopted due to the
develop a reliable black-box vulnerability scanner for detecting ease of use, automation, and independence from the web
SQLI vulnerability - SQLIVDT (SQL Injection Vulnerability application technology used. Section II gives an overview of
Detection Tool). The black-box approach is based on simulation some of the existing web application testing tools. The primary
of SQLI attacks against web applications. Thus, the scope of focus of our research was to develop a reliable black-box
analysis is limited to HTTP responses and HTML pages received vulnerability scanner (SQLIVDT) for detecting today’s most
from the application server. In order to achieve efficient SQLI important web applications vulnerability - SQLI. A detailed
vulnerability detection, an efficient algorithm for HTML page explanation of different forms of SQLI attacks and ways in
similarity detection is used. The proposed tool showed promising which they can be exploited are given in Section III. Similar
results as compared to six well-known web application scanners.
explanations are also available in the public domain [14, 15].
Keywords— Web application security; SQL injection; black-
Section IV describes HTML pages structural similarity. Before
box; web page similarity concluding the paper, we compared our tool against six well-
known web application scanners. The evaluation process and
I. INTRODUCTION obtained results are described in detail and presented in Section
V.
The main reason for most of the web applications
vulnerabilities is the lack of, or failure of, proper client input II. RELATED WORK
validation. These vulnerabilities can be classified in a group of
input manipulation vulnerabilities, of which the most important Most academic research on tools for detection of web
are SQL Injection (SQLI) and Cross-Site Scripting (XSS) [1, 2, applications vulnerabilities has been static source code
3]. Last two OWASP (The Open Web Application Security analysis, with a focus on detecting SQLI and XSS via
Project) reports for the top 10 web application vulnerabilities modeling checking analysis, information flow, or via their
shown that SQL injection is ranked first among other combination [2, 8, 9, 11, 16, 17]. Dynamic security analysis
vulnerabilities [4, 5]. tools perform attacks against web application under testing and
analyze application responses in order to detect any existing
SQLI is attack against a database-driven web application, in vulnerabilities. Kals et. al. [18] implemented dynamic security
which the attacker attempts to change the semantics of the analysis tool SecuBat for SQLI, as well as for XSS detection.
original SQL statement. This is done by inserting new SQL SecuBat is modular tool implemented as a Windows Forms
keywords, operators and statements (or their parts) into the .NET application in C#. Huang et. al. [26] proposed WAVES,
original SQL statement through unvalidated (unsanitized) a black-box tool for testing web applications for SQLI
input. In a successful attack, the attacker will pass an SQL vulnerabilities. This tool identifies entry points in a web
attack code to the back-end database for execution. Also, under application that can be used to inject malicious code and builds
some circumstances he may interact with the file system and attacks that target these points.
even execute system calls [6].
Besides academic tools, there are also commercial tools,
In order to minimize the likelihood of successful attacks like Acunetix Web Vulnerability Scanner, IBM Rational
against web applications, a variety of techniques to identify AppScan and HP Webinspect. All three can detect SQLI
existing web application vulnerabilities is used. Dynamic vulnerabilities, as well as several other vulnerabilities. There is
security analysis (black-box analysis) is technique based on also a wide range of open-source tools which can detect SQLI,
discovering vulnerabilities in web application by testing the such as Vega, W3af and Wapiti. Vega is GUI-based, cross-
application from the attacker’s point of view. Besides this
platform tool written in Java, which can be extended using its bypass), the web crawler will also identify and explore all web
Javascript API. W3af is a free open-source web application application pages (Fig. 1). Web crawler can be configured in
scanner designed and implemented for finding and exploiting such a way to recognize and avoid visiting links that will
SQLI and web application vulnerabilities. It is divided into the destroy the current session and logoff the crawler. This feature
core part and the plugins part. Wapiti is web application is implemented generically - we use the regular expression in
scanner designed and implemented to detect SQLI, as well as order to create the set of links to be ignored. Our web crawler
several other vulnerabilities. It does not provide a GUI for the runs until all accessible web pages are identified and parsed.
moment and must be used from a terminal. W3af and Wapiti Additionally, during automated web crawling process only
are written in Python. pages that are in the base URL, or that are on the list of
domains specified in advance, are visited.
Some of the existing Web application scanners are based
on predefined rules and known defects recorded in In many cases, automated web crawling of the modern web
vulnerability databases. They use vulnerability databases, such application will not be complete. The reason for this is that
as OSVDB (Open Source Vulnerability Database), to scan for automated web crawler does not reach all the application
possible existence of directories and files that malicious users HTML pages because these applications use partial page
usually try to find and treat as an entry point (for example refresh, asynchronous requests and can have different
/admin directory) [11]. Similarly, some scanners like authentication and authorization mechanisms. As an addition to
Accunetix, AppScan and Wikto use Google Hacking Database the automated web crawling, we perform the manual web
to search for signatures of online websites. Besides these crawling to explore all possible scenarios. During the manual
database-based detections, some of the most popular scanners web crawling SQLIVDT works in proxy mode. In this mode
provide rule-based SQL injection detection capabilities, i.e. SQLIVD intercepts the web pages that are sent from and to the
they have a huge attacking vectors base, through which they client (web browser). Those pages, as well as the other ones
can construct a number of of attacking exploits. Examples of already identified using the automated crawler, will serve as an
these scanners are AppScan and ZAP Proxy. All these tools try input into Phase 2.
to identify points in a web application that can be used to inject
malicious code. They perform attacks that target these points B. Phase 2 - AEP’s detection and extraction
and monitor how the application responses to the generated Parts of the web pages visited in Phase 1 of interest for our
attacks. approach are AEP’s. Generally, the main disadvantage [24] of
automated penetration testing tools is poor coverage of AEP’s.
Assessment of results collected during SQL injection test is This is why, in Phase 2, we try to extract all AEP’s from pages
not simple task at all. Still, some tools use very naive visited in Phase 1. The result is a set of AEP’s which has to be
techniques for test-result assessment. For example, AppScan is analyzed. AEP’s are mainly forms with their elements (and
capturing error messages such as “OleDbException” to constrains) which are filled by end users, as well as all
determine whether an SQL error happened, while Paros Proxy anchors/links with parameters, i.e. GET parameters.
searches for “SQL”, ”ODBC”, “JDBC” and similar strings
[19]. Such an approach can cause high number of false alarms
[11]. Web Authentication
crawling required?
III. OUR APPROACH NO
Our approach is implemented in SQLIVDT (SQLI YES
Vulnerability Detection Tool) tool - a tool for efficient SQLI YES
vulnerability detection. The approach is based on simulation of NO AEP’s detection
SQLI attacks against web applications. Thus, the scope of Authentication and extraction
analysis is limited only to HTTP responses received from the bypassed?
application server which runs tested web application. Similarly
to the reported designs commonly found in other systems [18],
our approach comprises the following phases (Figure 1): Web Report
Analysis Attacking
crawling, AEP’s (application entry point’s) detection and generation
extraction, attacking, analysis, and report generation.
Fig. 1. Our dynamic security analysis approach
A. Phase I - Web crawling
During the dynamic security analysis attacks can be To extract all AEP’s and collect the list of them, along with
launched only against previously recognized AEP’s. This is their constraints, all web pages visited in Phase 1 are parsed
why identification of all pages being part of the tested web and analyzed. The forms are parsed to discover their elements
application is crucial for testing [20]. This task can be done and predefined constraints which every form element may
automated, manually or semi-automated. have. For example, max length attribute can be set in order to
SQLIVDT Web crawler can be configured to use valid user define a maximum number of characters that can be inserted in
credentials (valid username and password, for example). This an input text field. The most important constraints for our
allows the web crawler to go beyond the login web page, and approach are the following: method, action, enctype, disabled,
to identify and explore all web application pages. Similarly, if max, maxlength, min, multiple, pattern, readonly, required and
login form can be successfully bypassed (authentication value. Although not all of these constraints are supported in all
today’s web browsers, we use all of them as an important and the complete query evaluates to true - for each row in the
information for generation of HTTP requests sent to the web corresponding table.
application during the testing phase (Phase 3). Regarding
anchors/links with parameters, we parse every anchor/link and 2) Illegal/Logically Incorrect Queries
extract all parameters and their values. This type of attack is usually used for injectable parameters
identification, data extraction and database finger-printing.
C. Phase 3 - Attacking SQLIVDT tries to modify original statements (by inserting
For every AEP we generate one set of valid parameter rubbish input or SQL tokens) in such a way that the resulting
values. SQLIVDT uses these valid values to generate HTTP statements will be illegal, i.e. logically incorrect. These
request. The result of this request is reference HTML page. statements will be rejected, and error messages will be returned
Additionally, for every AEP we generate many sets of from the database. Sometimes these error messages include
malicious or incorrect parameter values. More precisely, we useful debugging information, including description and
create parameter values which violate predefined constraints of exception details. For example, in order to make a type
parameters. Also, we use predefined attack patterns (described mismatch error SQLIVDT can add “ ’ ” (single quotation
later in this section) as parameter values. Malicious or incorrect mark) onto valid integer. The error message produced by this
parameter values are used by SQLIVDT to generate additional query can contain very useful information including a whole
HTTP requests. The results of these requests are additional incorrect SQL statement, type of database server, etc.
HTML pages, which are, along with the reference HTML page, 3) Union queries
used in Phase 4 (analysis). This type of attack is usually used for authentication
Based on type of a parameter value detected in Phase 2, we bypassing and data extraction. By inserting a statement of the
create different attack patterns. Generally, for text type form UNION SELECT <the_rest_of_inserted_query>,
parameters, we use attack patterns that require a single SQLIVDT tries to cheat the application into returning data
quotation mark. A small subset of these attack patters is given from a table different from the table that was intended by the
in Fig. 2. original SQL query. Inserted attack pattern changes the
semantics of the original statement, and as a consequence, the
1) admin' -- 2) admin' # database takes the results of both queries (the original and the
2) ' or 1=1-- 4) ' or 1=1# inserted SQL query) and union them.
5) ') or '1'='1-- 6)') or ('1'='1#
7) ' UNION SELECT 1, 'admin', 'xz', 1-- 4) PiggyBacked Queries
This type of attack is usually used for data extraction, data
Fig. 2. A small subset of SQL attack patterns with a single quotation mark
addition or modification, remote commands execution and for
Similarly, for integer type parameters, we use attack performing a denial of service. During the execution of this
patterns that doesn’t require a single quotation mark. A small attack, SQLIVDT tries to inject additional SQL query besides
subset of these attack patters is given in Fig. 3. the original one, in order for the database to receive multiple
queries. For example, for dropping of a known database table
1) 1 OR 1=1-- SQLIVDT uses “'; DROP TABLE <known_table_name>--”
2) 1; drop table test /* attack pattern. During this attack, two SQL statements will be
3) 1; drop table test -- executed in one query, if and only if the database support’s
4) 1; drop table test; create table test (name execution of multiple queries in one statement.
varchar(10)) --
5) 1; delete from test;-- 5) Inference attack
Fig. 3. A small subset of SQL attack patterns without a single quotation
This type of attack is usually used for data extraction,
mark identification of injectable parameters and database schema
determination. Typical attack techniques that are based on
It is very important to mention that SQLIVDT user can add inference are: blind injection and timing attack. These
new attack patterns to the SQLIVDT database. This way techniques are usually performed when an application has
SQLIVDT can be easily extended to support different and new been secured in such a way that, when an injection has been
SQLI attacks. There are numerous variations of each SQLI successfully executed, there is no useful information contained
attack type. This is why we present only a few most important in database error messages. When performing inference
supported by SQLIVDT. attack, SQLIVDT injects different commands into the
1) Tautologies application and then “observes” its responses. By detecting
Tautology-based attacks are usually used for authentication when the application behaves the same and when its behavior
bypassing and data extraction, although they can also be used changes, SQLIVDT can “conclude” whether certain
for identifying injectable parameters. SQLIVDT tries to exploit parameters are vulnerable, as well as additional information
an injectable field that is used in a SQL query WHERE clause. about the values in the database. For example, to detect
For example, for bypassing login form SQLIVDT uses “‘ or injectable parameter using blind SQLI SQLIVDT uses the
1=1 --“ attack pattern and it’s variants (taken from SQLIVDT following partial statements:
attack database). Because “--” is the SQL comment operator “<known_legal_values_of_parameters> ’ and/or 1=0 --“ and
and because “1=1” always evaluate to true, inserted attack “<known_legal_values _of_parameters> ’ and/or 1=1 --“.
pattern transforms the entire WHERE clause into a tautology
 Suppose we have an unsecure application (that doesn’t IV. HTML PAGES STRUCTURAL SIMILARITY
validate correctly the input value for one parameter). Then two As it can be seen, a challenging task during the process of
resulting statements containing former partial statements will analysis (Phase 4) is to determine whether two HTML pages
return different results meaning that parameter in question is look structurally similar. Two HTML pages are structurally
vulnerable to injection. similar if they have similar layout when observed in a browser
Evading detection technique. In order to avoid detection [19].
by defensive coding practices, as well as many automated To address this challenge, we extract HTML tag sequences
prevention techniques, for every unsuccessful ASCII-encoded from two pages and compare the similarity of them. We opted
attack SQLIVDT will launch two new attacks, where the to use this approach as the structure of an HTML page greatly
injected text is hexadecimal and Unicode encoded. depends on the HTML tag sequence. Also, it is important to
D. Phase 4 - Analysis notice that two HTML pages may be structurally similar, but
have different values in some tags. Also, structurally similar
In this phase, we analyze and compare additional HTML
pages with the reference page. If web application returns a 500 pages can also contain additional hidden tags that are invisible
error status code for HTTP request containing a set of when we open the pages in a browser. For example, generated
malicious or incorrect parameter values, then we classify the account information page is different for every account, but all
application as potentially vulnerable to attack in question. Also, pages for account information’s are still structurally similar to
the resulting page is additionally analyzed in order to find each other. Based on such observations we modified our
valuable information in error message, as already described approach used in SCSDS tool [21] to assess the similarity of
earlier. HTML pages. A previous study [22] determined the similarity
between two text files by computing the longest common
If web application does not return error status code, then we subsequence (LCS algorithm), using dynamic programming.
compare resulting page with the reference page. Based on a This algorithm has been widely used in diff, YAP and YAP 2
structurally similarity of these pages and type of performed programs since it was introduced in 1978 [19, 21]. A modified
SQLI attack we decide that web application is, or is not version of this algorithm is used in PIUIVT [19] - Longest
vulnerable to attack in question (Fig. 4). Common Tag Subsequence (LCTS). LCTS operates on HTML
tag sequences, instead of pure HTML code.
Based on our findings in [21] we decided to use a much
Reference page Additional page more reliable algorithm for similarity detection – RKR-GST
(Running Karp-Rabin Greedy String Tiling) [23, 24, 25], as
well as Winnowing algorithm. As it can be seen in [23], there
are few situations in which the Winnowing algorithm gives
NO HTTP error
Compare better results than the RKR-GST algorithm. In order to get
status code?
good enough results in every situation we decided to use both
algorithms for similarity detection of HTML tag sequences.
YES
Attack type and
Similarly to PIUIVT, SQLIVDT treats HTML pages as
Potential sequences of HTML tags, where tags are represented as a
structural
vulnerability series of tokens. Our similarity detection approach comprises
similarity?
the following five phases: pre-processing, tokenization,
NO vulnerability
exclusion, similarity measurement, and final similarity
calculation.
Fig. 4. Detection of SQL Injection In the first phase, pure text nodes and context-related tag
attributes, such as href, src, alt, and title, are removed. In the
For example, if SQLI authentication bypass variant of
second phase, conversion of the HTML code into tokens is
tautology attack is performed (when user logon credentials are
done. Every HTML tag is replaced by its corresponding token.
known by SQLIVDT in advance), then in this case structural
For example, body tag is replaced with <BODY> token. In the
similarity between the reference page (obtained by using valid
exclusion phase a HTML template code (which can generate
logon credentials) and additional page (obtained by using
many false positives) can be identified and excluded.
malicious input) means that the attack was successful. In
SQLIVDT creates a tokenized version of template code, in the
contrary, when user logon credentials are not known by
same way as in the tokenization phase. All findings of this
SQLIVDT in advance, then in this case structural similarity
“template token sequence” or its parts (subsequences of a
between the reference page and additional page means that the
“template token sequence”) are removed from the input token
attack was not successful.
sequence. For this purpose, SQLIVDT uses the RKR-GST
E. Phase 5 - Report generation algorithm. An important property of the RKR-GST algorithm
In this phase we generate a report about found security is that token subsequence can be found independent of its
vulnerabilities in tested web application. SQLIVDT can position in the token sequence. This phase is optional, but it
generate reports in different formats, namely: text, XML, can be used to ignore the template code during the similarity
HTML and PDF. detection phase, and reduce the similarity between non-similar
HTML pages. In the similarity measurement phase we
compute the similarity for two HTML pages under vulnerable on 4 SQLI attacks (3 first-order SQLI and 1 second-
comparison, using RKR-GST and Winnowing algorithms. The order SQLI). JSF application is vulnerable on 4 SQLI attacks
RKR-GST similarity measure of HTML token sequences (1 first-order SQLI, 1 second-order SQLI and 2 blind SQLI
h1and h2 is calculated by using the following formula: attacks), while PHP application is vulnerable on 3 SQLI
attacks (1 first-order SQLI, 1 second-order SQLI and 1 blind
2
1, 2 SQLI attack).
1 2
We tested each of these applications with six existing web
where coverage is the length of all matches, and length is vulnerability scanners, as well as with SQLIVDT. The
the number of HTML tokens in the token sequence. scanners that we used were W3af, Nikto, Wapiti, Vega, ZAP
Similar to RKR-GST, the Winnowing similarity measure of and Acunetix (Acunetix was the only commercial tool
fingerprint sets h1 and h2 is calculated using the following available to us at the time of writing this paper). All of them
formula: are listed on the list of the most popular Web-vulnerability
scanners [31]. Each scanner is capable of crawling web pages
2 inside application, as well as filling out discovered HTML
1, 2
1 2 forms.
where setSize is the size of a set, and set h is intersection of All three applications have vulnerable login forms. A valid
sets h1 and h2. username/password combination or login sequence was not
given to any of the seven scanners. The results of running the
The last phase in this similarity detection process is scanners against our three vulnerable applications are shown in
calculation of overall similarity measure between two HTML Table I. The three values in a row represent numbers of
code files a and b by using the following formula: discovered vulnerabilities against JSP, JSF and PHP
applications, respectively.
1, 2
2 All blind SQLI vulnerabilities were discovered by wapiti
where simRKR-GST and simWINN are similarity measure values and SQLIVDT. Acunetix discovered 2 out of 3 blind SQLI
obtained from RKR-GST and Winnowing similarity detection vulnerabilities, while other tools (Nikto, Vega and ZAP) didn’t
algorithms, and wRKR-GST and wWIN are weight factors of those discover any of blind SQLI vulnerabilities. Vega only
algorithms. discovered first-order SQLI vulnerability in JSF application.
W3af, Acunetix and SQLIVDT didn’t discover only one first-
If the overall similarity measure value is larger than the
order SQLI vulnerability (in JSP application). SQLIVDT
threshold value specified by the user, then the corresponding
discovered 1 out of 3 second-order SQLI vulnerabilities.
pair of HTML code files is marked as structurally similar.
Different web applications have different web page styles and TABLE I. THE RESULTS OF RUNNING THE SCANNERS AGAINST THREE
the threshold may need to be adjusted. Also, weight factors of VULNERABLE APPLICATIONS
RKR-GST and Winnowing algorithms can be adjusted.
tool \ vulnerability FO SQLI SO SQLI BL SQLI
V. ANALYSIS w3af 2/1/1 0/0/0 0/0/0
Nikto 0/0/0 0/0/0 0/0/0
There are a number of web applications designed to teach wapiti 0/0/0 0/0/0 0/2/1
application developers, architects and security professionals vega 0/1/0 0/0/0 0/0/0
about security concepts and secure software development, ZAP 0/0/0 0/0/0 0/0/0
such as WebGoat [27], Hacme Bank [28] and AltoroMutual Acunetix 2/1/1 0/0/0 0/1/1
SQLIVDT 2/1/1 1/0/0 0/2/1
[29]. Also, these web applications are often used for VULNERABILITIES 3/1/1 1/1/1 0/2/1
demonstration of capabilities of web application scanners.
Some of the vendors are aware of this and have adjusted their
tools in such a way to report the vulnerabilities of these It is important to mention that W3af tool successfully
applications [30]. Although the web application scanner may executed one second-order SQLI attack against JSF
application, but it failed to detect that successful execution.
discover vulnerabilities on these test applications, this has no
Other tools (Nikto, Wapiti and ZAP) did not discover any of
predictive value for how it will perform for other applications first-order and second-order SQLI vulnerabilities in any of
[30]. three applications. These tools didn’t find all of application
These are the reasons why we didn’t use these applications, pages, because they didn’t pass the login forms of tested
i.e. why we decided to use three vulnerable web applications applications. It is important to mention, that W3af tool reported
developed by 7 experienced master students and 2 teaching two false SQLI vulnerability detections, one in JSP and one in
assistants. Two applications were developed using Java JSF application. Wapiti, as well as Vega, reported false SQLI
technologies, JSP (Java Server Pages) and JSF (Java Server vulnerability detection in JSF application. Also, it is important
Faces). Both applications run on Apache Tomcat 7.0.27. JSP to notice that one of first-order SQLI vulnerabilities was not
application uses MS SQL Server 2008 as a database server, detected by any scanner (in JSP application). Two second-
while JSF application uses MySQL 5.5.25. Third application order SQLI vulnerabilities were also not discovered by any
was developed using PHP. It runs on Apache 2.2.3 and uses scanner.
MySQL 5.0.77 as the backend data source. JSP application is
 VI. CONCLUSION [12] A. Doup´e, M. Cova, and G. Vigna, “Why Johnny Can’t Pentest: An
Analysis of Black-box Web Vulnerability Scanners”, July 2010
This paper describes SQLIVDT tool designed for efficient [13] J. Fonseca, M. Vieira, and H. Madeira, "Testing and Comparing Web
SQLI vulnerability detection. The main goal of this tool is to Vulnerability Scanning Tools for SQL Injection and XSS Attacks,"
generate test inputs and assess test results of testing from the prdc, pp.365-372, 13th Pacific Rim International Symposium on
client side. Compared to six well-known web application Dependable Computing (PRDC 2007), 2007
[14] C. Anley, Advanced SQL Injection in SQL Server Applications,
scanners, SQLIVDT showed promising results in detecting http://www.nextgenss.com/ papers/advanced sql injection.pdf
SQLI vulnerability. Moreover, compared to these scanners, [15] C. Anley, (more) Advanced SQL Injection,
SQLIVDT detected the same or greater number of SQLI http://www.nextgenss.com/papers/more advanced sql injection.pdf
vulnerabilities in every tested application. [16] G. Wassermann, and Z. Su, “Sound and precise analysis of web
applications for injection vulnerabilities,” SIGPLAN Not., vol. 42, no. 6,
Because SQLIVDT uses two similarity detection pp. 32–41, 2007.
algorithms in process of page similarity detection (needed for [17] N. Jovanovic, C. Kruegel, and E. Kirda, “Pixy: A static analysis tool for
SQLI vulnerability detection) and because SQLIVDT makes detecting web application vulnerabilities (short paper),” IEEE
Symposium on Security and Privacy, pp. 258–263, 2006.
two passes off all pages (needed for detection of second-order [18] S. Kals, E. Kirda, C. Kruegel, and N. Jovanovic, “Secubat: a web
SQLI), it is obvious that this tool can be slower as compared to vulnerability scanner”, Proceedings of the 15th international conference
other web application scanners. This is why a speed on World Wide Web, pp. 247–256, 2006.
performance improvement of SQLIVDT is needed and will be [19] N. Li, T. Xie, M. Jin, and C. Liu, “Perturbation-based user-input-
investigated in the future work. validation testing of web applications”, Journal of Systems and
Software, vol. 83, pp. 2263-2274, 2010.
REFERENCES [20] Y.-W. Huang, S.-K. Huang, T.-P. Lin, and Ch.-H. Tsai, “Web
application security assessment by fault injection and behavior
[1] H. Shahriar, and M. Zulkernine. Automatic Testing of Program Security monitoring”, Proceedings of the 12th international conference on World
Vulnerabilities, 33rd Annual IEEE International Computer Software and Wide Web, pp. 148-159, 2003
Applications Conference, pp. 550 - 555, 2009. [21] Z. Djuric, and D. Gasevic, “A Source Code Similarity System for
[2] A. Kiezun, P. J. Guo, K. Jayaraman, and M. D. Ernst, “Automatic Plagiarism Detection”, The Computer Journal, vol. 56, pp. 70-86, 2013.
creation of SQL injection and cross-site scripting attacks”, in ICSE’09, [22] J.W. Hunt, and M.D. McIlroy, “An Algorithm for Differential File
Proceedings of the 30th International Conference on Software Comparison”, Technical Report SECLAB-05–04, Bell Laboratories,
Engineering, Vancouver, BC, Canada, May 20–22, 2009. 1976.
[3] T. Scholtea, D. Balzarottib, and E.Kirda, “Have things changed now? [23] A. B. Kleiman, and T. Kowaltowski, “Qualitative Analysis and
An empirical study on input validation vulnerabilities in web Comparison of Plagiarism-Detection Systems in Student Programs”,
applications”, Computers & Security, vol. 31, pp. 344-356, 2012. Technical Report IC-09-08. Instituto de Computação, UNIVERSIDADE
[4] OWASP Top 10 2010, https://www.owasp.org/index.php/Top_10 _2010 ESTADUAL DE CAMPINAS, 2009.
[5] OWASP Top 10 2013, https://www.owasp.org/index.php/Top_10 _2013 [24] M.J. Wise, “String similarity via greedy string tiling and running Karp-
[6] Justin Clarke, SQL Injection Attacks and Defense, Syngress, 2012 Rabin matching”, Deptartment of CS, University of Sydney,
[7] W. G. Halfond, and A. Orso, “AMNESIA: Analysis and Monitoring for ftp://ftp.cs.su.oz.au/michaelw/doc/RKR GST.ps, 1993.
NEutralizing SQL-Injection attacks”, Proceedings of the 20th [25] R.M Karp, and M.O. Rabin, “Efficient randomized pattern-matching
IEEE/ACM international Conference on Automated software algorithms”, IBM Journal of Research and Development - Mathematics
engineering, pp. 174-183, 2005. and computing, vol. 31, pp. 249-260, 1987.
[8] Y.-W. Huang, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo, [26] Y. Huang, S. Huang, T. Lin, and C. Tsai. Web Application Security
“Securing Web application code by static analysis and runtime Assessment by Fault Injection and Behavior Monitoring. In Proceedings
protection”, Proceedings of the 13th international conference on World of the 11th International World Wide Web Conference (WWW 03),
Wide Web, pp. 40 - 52, 2004. May 2003.
[9] M. Lam, M. Martin, B. Livshits, and J. Whaley, “Securing Web [27] OWASP WebGoat Project, https://www.owasp.org/index.php/
applications with static and dynamic information flow tracking”, Category:OWASP_WebGoat_Project
Proceedings of the ACM SIGPLAN symposium on Partial evaluation [28] HackMe bank, http://www.mcafee.com/us/downloads/free-tools/hacme-
and semantics-based program manipulation, pp. 3-12, 2008. bank.aspx
[10] M. Martin, and M. Lam, “Automatic generation of XSS and SQL [29] AltoroMutual, http://demo.testfire.net/
injection attacks with goal-directed model checking”, Proceedings of the [30] L. Suto, “Analyzing the Accuracy and Time Costs of Web Application
17th conference on Security symposium, pp. 31-43, 2008. Security Scanners”, Available: http://ha.ckers.org/
[11] J. Bau, E. Bursztein, D. Gupta, and J. Mitchell, “State of the Art: files/Accuracy_and_Time_Costs_of_Web_App_Scanners.pdf
Automated Black-Box Web Application Vulnerability Testing”, [31] SecTools.Org, http://sectools.org/tag/web-scanners
Proceedings of the 2010 IEEE Symposium on Security and Privacy, pp.
332-345, 2010.

View publication stats