Analyzing Vulnerability of Web Pages through SQL Injection
and Cross Site Scripting
Musham Hasan Mehdi
University School of Information
& Communication Technology
P-76, Anuj Vihar
Shankar Vihar,
New Delhi
mehdi.musham@gmail.com
ABSTRACT
In computer science, analyzing vulnerability is done
through data validation which is the process of ensuring
that a program operates on clean, correct and useful
data. It uses routines, often called "validation rules"
"validation constraints" or "check routines", that check
for correctness, meaningfulness, and security of data
that are input to the system. The rules may be
implemented through the automated facilities of a data
dictionary, or by the inclusion of explicit application
program validation logic. In the contemporary scenario
where the misfeasors are constantly trying to innovate
their malicious intents, the programmers are working
day and night and coming out with innovative measure
to keep the Attacks at bay. In dealing with such
dynamic and changing scenario it becomes imperative
for us to adopt new and innovative methods to counter
such loopholes. [1]The process of Reverse Engineering
comes into play, as we delve into the minds of the
opposing forces. In general philosophy, it is said that to
defeat your enemy you must think like him and attack
where he least expects it. Keeping this in mind, today’s
programmers attack their very own creations in order to
make them more robust and fortified, as the advantage
in such an approach is that, we might have tried out
every possible move of the opponent, thereby leaving
him with less or no option open..
Keywords
input validation, web
language, Security.
application,
programming
1. INTRODUCTION
Web application security is a branch of Information
Security that deals specifically with security of
websites, web applications and web services[2]. At a
high level, Web application security draws on the
principles of application security but applies them
specifically to Internet and Web systems. Typically web
applications are developed using programming
languages such as PHP, Java EE, Java, Python, Ruby,
ASP.NET, C#, VB.NET or Classic ASP. With the
emergence of Web 2.0, increased information sharing
through social networking and increasing business
adoption of the Web as a means of doing business and
delivering service, websites are often attacked directly.
Hackers either seek to compromise the corporate
network or the end-users accessing the website by
subjecting them to drive-by downloading. As a result,
industry is paying increased attention to the security of
the web applications themselves in addition to the
security of the underlying computer network and
operating systems.
avoiding critical mistakes.
2. Collection of Data and Tools
In order to study the characteristics of vulnerable web
applications, it is necessary to have access to a
significant amount of vulnerability data. Hence, we
collected and classified a large number of vulnerability
reports[3]. These vulnerability reports were used to
identify the programming language each web
application was developed in. Furthermore, we used the
vulnerability reports we gathered to semi-automatically
extract vulnerable input parameters from the source
code of web applications[3]. Finally, by automatically
collecting data from a number of open source project
hosting services, we were able to estimate the
popularity of web programming languages.
Table 1
4. Analysis
Figure 1
3. Attacks and Statistics
Web applications have become attractive targets for
attackers due to the large degree of authority they
possess, their significant user populations, and the
prevalence of vulnerabilities they contain. Among the
classes of vulnerabilities exhibited by web applications,
XSS and SQL injection remain among the most serious
threats to web application security[4]. As such, much
attention in the security research community has
focused on removing or mitigating the effect of these
vulnerabilities. XSS and SQL injection vulnerabilities
both manifest at a fundamental level as a failure to
preserve the integrity of HTML documents and SQL
queries, respectively, in the presence of untrusted input
to the web application. In the former case, an XSS
vulnerability allows an attacker to inject dangerous
HTML elements, typically including malicious clientside code that executes in the security context of a
trusted web origin. In the latter case, a SQL injection
vulnerability allows an attacker to modify an existing
database query — or, in some cases, to inject a
completely new one — in such a way that violates the
web application’s desired data integrity or
confidentiality policies[5]. One particularly promising
approach to preventing the exploitation of these
vulnerabilities is robust, automated sanitization of
untrusted input. In this approach, filters, or sanitizers,
are automatically applied to user data such that
dangerous constructs cannot be injected into HTML
documents or SQL queries. Automated protection
against these vulnerabilities is highly desirable due to
the well known difficulty in manually achieving
complete and correct sanitizer coverage.
We first examine whether certain languages are more
prone to XSS and SQL injection vulnerabilities. Then
we analyze the type of the input parameters that
commonly serve as attack vectors, and we compare
them with particular features provided by the web
programming languages, or by the application
frameworks available to them.
5. SQL Vulnerabilities
SQL injection is a code injection technique, used to
attack data-driven applications, in which malicious SQL
statements are inserted into an entry field for execution
(e.g. to dump the database contents to the attacker).SQL
injection must exploit a security vulnerability in an
application’s software, for example, when user input is
either incorrectly filtered for string literal escape
characters embedded in SQL statements or user input is
not strongly typed and unexpectedly executed. SQL
injection is mostly known as an attack vector for
websites but can be used to attack any type of SQL
database.[6]
SQL injection (SQL) is considered one of the top 10
web application vulnerabilities of 2007 and 2010 by the
Open Web Application Security Project. In 2013, SQLI
was rated the number one attack on the OWASP top
ten[6]. There are five main sub-classes of SQL
injection:
-specific SQLI
insufficient authentication
SQL injection + DDoS attacks
QL injection + DNS hijacking
Figure 2
7. Cross Site Scripting : XSS
Cross-site scripting (XSS) is a type of computer
security vulnerability typically found in Web
applications. XSS enables attackers to inject client-side
script into Web pages viewed by other users. A crosssite scripting vulnerability may be used by attackers to
bypass access controls such as the same origin policy.
Cross-site scripting carried out on websites accounted
for roughly 84% of all security vulnerabilities
documented by Symantec as of 2007 [7]. Their effect
may range from a petty nuisance to a significant
security risk, depending on the sensitivity of the data
handled by the vulnerable site and the nature of any
security mitigation implemented by the site’s owner.
Figure 3
8. Discussion
we can conclude that there is empirical evidence to
support the general intuition that input validation serves
as an executive layer of defense against XSS and
SQL injection vulnerabilities[8]. In fact, it is likely that
the
increased usage of strongly-typed languages and
explicit in-put validation functions for web
programming would have similar benefits for other
classes of vulnerabilities, as well as more general
software faults. Note, however, that we observe that
input validation is not a panacea for eradicating
vulnerabilities in web applications. For example, a
particular drawback of the explicit input validation for
complex input data is that the developer is responsible
for applying the appropriate validator to each and every
possible user input that is not already covered by
implicit typecasting. Unfortunately, this is, as
operational experience has demonstrated in the case of
web application output sanitization, an arduous and
error-prone task[8]. Therefore, we advocate that,
analogous to the case of framework support for
automatic output sanitization, web development
languages and frameworks should support the automatic
validation of web application inputs as an additional
security measure against both XSS and SQL injection
vulnerabilities, as well as other security-relevant
application logic flaws.
8. Related Work
Figure 4
Our work is not the first study of vulnerabilities in web
Applications[9]. Fonseca et al. studied how software
faults re- late to web application security[10]. Their
results show that only a small set of software fault[11]
types is responsible for most of the XSS[12] and SQL
injection vulnerabilities in web applications. Moreover,
they empirically demonstrated that the most frequently
occurring fault type is that of missing function calls to
sanitization or input validation functions. Our work
partially corroborates this depending, but also focuses
on the potential for automatic input validation as a
means of improving the electiveness of existing input
validation methods.[10]
Table 2
9. Conclusion
Web applications have become an important part of the
daily lives of millions of users. Unfortunately, web
applications are also frequently targeted by attacks such
as XSS and SQL injection. In this paper, we presented
our empirical study of more than 7000 web application
vulnerabilities and more than 70 web application
development frameworks with the aim of gaining
deeper insights into how common web vulnerabilities
can be prevented[13]. In the study, we have focused on
the relationship between the specific programming
language used to develop web applications, and the
vulnerabilities that are commonly reported.
10. References
[1.] Data Validation, Data Integrity, Designing
Distributed Applications with Visual Studio .NET
[2.] Jump up Arkady Maydanchik (2007), "Data Quality
Assessment", Technics Publications, LLC
[3.] (sections 3.2.3 and 3.4.1) and RFC 5321 – with a
more readable form given in the informational RFC
3696
[4.] Written by J. Klensin, the author of RFC 5321
[5.]
The
associated
errata
http://www.rfceditor.org/errata_search.php?rfc=3696
[6.] Microsoft. "SQL Injection". Retrieved 2013-08-04.
[7.] Imperva (July 2012). "Imperva Web Application
Attack Report"
[8.] Category:OWASP Top Ten Project". OWASP.
Retrieved 2011-06-03.
[9.] "Using SQLBrute to brute force data from a blind
SQL injection point". Justin Clarke. Archived from the
original on June 14, 2008. Retrieved October 18, 2008.
[10.] Andrey Rassokhin; Dmitry Oleksyuk. "TDSS
botnet: full disclosure". Retrieved 6 December 2012.
[11.] Symantec Internet Security Threat Report: Trends
for July–December 2007 (Executive Summary) (PDF)
XIII. Symantec Corp. April 2008. pp. 1–3. Retrieved
May 11, 2008.
[12.] Jeremiah (July 30, 2006). "The origins of CrossSite Scripting (XSS)". Retrieved September 15, 2008.
[13.] http://securitythoughts.wordpress.com/