Hacking With Sql Injection Exposed - A Research Thesis

IV
Apart from bibliographic citations, the contents herein presented,
including graphical design, were solely
produced by Carlos Miguel Barreira Ferreira, the author.
Except where expressly stated otherwise, you are not permitted to copy, broadcast, download, store (in any
medium), transmit, show or play in public, adapt or change in any way the content of thesis for any other purpose
whatsoever without the prior written permission of the author.
© 2006 Carlos Miguel Barreira Ferreira. All rights reserved. Todos os direitos reservados.

in memory of my father and to Jesus, lover of my soul

• a c k •
acknowledgements • a c k •
Hacking with SQL Injection Exposed VII
My first word of gratitude goes of course to my closest family members. I thank my wife
Ana, my young daughter Sara, and my mother, for their loving care and enduring
patience.
I also thank my supervisor, professor Pedro Isaías for the time and effort he commited
into this endeavor, and for his priceless support whenever I needed someone to stand up
for me. His expertise, open mind and insight were invaluable assets on the development
of this research thesis.
My final word of appreciation goes to those friends and professionals who took the time
to review this document. My gratitude to:
• Andreas Goldschimdt, Project Manager at Hewlett-Packard EMEA
• Ângela Martins, HR Partner at Microsoft
• Pedro Machado, Consultant at UNISYS
• Shaun Leisegang, Technical Specialist at SourceCode EMEA

• a b s t r a c t •
abstract • a b s t r a c t •
Hacking with SQL Injection Exposed IX
owadays, information constitutes an organization’s most valuable asset and attacks on it
could threaten the organization’s integrity, availability and confidentiality. Despite the fact
that organizations have committed plenty of resources into security, code injection attacks, where
a remote attacker attempts to fool a software system into executing some carefully crafted attack
code and thereby gain control of the system, have become commonplace in recent years. SQL
Injection is an emerging code injection technique that specifically targets the underlying relational
database management system of an e-Business platform via its frontend which typically is, but by
no means restricted to, a Web page. It literally bypasses all security barriers, shattering the
corporate investments in IT security. Even though such harm can be inflicted, it seems that only
minimal resources are invested in developing security standards and in-built security measures in
Web applications as the SQL Injection topic is still poorly studied.
Using a combination of action research and literature review, this research proposes the first
unifying definition of SQL Injection and the first taxonomy of attacks. This taxonomy is then used
as basis for experimenting on a real e-Business platform in order to answer to the research
question which inquiries if «the weakness of modern e Business systems can be demonstrated by
proving SQL Injection techniques to be effective in obtaining and altering private business data».
This work demonstrates that SQL Injection is indeed an effective means to illicitly access and
manipulate private business data. It also demonstrates that even though some countermeasures
exist, a comprehensive solution is still far into the future. Finally, this work establishes that if an
effective solution is ever to be found it must unify technology, people, processes, and policies,
while accounting for the business problems and challenges organizations are faced with. For the
time being, principles are the best means of addressing the SQL Injection threat in a holistic
fashion. Though this work is all about exposing and not actuality preventing, a compilation of
useful principles has been included.
N

• r e s u m o •
resumo • r e s u m o •
Hacking with SQL Injection Exposed XI
informação constitui hoje o activo mais valioso nas organizações. Ataques especificamente
direccionados à informação colocarão em risco a integridade, disponibilidade e
confidencialidade das organizações. Apesar de estas terem historicamente empregue recursos
consideráveis na componente de segurança, ataques de injecção de código, onde um atacante
remoto tenta manipular um sistema de informação em vista da execução de código malicioso por
parte deste, têm sido cada vez mais comuns ao longo dos últimos anos. SQL Injection é uma
técnica emergente de injecção de código que tem por alvo o sistema de gestão de bases de
dados das aplicações de suporte ao negócio sendo o ataque perpetrado através da interface com
o utilizador que tipicamente aos dias de hoje será possivelmente uma página Web. Esta técnica
permite literalmente evitar as barreiras de segurança existentes, deitando por terra os
investimentos já feitos em segurança. Apesar de tantos danos poderem ser infligidos, dir-se-ia que
apenas recursos mínimos têm sido empregues no desenvolvimento de standards e medidas de
base às aplicações Web pois o tópico do SQL Injection é ainda muito pouco estudado.
Tendo por base uma combinação de action research e revisão de literatura, este trabalho de
investigação propõe a primeira definição unificadora de SQL Injection e a primeira taxonomia de
ataques. Esta taxonomia é seguidamente utilizada na validação experimental da questão de
investigação que indaga se «através de SQL Injection será possível demonstrar a vulnerabilidade
dos sistemas de e-Business ao obterem-se e alterarem-se dados privados do negócio».
Este trabalho demonstra que de facto o SQL Injection é uma técnica eficaz de obtenção e
alteração ilícita de dados privados de negócio. Demonstra-se igualmente que apesar de existirem
algumas medidas preventivas, uma solução global encontra-se ainda longe, tendo ficado claro
que se alguma vez tal solução de carácter abrangente for formulada, terá de equacionar aspectos
tecnológicos, humanos, processuais e procedimentais. Presentemente, o recurso a princípios
apresenta-se como o melhor meio de combinar todos estes factores. Desta forma, incluiu-se uma
compilação de princípios que permitem mitigar a ameaça do SQL Injection.
A

• a b s t r a i t •
abstrait • a b s t r a i t •
Hacking with SQL Injection Exposed XIII
De nos jours, l’information représente l’actif le plus précieux dans une organisation. Des assauts
dirigés exclusivement à cette information pourront éventuellement mettre en danger l’intégrité, la
disponibilité et la confidentialité de l’organisation. Même si, au long des temps, elle se défendait
utilisant des ressources remarquables en ce qui concerne la sécurité, des assauts d’injection de
code, où un assaillant non local s’aventure à manipuler un système d’information en vue de, lui-
même, exécuter un code malicieux, ont été de plus en plus fréquents au long des dernières
années. SQL Injection est une technique émergente d’injection de code ciblant le système de
gestion de base de données des applications de support de l’affaire et l’assaut est réalisé grâce à
l’interface avec l’utilisateur qui, actuellement, peut être une page Web. Cette technique permet de
doubler les obstacles de sécurité, terrassant les investissements déjà faits en sécurité. Malgré
l’imposition d’autant de dommages, seul quelques vaines ressources ont été employées dans le
développement de standards et de moyens de base aux applications Web puisque le topique SQL
Injection est encore très peu étudié.
Ayant comme soutien une combinaison d’action research et une révision de littérature, ce travail
de recherche se propose à, pour la première fois, définir de façon unificatrice SQL Injection et
aussi à présenter la première taxinomie d’assauts. Celle-ci sert de support à la validation
expérimentale de la question de cette recherche qui enquête si «par SQL Injection il est possible de
démontrer la vulnérabilité des systèmes du e-Business par l’obtention et par la modification de
données privées de l’affaire».
Cette recherche prouve que SQL Injection est effectivement une technique efficace à l’obtention et à
la modification illicites de données privées de l’affaire. Elle affirme également que, même s’il existe
quelques mesures préventives, une solution déterministe est bien lointaine. Elle soutient l’opinion
que, si cette solution englobante se formulerait, elle devra tenir en compte des aspects
technologiques, humains, processifs et de conduite. À l’heure actuelle, le recours à des principes
semble être le meilleur moyen d’associer tous ces éléments. C’est pourquoi, une compilation de
principes qui permettent l’adoucissement de la menace du SQL Injection est incluse dans ce travail.

• c o n t e n t s •
contents • c o n t e n t s •
Hacking with SQL Injection Exposed XV
CONTENTS
Contents.............................................................................................................................................15
List of Figures .......................................................................................................................................................... 20
List of Tables............................................................................................................................................................ 22
Introduction......................................................................................................................................23
Background............................................................................................................................................................. 24
4Webbed Organizations............................................................................................................................. 25
4About Security........................................................................................................................................... 30
4Introducing Web Applications.................................................................................................................. 36
4SQL Injection – The Research Topic.......................................................................................................... 43
4About SQL Injection..................................................................................................................................45
4Simple Conceptual Example.....................................................................................................................46
About This Research ............................................................................................................................................... 49
4The Problem and Challenges.................................................................................................................... 49
4The Research Question ............................................................................................................................. 50
4Purpose and Goals.................................................................................................................................... 50

Hacking with SQL Injection ExposedXVI
4Scope..........................................................................................................................................................51
4Motivation..................................................................................................................................................52
4Document Outline.....................................................................................................................................53
Literature Review.............................................................................................................................55
Research Strategy.....................................................................................................................................................56
Findings....................................................................................................................................................................62
4Definition of SQL Injection.........................................................................................................................63
4RDBMS and SQL ........................................................................................................................................66
4Relational Database Management Systems – RDBMS.............................................................................66
4Data Definition Language – DDL..............................................................................................................72
4Data Manipulating Language – DML.......................................................................................................77
4Data Control Language – DCL..................................................................................................................80
4Security in Databases................................................................................................................................80
4World Wide Web.......................................................................................................................................84
4Systems Architectures...............................................................................................................................85
4Security in Applications on the Wild Wild Web.......................................................................................91
Critical Analysis.........................................................................................................................................................96
4Lessons Learned.........................................................................................................................................96
4Direct Implications .....................................................................................................................................98
4Refutation of Arguments...........................................................................................................................98
4Paramount Topics Surrounding SQL-Injection..........................................................................................99
4Additional Research................................................................................................................................ 100
4Projects In This Area................................................................................................................................ 101
Conclusions........................................................................................................................................................... 102
Methodology ..................................................................................................................................103
Research Strategy.................................................................................................................................................. 104
Findings................................................................................................................................................................. 105
4Research Philosophies............................................................................................................................. 106
4Positivism................................................................................................................................................ 106
4Critical Realism....................................................................................................................................... 108
4Interpretivism......................................................................................................................................... 108

Hacking with SQL Injection Exposed XVII
4Research Approaches..............................................................................................................................110
4Deduction .............................................................................................................................................. 110
4Induction................................................................................................................................................ 111
4Research Strategies .................................................................................................................................111
4Experimentation..................................................................................................................................... 111
4Surveys................................................................................................................................................... 112
4Case-Study ............................................................................................................................................. 113
4Grounded-Theory .................................................................................................................................. 113
4Ethnography.......................................................................................................................................... 114
4Action Research ..................................................................................................................................... 114
4Temporal Horizons..................................................................................................................................116
4Multiple Methods: Triangulation............................................................................................................116
Critical Analysis......................................................................................................................................................118
4Lessons Learned ......................................................................................................................................118
4Refutation of Research Approaches .......................................................................................................119
4Direct Implications...................................................................................................................................120
Research Methods ................................................................................................................................................121
Attack Taxonomy............................................................................................................................123
Survey of Techniques............................................................................................................................................124
4Setting the Objective...............................................................................................................................126
4Choosing the Method.............................................................................................................................127
4Data Manipulation................................................................................................................................. 127
4Authentication Bypass........................................................................................................................... 128
4Information Retrieval ............................................................................................................................. 130
4Information Manipulation..................................................................................................................... 130
4Information Fabrication......................................................................................................................... 131
4Information Deletion ............................................................................................................................. 132
4Extending to Other Data Sources with OleDb....................................................................................... 132
4Extending Beyond the RDBMS by Using Command Execution............................................................ 140
4Uploading Files....................................................................................................................................... 142
4Examining Prerequisites ..........................................................................................................................144
4Subqueries ............................................................................................................................................. 145

Hacking with SQL Injection ExposedXVIII
4JOIN........................................................................................................................................................ 146
4UNION ................................................................................................................................................... 147
4Multiple Statements .............................................................................................................................. 148
4Comments............................................................................................................................................. 148
4Error Messages....................................................................................................................................... 148
4Implicit Type Casting.............................................................................................................................. 149
4Variable Morphism................................................................................................................................ 150
4Stored Procedures.................................................................................................................................. 152
4String Concatenation for Building Dynamic SQL .................................................................................. 152
4INTO....................................................................................................................................................... 153
4Weak Policies and Principles.................................................................................................................. 153
4Poking for Vulnerabilities........................................................................................................................ 154
4Unvalidated Input.................................................................................................................................. 154
4Error Message Feedback........................................................................................................................ 155
4Time Delays............................................................................................................................................ 156
4Uncontrolled Variable Size..................................................................................................................... 158
4Type Casting & Variable Morphism....................................................................................................... 159
4Single Quotation Marks in Building Dynamic Queries.......................................................................... 160
4Discovering Database Objects ............................................................................................................... 161
4Offline Research..................................................................................................................................... 164
4Choosing Means..................................................................................................................................... 165
4Web Form Manipulation....................................................................................................................... 166
4URL Header Manipulation..................................................................................................................... 168
4HTTP Header Manipulation................................................................................................................... 169
4Cookie Poisoning ................................................................................................................................... 173
4Designing the Query............................................................................................................................... 175
Toward The Taxonomy......................................................................................................................................... 176
4Unifying Definition for SQL Injection...................................................................................................... 178
4Taxonomy Formulation........................................................................................................................... 179
Experimenting ................................................................................................................................187
Real Environment Test .......................................................................................................................................... 188
Defensive Tactics ............................................................................................................................195

Hacking with SQL Injection Exposed XIX
Technology-Based.................................................................................................................................................197
Principle-Based......................................................................................................................................................204
Conclusions .....................................................................................................................................213
4Introduction......................................................................................................................................................214
4Discussion of Results.........................................................................................................................................217
4Contributions of This Work ..............................................................................................................................220
4Implications.......................................................................................................................................................221
4Limitations of This Work...................................................................................................................................222
4Further Investigation.........................................................................................................................................223
References .......................................................................................................................................225
Glossary............................................................................................................................................231

Hacking with SQL Injection ExposedXX
LIST OF FIGURES
Figure 1 - The Evolution of Business ...............................................................................................................................26
Figure 2 - The Evolution of Information Technology Architectures ...............................................................................27
Figure 3 - The Evolution of the Internet..........................................................................................................................28
Figure 4 - Breakdown of CVE security vulnerabilities found in 2003 and 2004............................................................31
Figure 5 - The Seven Layers of the OSI Model................................................................................................................32
Figure 6 - Typical Web Infrastructure Layout..................................................................................................................34
Figure 7 - The Spaghetti IT Architecture.........................................................................................................................37
Figure 8 - Classic Three-Tier Web Architecture Model....................................................................................................40
Figure 9 - Use of Textual Representation in an Application ...........................................................................................41
Figure 10 - Summary of the Causing Factors of SQL Injection.....................................................................................43
Figure 11 - The Literature Review Process .....................................................................................................................57
Figure 12 - Literature Sources Available ........................................................................................................................62
Figure 13 - Worldwide RDBMS Market Share in 2002.................................................................................................70
Figure 14 - Worldwide RDBMS Market Share in 2003 Excluding Mainframes............................................................71
Figure 15 - Simple Relational Data Structure ................................................................................................................72
Figure 16 - Overriding Table Permissions on MS SQL Server 2005 ..............................................................................83
Figure 17 - No Application Is An Island.........................................................................................................................84
Figure 18 - Bridging the Gap Between Business and IT................................................................................................87
Figure 19 - The Evolution to Services.............................................................................................................................88
Figure 20 - Gartner Web Services Magic Quadrant......................................................................................................89
Figure 21 - Web Services Enabled Service-Oriented Architecture................................................................................90
Figure 22 - The Four Points of Authentication of a Database-Enabled Remote Web Request....................................91
Figure 23 - Authentication Methods in IIS 6.0..............................................................................................................91
Figure 24 - User vs. Account Impersonation on a Web Application............................................................................92
Figure 25 - The Research Process “Onion”................................................................................................................. 105
Figure 26 - Microsoft’s Endorsement of Windows Authentication........................................................................... 137
Figure 27 - Corporate Messaging Software, IB Market Share, 2005 ........................................................................ 138
Figure 28 - Primary Key Information Exchanged via URL Querystring....................................................................... 151
Figure 29 - Sniffing SQL Statements Processed by the RDBMS in Real-Time............................................................ 165

Hacking with SQL Injection Exposed XXI
Figure 30 - Typical Activity Log of a Web Server........................................................................................................175
Figure 31 - Taxonomy of SQL Injection Attacks .........................................................................................................179
Figure 32 - Public Page Used for Proof of Concept....................................................................................................188
Figure 33 - Probing for Possible Injection Entrypoints Via a Web Page.....................................................................189
Figure 34 - Error Message Raised by a Successful SQL Injection Attack....................................................................189
Figure 35 - List of Local Files Obtained via an Error Raised by a Successful SQL Injection Attack.............................192
Figure 36 - SQL Injection Attack Prevented by the Microsoft ASP .NET Framework.................................................202
Figure 37 - Exploitation Prevented by the “Secure by Default” Principle on MS SQL Server 2005...........................202
Figure 38 - The Concept of a Trust Boundary and Chokepoints................................................................................209
Figure 39 - The Knowledge Creation Cycle ................................................................................................................214
Figure 40 - The Height of People, Processes, Policies and Technology in SQL Injection...........................................217

Hacking with SQL Injection ExposedXXII
LIST OF TABLES
Table 1 - System Stored Procedures in MS SQL Server 2005........................................................................................76
Table 2 - Handy Extended Stored Procedures in MS SQL Server 2000...................................................................... 142
Table 3 - Explicit and Implicit Type Conversions in MS SQL Server 2005 .................................................................. 149
Table 4 - Common HTTP Server Variables.................................................................................................................. 172
Table 5 - Taxonomy of SQL Injection Attacks............................................................................................................. 185

Hacking with SQL Injection Exposed
Chapter 1
INTRODUCTION
Every Web Application using a relational database can
theoretically be a subject for SQL Injection attacks. This
research aims to develop the first consolidated taxonomy
of attacks by gathering data from a variety of sources that
encompass academic, professional and underground
fonts, thus providing the means for follow-up studies in
preventing these types of attacks.
This chapter's goal is to present what this research is about and introduce the
research topic to the reader by providing an overview of the facts that lead to the
formulation of the research question and what has already been done in that
field. Later on the chapter, an outline of this work will be presented, as well as
the vision of the author about its relevance, and motivation for carrying it out.

introduction •
BACKGROUND
Hacking with SQL Injection Exposed24
BACKGROUND
According to Livshits & Lam (2005), the security of Web applications has become more
and more important over the last decade as Web-based enterprise applications have
increasingly come to manage sensitive information such as financial or medical data.
Within the Information Society context, if such data gets compromised, losses to
organizations could ascend to millions, not counting intangible losses, e.g. loss of
reputation, which typically take the biggest toll and tend to take longer to dissipate. As a
result, Web applications are becoming more secure due to the growing awareness of
attacks. However, in large and complex applications, a single oversight can result in the
compromise of the entire system (Cerrudo 2002). Despite the fact that organizations
have committed plenty of resources into security, code injection attacks, where a remote
attacker attempts to fool a software system into executing some carefully crafted attack
code and thereby gain control of the system, have become commonplace in recent years
(Linn et al. 2004). SQL Injection is an emerging code injection attack specifically targeting
the relational database management system that is empowering an e-Business platform
via its frontend which typically is, but by no means restricted to, a Web page. It literally
bypasses all security barriers, shattering the corporate investments in IT security. Even
though such harm can be inflicted, it seems that only minimal resources are invested in
developing security standards and in-built security measures in Web applications
(Landsmann & Strömberg 2003;Viega & Messi 2004) as the topic is, up till now, poorly
studied.
But the status quo can be looked upon as the result of a combined set of causes of
different natures, such as organizational, technological and methodological factors.
Therefore, it is essential to characterize these three factors in order to portray the reality
surrounding the research topic. These will be respectively addressed over the next topics.

introduction •
BACKGROUND
Hacking with SQL Injection Exposed 25
4 Webbed Organizations
Throughout the years organizations have striven to reduce costs and leverage the use of
the existing technology assets at their disposal while seeking to improve customer service,
increase competitivity, and be more responsive to the strategic priorities of the business
(Endrei et al. 2004) . If true that these challenges arose long before Information
Technology (IT), essentially as a direct consequence of an open market, they were
deepened by the advent of Information Technology and the Knowledge Society. As a
result, IT executives are constantly struggling to enhance the ability and scope of
corporate communication, allowing more efficient information exchange within their
own organizations as well as between partners in their value chains (Landsmann &
Strömberg 2003).
Two underlying principles exist behind these pressures: Heterogeneity and Change.
Heterogeneity because at any point in time mature organizations are the sum of legacy
systems, applications, architectures, processes (and people) of different vendors and eras.
As to Change, Globalization and the e-Business paradigm have tremendously accelerated
its pace over the past decade or so. According to Mark Endrei et al. (2004), Globalization
leads to fierce competition, which in turn leads to shorter product development lifecycles.
Empowered by rich and easily accessible product information, customers tend to change
requirements rapidly hence feeding an ever-accelerating loop of competitive
improvements in products and services. Whilst some organizations have succumbed to
the pressure imposed by the open competition market, the winning formula appears to
be a combination of agility and flexibility.
As a result, organizations have been evolving themselves, and almost of a sudden,
restructuring became a buzz-word associated to dynamic, forth-going organizations.
From highly hierarchical organizations preceding the 80’s, where business divisions were

introduction •
BACKGROUND
vertical, isolated and segmented into departments, organizations evolved to a more
horizontal business-process-centric layout during the 90’s, toward the new business
ecosystem paradigm where the borders across departments became blurred. This
paradigm shift is depicted on the following diagram:
Figure 1 - The Evolution of Business
> adapted from (Endrei et al. 2004) <
But if this is what has been happening to organizations, where does that leave the
corporate IT environment? Business processes no longer pay respect to the sacred, yet
invisible, line separating business units as they all must now cooperate on a mesh of
interactions and players. The mesh itself keeps getting redefined according to the
requirements of the business, yet, the classic business challenges such as cost-reduction
seem to make a stand that agility and flexibility come at high price. Race (2003) indicates
on her report that the base IT challenges organizations are faced with remain essentially
the same. She points out the following challenges as the most relevant:
• Business processes are, by definition, hard to amend;
80’s and before 90’s The New World

introduction •
BACKGROUND
• Integrating different systems is not scalable;
• Non-reutilization of common functional modules, represents financial losses
and reduces interoperability;
• Although there are emerging technologies to address these issues, these are
still immature and troubled by the lack of standards.
Moreover, the evolution of the Internet has laid a foundation for the development and
usage of new categories of Information Technology systems operating on the Web
(Landsmann & Strömberg 2003). While the Web presents itself as a major business driver
promoting research and development of new technologies and standards, and
consequently taking systems architectures one step further, the danger of leaving old
problems behind stands tall.
Figure 2 - The Evolution of Information Technology Architectures
By the time client-server architectures began to be widely used, unstructured data
management, such as the file system, was already mature and looked upon as a
commodity. But the whole purpose of client-server was to serve and consume structured
data. This lead to the appearance and improvement of new and more sophisticated
relational database management systems (RDBMS)1
especially designed for operating
1
According to its role, whether operational or analytical, they can respectively be referenced as OLTP or OLAP.
Although the research topic is transversal to the database role, the focus will reside upon OLTP databases.
SSttrruuccttuurreedd
MMoonnoolliitthhss
CClliieenntt//SSeerrvveerr
33--TTiieerr
NN--TTiieerr
DDiissttrriibbuutteedd
OObbjjeeccttss
CCoommppoonneennttss
SSeerrvviicceess

introduction •
BACKGROUND
within a networked environment2
. But data structuring is just part of the justification for
the prominent role of the RDBMS. According to eXtropia (2006), these systems allow to
store, retrieve and modify data with efficiency regardless the amount of data being
manipulated. But more important, databases have quickly become integral to the design,
development, and services offered by the organizations, and the foundation stone on
which their operational, tactical and strategic business model is based upon. Since the
time of client-server down to Service-Oriented Architectures (see figure 2 on the previous
page), databases have matured and grown in scope within the organizations.
And then the Web came. Informational websites, e-Commerce websites, extranets,
intranets, data exchange, search engines, e-Business, and more, spread like wild fire.
Figure 3 - The Evolution of the Internet
> adapted from (Chakrabarti 2003) <
The World Wide Web, or Web for short, provides connectivity, online access to
information and services, anytime, anywhere around the globe. Corporations quickly
realized the potential of this new revenue stream, and steadily began to adhere to Web
applications by connecting their systems to the Web. Halfond & Orso (2005b) describe
2
There are others that fit this category, such as object-oriented databases, but they are out-of-scope for this work.

introduction •
BACKGROUND
this reality by stating that database-driven Web applications have become widely
deployed on the Internet, and organizations use them to provide a broad range of
services to their customers. As a result, and according to Uzi Ben-Artzi Landsmann &
Donald Strömberg (2003), the business environment has progressively gotten
decentralized. Unlike earlier revolutions, where most of the action occurred within the
corporate protected network environment, and mostly because of the e-Business
paradigm, core business databases have increasingly been exposed to unrestrained
networks such as the Internet by means of various frontends and intricate
multilayer-architectures. This lead to an improvement on the architectures, causing
Service-Oriented Architectures (SOA) to emerge. SOA promotes a business view in
opposition to a technology-centric understanding of the corporate IT environment, by
endorsing abstraction and standardization. Even though business people are getting
more and more control, however, according to Race (2003) the top-level IT challenges
organizations are faced with, still, remain basically the same. In other words, technology
does not solve business problems!
In summary, organizations had to keep the pace with the demands imposed by a
fast-moving market, causing departmental boundaries to blur, and thus providing
the stage for the implementation of transversal business processes. IT became more
business-centric by means of abstraction and standardization as per the
Service-Oriented Architectures approach. The advent of the Web carried the sight of
new unexplored markets, and the promise of success within reach of those who
would move in first. Databases were the keystone providing the reliability the
business had always required and the necessary scalability for expansion into the
Web. But the pressure imposed by a ferocious competition and the rush to conquer
a new vast market unfortunately kept old problems unsolved. Organizations have
grown in complexity and are no longer standing alone, but webbed on the Web.

introduction •
BACKGROUND
4 About Security
The second factor causative of the research topic is of technical nature, as it would be
impossible to address Hacking without referring to security and some technicalities
underneath it.
According to Dieter Gollmann (2006), computer security is the prevention and detection
of unauthorized actions performed by users of a computer system, encompassing three
key goals: integrity, confidentially and availability, which can be ensured by three leading
mechanisms: authentication, encryption and access control3
(Blake 2003;Gollmann
2006). Integrity deals with the prevention of unauthorized modification of information.
Confidentially deals with the prevention of unauthorized disclosure of information, and
availability with the prevention of unauthorized withholding of information or resources.
The primary assets used by an application can be divided into two groups: information
and equipment. Information refers to the data that is stored within the application and
provided to the end-user. Equipment refers to the hardware and software used to deliver
the application (Blake 2003). Although the above mentioned security key goals and
mechanisms are applicable to both information and equipment, things get more serious
when the most treasured asset within an Information Society is threatened: Information
itself. The historical commonness of buffer overflow attacks as an intrusion mechanism
(Boyd & Keromytis 2004;Landsmann & Strömberg 2003;Viega & Messi 2004) has
resulted in substantial research focused on the problem of detecting, preventing and
containing such attacks (Boyd & Keromytis 2004;Landsmann & Strömberg 2003).
Furthermore, according to Uzi Ben-Artzi Landsmann & Donald Strömberg (2003) and the
OWASP project (2006), corporations and security professionals have traditionally
3
These and additional security services and mechanisms will be properly addressed on the Literature Review
chapter.

introduction •
BACKGROUND
committed most of their resources into networking and operating system security.
Therefore, attack methods aiming at these components have been known for some time
and standardized countermeasures have been put in place. On the other hand,
considerably less attention has been paid to attacks at the application level, such as
injection attacks like SQL Injection. According to literature (Álvarez & Petrovic 2003;Boyd
& Keromytis 2004;Gaurav, Angelos, & Vassilis 2003;Huang et al. 2003;Kost
2003;Landsmann & Strömberg 2003;Linn et al. 2004;McDonald 2002;OWASP 2006;Xu,
Bhatkar, & Sekar 2005), Web masters and systems administrators around the globe have
been witnessing a rapid increase in the number of attacks on Web applications.
According to research (Xu, Bhatkar, & Sekar 2005), the breakdown of the common
vulnerabilities and exposures (CVE) in 2003 and 2004 is shown on the next chart:
Figure 4 - Breakdown of CVE security vulnerabilities found in 2003 and 2004
> adapted from (Xu, Bhatkar, & Sekar 2005) <
Design Errors
30%
Directory Transversal
4%
Format String
3%
URL encoding and related 1%
Command Injection 5%
Configuration 3%
Cross-site Scripting 5%
SQL Injection 2%
Other 5%
Memory Errors 22%
DOS
20%

introduction •
BACKGROUND
HTTP FTP Telnet
Ethernet ATM
MAC Address
IP ICMP SNMP
TCP UDP SPX
HTTPS
RPC NETBios
A quick review of the previous chart in will yield that only 23% of the security
vulnerabilities are related to networking and operating system as configuration and
Denial of Service (DoS) are the only set of vulnerabilities fitting into this category. The
remaining part is related to application vulnerabilities in any manner. Concentrating on
this set of threats, the chart corroborates that buffer overflows, same as memory errors, is
the most common intrusion mechanism. Unfortunately, as the chart represents a
snapshot of the reality within a limited interval of time, it is not possible to corroborate
the growth of code injection attacks. One can only infer that the small percentage of
code-injection attacks, and more precisely SQL Injection attacks, is due to its relative new
appearance in the hacking scene. So if there is a clear distinction between attacks aiming
the infrastructure and those aiming the application, let’s drill-down a bit and introduce
the OSI model depicted on the following diagram:
Figure 5 - The Seven Layers of the OSI Model

introduction •
BACKGROUND
The complexity and scope of the OSI model spans way beyond the domain of this work
and therefore only its relevant bits and pieces will be herein described. The OSI model
was developed by the ISO subcommittee and it does not target any specific technology
since it is a framework. What is important to retain from the diagram is the existence of a
layered model which defines a flow of interactions depending on the communication’s
direction. Although the OSI model is not tied up to any particular technology, most of
the protocols shown on the diagram reflect the reality of today’s Web systems, which
depend on HTTP, which in turn uses IP. According to Dawson et al. (2006), TCP is the de
facto standard transport protocol in today’s operating systems and is a very robust
protocol that adapts to various network characteristics, packet loss, link congestion, and
even significant differences in vendor implementations. As security awareness grew over
the years, new TCP-IP based devices and protocols were developed in order to ensure the
previously mentioned prime goals of security. Network appliances now span from simple
network bridges to application-level firewalls and intrusion detection systems (IDS). The
evolution of such devices was not surprisingly in line with the OSI model as attacks
seemed to follow that pattern. The more sophisticated the attack was, the higher its
target was on the hierarchy of layers. So firewalls, the pinnacle set of devices that protect
the resources of one network from users from other networks, evolved to
application-level firewalls in the hopes of stopping attacks happening at this level. But the
intelligence of such devices is limited. They can detect, for example, if HTTP is being used
on a predefined port as opposed to an unexpected telnet session that could potentially
mean that a successful attack was in place. But if the application protocol is inline to
what is expected, although a logical attack like SQL Injection could be in place, these
devices are rendered as inadequate in such situations (Halfond & Orso 2005a). Due to
this limitation, Intrusion Detection Systems were developed. They try to discover
behavioural patterns in order to determine if an attack is indeed in place, but IDSs are

introduction •
BACKGROUND
only as smart as their knowledge database and are known to be prone to false positives.
Back to the chart in Figure 4 - Breakdown of CVE security vulnerabilities found in 2003
and 2004 on page 31, what makes applications so appetizing is the fact that ordinary
networking safeguards can be bypassed by carrying out a logical attack on the
application. These attacks try to fool the application into executing some carefully crafted
code on the hacker’s behalf using the application’s security context. The following
diagram depicts a common corporate architecture that offers a set of Web-based
applications that depend on corporate key systems.
Figure 6 - Typical Web Infrastructure Layout
Basically, most Web servers are separated from clients by firewalls (Landsmann &
Strömberg 2003); in this case two firewalls are used for providing two protected zones of
security. Remote users on the public zone, the Internet, perform legitimate requests to a
system sitting in the corporate demilitarized zone (DMZ). These requests can vary in
nature, but for the sake of simplicity let’s assume it is a standard Web request triggered
by a user using any standard Internet browser. The default rule of a firewall is to deny all
PPuubblliicc
ZZoonnee
DDeemmiilliittaarriizzeedd
ZZoonnee
PPrriivvaattee
ZZoonnee hhttttpp::8800
ssqqll::11443333

introduction •
BACKGROUND
requests, thus forcing a declarative security model. In order to allow public requests to be
addressed by the proper system, the public firewall is configured to allow incoming
requests using the HTTP protocol (layer 7 of the OSI model) on its expected default port
number 80. Subsequently, it is common that such systems on the DMZ require access to
some corporate business systems, sitting within the corporate private environment.
Probably the most typical scenario would be access to a relational database management
system. Using the same logic as before, the second firewall permits such requests coming
from a server on the DMZ depending on the expected incoming and outgoing protocol
types, requesting entity and destination system. So trying to use blocked ports to access
other kind of services is very difficult from a hacker’s perspective sitting on the public
zone, especially when firewalls have the ability to read protocols on layer 7. On the other
hand, if the remote user fools the application on the DMZ to perform illicit tasks on his
behalf, from a network security point of view no attack will be in progress, but the
privileged security context of the application itself allows piggy-backing malicious code on
a legitimate request.
In summary, Web attacks, i.e. attacks exclusively using the HTTP/HTTPS protocol, are
rapidly becoming one of the fundamental threats for information systems
connected to the Internet (Álvarez & Petrovic 2003). Such attacks target databases
that are accessible through a Web frontend, and take advantage of flaws in the
input validation logic of Web components (Boyd & Keromytis 2004). This is so
because although most Web servers are separated from clients by firewalls and
other security devices, however from a security perspective, Web applications offer
users legitimate channels through firewalls into corporate systems. When launched
from within the application logic, attacks are in general harder to detect and
protect against (Landsmann & Strömberg 2003;OWASP 2006;Spett 2002).

introduction •
BACKGROUND
4 Introducing Web Applications
Now that both organizational and technical factors surrounding the research topic have
been outlined, the remaining set of factors is of methodological nature. The OWASP
project (2006) states that any software application built on client-server technology that
operates on the Web and interacts with users or other systems using HTTP, could be
classified as a Web application. These applications aim to provide connectivity and access
to online services and information to users. Spett (2002) indicates that they range from
simple to very complex, and each has a distinct purpose. OWASP (2006) goes further into
detail by stating that nowadays high-end Web applications encompass realtime sales and
inventory across multi-vendors, including Business-To-Business and
Business-To-Consumer, flow of work and supply chain management, and legacy
applications.
In Information Technology, legacy applications and data are those that have been
inherited from languages, platforms, and techniques earlier than the current technology.
In the past, most programming targeted specific operating systems. A quick search on
the Wikipedia (2006e) will yield that in the IT industry, legacy is defined as «an antiquated
computer system or application program which continues to be used because the user
(typically an organization) does not want to replace or redesign it». These systems
typically are monoliths (see Figure 2 - The Evolution of Information Technology
Architectures on page 27) and complex, resulting in prohibitive redesign costs.
Furthermore, they tend to be highly-available systems with nearly 100% uptime, with
little or no existing documentation on how the system operates, resulting in the inability
to expand and update it. On the other hand, since the .COM bubble burst another point
of view has arisen. The Wikipedia (2006e) defines it as «legacy systems are simply (and
only) computer systems that are both installed and working». So it all comes does down

introduction •
BACKGROUND
to the risk and cost of change, compared to the possible benefit resulting from the
replacement of such systems. Although the following picture pretends to be a satyr of
some intricate IT architecture drawn on a flipchart during an IT staff meeting, it could
very well represent a real scenario of an organization that has grown overtime, but kept
its legacy systems operating.
Figure 7 - The Spaghetti IT Architecture
Managing such architecture would definitely be a nightmare, no matter how good, or
how many professionals are in-charged of that burden. What is sought by presenting this
scenario is that avoiding a long-term IT architecture to become an uncontrolled monster
requires a whole lot of effort and discipline. But medium to large organizations simply
cannot get rid of core business systems at the same rate they become legacy. As
architectures evolve (see Figure 2 - The Evolution of Information Technology Architectures

introduction •
BACKGROUND
on page 27), more and more abstraction layers are put on top of the previous, but one
cannot forget that at the very core, legacy systems and code are still present. Viega and
Messi (2004) cite an informational study based on security reviews of commercial code
where it was observed that C code – the de facto language used for coding some of the
eldest systems still running, such as the UNIX operating system – tends to have five to ten
times more vulnerabilities than Java code. Shankar et al. cited by Yao-Wen Huang et al.
(2004) detected insecure information flow within legacy code with little additional
annotation. According to Anh Nguyen-Tuong et al. (2004) it is tedious to review code
and look for vulnerabilities and this can result in some vulnerabilities to be overlooked. So
if in normal situations, where documentation and thorough knowledge of the code are
present, it is a difficult task to search and detect possible vulnerabilities, when it comes to
legacy, where by definition existing operating knowledge and documentation is scarce,
this could be an almost impossible task to achieve.
But more advanced systems, architectures and programming languages do not
necessarily mean a more hardened end-product. Viega and Messi (2004) state that
«although languages such as Java give programmers fewer chances to shoot themselves
in the foot than C does, there is still plenty of opportunity to take off some toes». In
addition to this, Web applications tend to have rapid development cycles (Huang et al.
2003). But the problems during development do not end up with the stress imposed by
rapid development cycles. Developers and development teams can be awfully
inconsistent. The programmer who worked on Function A in Script A might have nothing
to do with Function B in Script A, so while one parameter in Script A might be
vulnerable, another might not (Spett 2002). Spett also claims that one can never be sure,
and therefore, everything should be tested. But this is exactly where another problem
begins. According to Anh Nguyen-Tuong et al. (2004), although security plays a critical
role in nearly all Web applications, only a small fraction can afford a detailed security

introduction •
BACKGROUND
review. Because of this pressing need for speed and streamlining of the development
phase, the industry responded accordingly and developers today have a vast set of rapid
Web development frameworks and technologies, including Sun's J2EE (Java Server Pages,
Servlets, Struts, etc.), Microsoft's ASP and ASP.NET, PHP, and the Common Gateway
Interface (CGI) and all of these models make use of a tiered environment (Buehrer, Weide,
& Sivilotti 2005). But as stated earlier on this document, technology only facilitates. It
does not solve business problems, meaning, it is a big aid to have the industry
backing-up professionals and organizations with more and more advanced technologies
and frameworks, but at the end of the day success will be dictated by the installed
behaviours and methodologies.
Since the client-server architecture, applications are modelled into different logical layers
and subsequently, the supporting hardware infrastructure into tiers (Landsmann &
Strömberg 2003). Although there is some discussion around whether layers fit into
applications and tiers into infrastructure or vice-versa, the first option will be herein
preferred since it is closer to the de facto naming-conventions employed by the industry.
Understanding how the application is going to be deployed has a critical impact on its
design. In fact, defining the solution architecture is a pre-step when making use of the
Web development frameworks mentioned above. Whether if layers constrain tiers or tiers
dictate the definition of layers, it is irrelevant. Solution architects must look at the grand
picture when designing a Web solution. A typical Web solution entails three layers: the
presentation layer, middle layer, also known as business objects, and data layer (Buehrer,
Weide, & Sivilotti 2005;Landsmann & Strömberg 2003).

introduction •
BACKGROUND
Figure 8 - Classic Three-Tier Web Architecture Model
The presentation layer is typically represented by an Internet Browser and comes in the
form of HTML, although other types of content could be delivered. The middle layer is
where the business rules and logic that drives the application is defined, and finally, the
data layer providing data storage and retrieval services (Buehrer, Weide, & Sivilotti
2005;Landsmann & Strömberg 2003). These layers could be part of a more complex
architecture as in Figure 2 - The Evolution of Information Technology Architectures on
page 27, but the base actors are those defined by the classic three-tier Web architecture.
The database, Web server and application logic components are all parts of a larger
system (Landsmann & Strömberg 2003) no matter if these components are
tightly-coupled or loosely-coupled. Flaws in one component will certainly jeopardize the
whole solution as a chain is never stronger than its weakest link. Because this research
focuses on the bottom layer, the data layer, the remaining layers will not be described in
detail.
PPrreesseennttaattiioonn
IInntteerrnneett BBrroowwsseerr aanndd HHTTMMLL
BBuussiinneessss LLooggiicc
EEnnccaappssuullaatteedd BBuussiinneessss OObbjjeeccttss
DDaattaa
RReellaattiioonnaall DDaattaabbaassee

introduction •
BACKGROUND
One of the main reasons why this research aims at studying the data layer is due to its
paramount role in Web applications that deliver dynamic content, and therefore make
e-Business possible. Halfond & Orso (2005a) state that «many organizations have a need
to store sensitive information, such as customer records or private documents, and make
this information available over the network. For this reason, database-driven Web
applications have become widely deployed in enterprise systems and on the Internet».
Buehrer, Weide, & Sivilotti (2005) go even further and state that Web applications
employing database-driven content are ubiquitous. Not just Internet companies such as
Yahoo or Amazon, but also companies of the old-economy require a presence on the
Web, and almost always, this presence in ensured by means of a relational database. In
its simplest form, Web applications receive inputs coming from the user, forward them to
the business logic layer, which according to its rules will react according to the user’s
input, let’s say, when searching for a specific product, which in turn will be performing
some kind of task on the data services end.
Figure 9 - Use of Textual Representation in an Application
> adapted from (Pietraszek & Berghe 2005) <
TTeexxttuuaall
RReepprreesseennttaattiioonnss
NNeettwwoorrkk IInnppuutt
GGeett,, PPoosstt,, CCooookkiiee
DDiirreecctt IInnppuuttss
aarrgguummeennttss,, eennvv..
SSttoorreedd IInnppuuttss
DDBB,, XXMMLL,, CCSSVV
EExxeeccuuttee
sshheellll,, XXSSLLTT
QQuueerryy
SSQQLL,, XXPPAATTHH
LLooccaattee
UURRLL,, ppaatthh
RReennddeerr
HHTTMMLL,, SSVVGG
SSttoorree
DDBB,, XXMMLL
ccoonnssttaannttss
inputs outputs

introduction •
BACKGROUND
Figure 9 describes the various types of inputs an application may receive, and the
corresponding outputs it may generate. In a way, this diagram also depicts the three-tier
Web architecture, but using a horizontal approach centered around the logic beneath
the application, making it easier to discern the cause-effect outcome of the user input on
the outputs. The commonality across the various types of inputs and outputs is the fact
that all have a textual representation within the application and this is where code
injection attacks effectively go into action.
In summary, organizations cannot get rid of core business systems at the same rate
they become legacy, but legacy applications are known to be prone to development
errors (Huang et al. 2004;Viega & Messi 2004). While reality dictates that legacy
systems are integral part of the corporate IT infrastructure, they now have to endure
the pressure caused by the Web shift although they were never designed to
withstand such demand. In addition, Web applications tend to have rapid
development cycles (Huang et al. 2003). And although security is critical in almost
every Web application (Spett 2002), only a small fraction can afford a detailed
security review (Nguyen-Tuong et al. 2004). Web architectures are normally divided
in tiers, and flaws in one component will certainly jeopardize the whole solution. As
a result, most Web applications contain security vulnerabilities and serious security
vulnerabilities are regularly found in the most prominent commercial Web
applications including Gmail, eBay, Yahoo, Hotmail and Microsoft Passport (Nguyen-
Tuong et al. 2004). The dependency of Web applications on relational databases
and the role of databases within the organizations certainly elect it as a tempting
target for anyone seriously looking for crippling an organization, or gain personal
benefit.

introduction •
BACKGROUND
4 SQL Injection – The Research Topic
So far the reader has been taken on a journey across the three factors dictating the status
quo surrounding the research topic and the underlying causes behind logical attacks such
as SQL Injection attacks. These three factors are of organizational, technological and
methodological nature. The following diagram attempts to summarize the findings
portrayed on the preceding topics on consolidated view:
Figure 10 - Summary of the Causing Factors of SQL Injection
Throughout the years organizations have striven to reduce costs and leverage the use of
the existing technology assets at their disposal while seeking to better customer service,
improve competitivity, and be more responsive to the strategic priorities of the business
(Endrei et al. 2004) . This caused departmental boundaries to blur, providing the stage for
PPrroobblleemmss
RReemmaaiinneedd EEsssseennttiiaallllyy tthhee SSaammee
SSyysstteemmss IInntteeggrraattiioonn,, PPeeooppllee MMggmmtt,,
UUppddaattiinngg BBuussiinneessss PPrroocceesssseess
CChhaalllleennggeess
RReemmaaiinneedd tthhee SSaammee
CCoosstt--RReedduuccttiioonn,, RReevveennuuee
TTiimmee--ttoo--MMaarrkkeett
TTeecchhnnoollooggiiccaall >>
IITT SSeeccuurriittyy
MMaattuurree mmeecchhaanniissmmss ffoorr iinnffrraassttrruuccttuurree sseeccuurriittyy
IInneeffffeeccttiivvee mmeecchhaanniissmmss aaggaaiinnsstt llooggiiccaall aattttaacckkss
MMeetthhooddoollooggiiccaall >>
WWeebb PPaarraaddiiggmm
EExxppoonneennttiiaall ggrroowwtthh ooff iinntteerrccoonnnneecctteedd ssyysstteemmss
LLeeggaaccyy ssyysstteemmss aarree pprroonnee ttoo ddeessiiggnn ffllaawwss
DDaattaabbaasseess eennaabbllee ee--BBuussiinneessss,, bbuutt ddeeppeenndd oonn lleeggaaccyy
RRaappiidd ddeevveellooppmmeenntt ccyycclleess
OOrrggaanniizzaattiioonnaall >>
EEccoossyysstteemm PPaarraaddiiggmm
BBuussiinneessss UUnniittss aarree nnooww ppaarrtt ooff aann eeccoossyysstteemm wwiitthhiinn tthhee ccoommppaannyy
OOrrggaanniizzaattiioonnss aanndd IITT aalliiggnneedd ttoo ttrraannssvveerrssaall bbuussiinneessss pprroocceesssseess
Logical attack against data
and core business systems
via a front-end

introduction •
BACKGROUND
the implementation of transversal business processes. IT became more business-centric in
response to the Web shift even though the basic business problems and challenges
remained essentially the same. The advent of the Web carried the sight of new
unexplored markets, but the conquering rush unfortunately kept old problems unsolved.
Organizations have grown in complexity and size in great measure thanks to the
reliability and scalability of database management systems. As a result, security
increasingly became a concern and Web attacks are rapidly becoming one of the
fundamental threats for information systems connected to the Internet (Álvarez &
Petrovic 2003). This relatively new phenomenon can partially be explained by the
popularity of Web applications and techniques to exploit their security vulnerabilities
(Buehrer, Weide, & Sivilotti 2005). While most Web servers are separated from clients by
firewalls and other security devices, still from a security perspective, Web applications
offer users legitimate channels through firewalls into corporate systems. Often, these core
corporate systems are still comprised of legacy systems and applications. They now have
to endure the pressure caused by the Web shift although they were never designed to
withstand such demand, though it is a proven fact that such applications are prone to
design flaws (Huang et al. 2004;Viega & Messi 2004). The dependency of Web
applications on relational databases and core business legacy systems and the role of
databases within the organizations certainly elect them as a tempting target. This lead to
the proliferation of logical attacks which try to fool the application into executing some
carefully crafted code on the hacker’s behalf using the application’s security context. SQL
Injection is a type of code-injection attack targeting databases that are accessible,
typically through a Web frontend, which takes advantage of flaws in the input validation
logic of application components in order to achieve its purposes.

introduction •
BACKGROUND
4About SQL Injection
SQL, acronym for Structured Query Language, is a standard interactive and programming
language for getting information from and updating a database. Melton (1996) defines
it as a relational database data sublanguage. Although SQL is both an ANSI and an ISO
standard, many database products support SQL with proprietary extensions to the
standard language4
. Queries take the form of a command language (Anley 2002b).
Anley also adds that the typical unit of execution of SQL is the “query”, which is a
collection of statements that typically return a single “result set”. SQL statements can
modify the structure of databases (using Data Definition Language statements, or DDL)
and manipulate the contents of databases (using Data Manipulation Language
statements, or DML). As a standard language for all relational database management
systems, one cannot say SQL Injection is caused by flaws of a specific product, but is
rather the result of failure to validate inputs within the applicative components5
.
Literature provides an extensive set of definitions for SQL Injection which orbit fairly close
around the same base concept. Álvarez & Petrovic (2003) provide a broad and simple
definition by stating that an SQL Injection attack is in place when «an attacker creates or
alters existing SQL commands to gain access to unintended data or even the ability to
execute system level commands on the host.». Yet Yao-Wen Huang, Shih-Kun Huang, Lin,
& Tsai (2003) prefer to center it on the Web. This view is also shared by several other
sources (Anley 2002b;Boyd & Keromytis 2004;Cerrudo 2002;Huang et al. 2004;Kost
2003). In summary, these sources define SQL Injection as a flaw on the input validation
logic of a Web application that via a Web frontend receives user input containing
4
The SQL dialect used on this work will be Microsoft’s, also known as Transact-SQL.
5
As the topic is RDBMS-agnostic, this work will use Microsoft SQL Server, one if not the most popular RDBMS, as
the base platform whenever examples or experimentation take place

introduction •
BACKGROUND
malicious patterns used on the construction of a legitimate SQL query, ultimately leading
to the arbitrary execution of SQL and operating system commands.
4Simple Conceptual Example
As a motivating example, let’s consider a scenario of an online banking application that
allows customers to log in and view their accounts, make payments, and so on and so
forth. In order to access these services, customers must undergo a compulsory
authentication step by providing logon credentials in the form of a username and a
password on a dedicated page specially created for that purpose. This Web page
represents the third tear of the classic Web application model (consult Figure 8 - Classic
Three-Tier Web Architecture Model on page 40). When data is submitted to the
middle-tier, the corresponding applicative modules (ASP, JSP, CGI, Perl, etc.) will take the
user’s input and use it for building a query to be executed against the data-tier. The data-
tier is almost always represented by a relational database management system and
consequently the query built by the middle-tier components is written on the SQL dialect
of that RDBMS. On this scenario, a typical validation query would look similar to this:
The SQL language was designed to be similar to English and anyone without any
knowledge of SQL could probably understand the meaning of the expression. It queries
the database for all the information registered for user “Miguel” with password “secret”,
which implicitly denotes that a response is expected. Among other actions, this response
will be used to determine if the user has successfully authenticated6
by proving his
6
Authentication is only one out of three principal mechanisms applied for ensuring security’s key goals.
Encryption and access control complete this set.
Select * From Users Where Login='Miguel' and Password='secret'

introduction •
BACKGROUND
identity. For example, if the database response is empty, the underlying implication is that
there is no such user named “Miguel” with password “secret” on record. On the other
hand, a valid response from the database would inform the components on the
middle-tier that the user is authentic. The middle-tier then produces an output to the
presentation-tier according to the business rules. This output typically represents the very
next Web page the user is presented with and its contents are contextualized according
to the user data returned by the database. Furthermore, it is common for this output to
contain a security token which will enable the user to perform various consequent actions
on the application without the need for re-authenticating. In this scenario, the output
should be a Web frontend containing a security cookie and exhibiting a set of menus
with options that enable the user to view his account movements, make payments and
perform all sorts of financial transactions. How does SQL Injection fit into all this?
Suppose the user is knowledgeable about it and decides to perform a logical attack on
the application by injecting some malicious code on the user and password textboxes on
the logon Web page in the hopes to fool the authentication logic of the underlying Web
application. Consider the following value for username and password:
This simple text string does not require any special tool to develop, nor any hacking
program to send it to the Web server. The resulting validation SQL query performed by
the middle-tier against the database would look like:
Select * From Users Where
Login='X' OR 'A' = 'A' and Password='X' OR 'A' = 'A'
X' OR 'A' = 'A

introduction •
BACKGROUND
Analyzing this query is a little more complicated than the previous as a logical analysis is
required. First, the resulting query is well-formed in terms of its syntax. Second, its
semantics is kept unaltered, meaning no other structures or database objects are therein
referred. In other words, no knowledge of the database structure was required. Third and
most important, the WHERE expression evaluates to true. “A” is equal to “A”, then the
expression evaluates to true. Binary logic dictates that False OR True = True. In common
words, if something is false or is true, for example if someone says «I’m male or I’m
female», the outcome is always true. So if the login is “X’ which is probably false, but “A”
is always equal to “A”, then that piece of the expression always evaluates to true. Likewise
happens on the second portion which contains the evaluation of the password. So the
remaining logical expression to evaluate is comparing the “True” resulting from the login
evaluation and the “True” resulting from the password evaluation. This comparison using
the AND logical operator yields “True”, resulting in the authentication mechanism to be
bypassed and proving free access to the account of the unlucky user who had the
privilege to be listed at the top.
All networking security mechanisms were bypassed as a legitimate channel was used to
reach out to the database. Furthermore, Web requests such as the one depicted on the
example are often transmitted in the form HTML form posts. Due to the data load, such
requests are typically not logged, hence making the attack virtually undetected as no
activity trail has been left behind. This rather simple example demonstrates the power of
this technique and the losses it can inflict on people and organizations.

introduction •
ABOUT THIS RESEARCH
ABOUT THIS RESEARCH
Up to now the research topic, its background and status quo have been broadly outlined,
all with the purpose of introducing the goals that stand behind this research, its purpose,
motivation, and most important of all, the research question. These will be properly
addressed over the next subtopics.
4 The Problem and Challenges
The statement of Landsmann & Strömberg (2003) that «Every Web Application using a
relational database can theoretically be a subject for SQL Injection attacks» summarizes in
a very neat way the seriousness of the SQL Injection threat and the overwhelming
challenge of countermeasuring it. Three key points surface from the Background topic as
the foremost factors supporting this statement: a) this type of attacks caught
organizations completely unprepared as it tears down existing security barriers, thereby
shattering existing investments in IT security; b) it is a relatively new problem as the
Internet comes forth as “The” catalyser responsible for the increase on the number and
diversity of attacks; c) lack of awareness is probably the single most important factor
accountable for this technique’s success, causing other researchers and IT experts to get
held back on their efforts to further investigate and address this issue in a consistent and
systematic way. By now it is clear the edge stands on the hacker community side and
literature states that it seems that only minimal resources are being invested (Landsmann
& Strömberg 2003). Furthermore, the lack of academic literature on the subject is
astonishing, and while the IT industry has begun awakening to the problem, the number
of rich and ingenious available resources scattered across hacking sites and underground
communities is absolutely remarkable compared to what researchers and IT experts have
as baseline for their studies.

introduction •
ABOUT THIS RESEARCH
4 The Research Question
«Can the weakness of modern e-Business systems be demonstrated
by proving SQL Injection techniques to be effective in obtaining and
altering private business data? »
The research question almost comes naturally from the research topic, and although it
looks pretty straightforward and a subject of experimentation in order to confirm what
literature states, the hard work lies beneath. As previously stated, the topic has been
neglected as the growth of attacks is fairly recent, and therefore there are few studies
that can be used as support basis. For that matter, it is necessary to develop a taxonomy
of attacks first in order to prove the research question right or wrong. So the added value
of this research does not lie directly on the research question itself, but on the underlying
steps. Proving it will only serve to validate the taxonomy.
4 Purpose and Goals
Now that an overview on the problem and its underlying challenges have been
presented, it is now appropriate to address questions such as “what do we already know
on the subject?” and “how does this research fit into the grand picture composed by
similar studies in the field?”. Literature clearly indicates the topic has barely been studied
thus far (Landsmann & Strömberg 2003) and security standards and in-built security
measures urge to be developed. Actually, the word “awareness”, or lack of such,
summarizes what probably is the prime factor contributing for the hacker’s community
lead. No taxonomy of attacks has ever been attempted and resources on the topic still lay
scattered across various underground sources. The stakes are high as organizations have
much to lose from those that without much effort and with some ingenious

introduction •
ABOUT THIS RESEARCH
craftsmanship can maliciously take over what is most treasured within an Information
Society: Information itself. This research primarily seeks to shed some light on the
obscurity that for far too long has been characteristic of the topic, by proposing a
taxonomy of attacks which will consolidate existing academic, professional and
underground materials. It is not this work’s goal to provide enough experimental
evidence to validate the taxonomy, nor will a set of preventive techniques be proposed,
although these are valid questions worthy to be studied in future works. Nonetheless,
whenever appropriate some experimentation and smart defensive techniques will be
mentioned.
4 Scope
The scope of SQL Injection and its implications extend far beyond databases, Web
applications and security, and even those are vast areas of research of their own.
Therefore it is necessary to narrow down the scope of this research in addition to the
scope already set by the research topic and research question. The following bulleted list
attempts to summarize the scope of this work:
• Portray the status quo as an introductory path to the topic:
Ø Systematize the most commonly used set of practices and systems
architectures used for implementing e-Business platforms;
Ø Establish a clear dependency of e-Business systems on relational database
management systems;
• Expose SQL Injection:
Ø By investigating different variations;
Ø By proposing a taxonomy of attacks:
§ Explaining the concept;

introduction •
ABOUT THIS RESEARCH
§ Modus Operandis;
§ Effectiveness of the technique;
§ Applicability scope;
• Perform experimentation and ultimately answer to the research question;
• Based on the gained experience, propose simple first line defensive techniques.
4 Motivation
Part of the motivation for pursuing this research comes from the fact the researcher
being a solution architect for the Hewlett-Packard Corporation acting in the Enterprise
Application Services practice of the Consulting & Integration division. While interfacing
with or auditing corporate systems, all too often he faces many situations where an SQL
Injection attack could easily devastate the core business systems and cripple the
company’s ability to do business. The lack of awareness is almost unbelievable;
developers are rarely coding defensively, and systems engineers have the false feeling their
extremely expensive set of firewalls and intrusion detection systems will ensure IT security.
The stakes are indeed high and organizations that have suffered such attacks and have
actually detected them, rarely speak up as it would further compromise their ability to
guarantee integrity, availability and confidentiality to its customers. Therefore, the
motivation and prime goal of this work is to expose and systematize the problem, and
then prove the proneness of the major and most popular e-Business systems to these
attacks, thus empowering other researchers and IT experts to pursue further
developments in security.

introduction •
ABOUT THIS RESEARCH
4 Document Outline
This thesis is divided into seven chapters plus two additional sections, namely References
and Glossary which can be found at the end of the document. The organization of
chapters and their purpose is as follows:
Chapter 1 INTRODUCTION
Introduces the research topic by providing an overview of the facts
that lead to the formulation of the research question.
Chapter 2 LITERATURE REVIEW
Describes the process of providing a detailed and justified analysis
of and commentary on the merits and faults of the key literature.
Chapter 3 METHODOLOGY
Presents an overview of the research methods ecosystem and
formulates the research methods for addressing this work’s goals.
Chapter 4 ATTACK TAXONOMY
Performs a survey of the existing SQL Injection techniques and then
proposes the very first taxonomy of SQL Injection attacks.
Chapter 5 EXPERIMENTING
Performs experimentation on a real live system on the Internet as
means of building internal validity.

introduction •
ABOUT THIS RESEARCH
Chapter 6 DEFENSIVE TACTICS
Presents a first line of defensive tactics against SQL Injection attacks.
Chapter 7 CONCLUSIONS
Presents a final argument and what did this work accomplish in
terms of bridging the gap between different bodies of Knowledge.
REFERENCES
Formal list of all bibliographic sources acknowledged and
referenced throughout this thesis.
GLOSSARY
Consistent set of acronyms, jargon and definitions which are used
throughout this thesis.

Hacking with SQL Injection Exposed
Chapter 2
LITERATURE REVIEW
Critical literature review will form the foundation on
which the research is built. It describes the process of
providing a detailed and justified analysis of and
commentary on the merits and faults of the key literature
on the research topic. Despite it generally is an early
activity, the process can be likened to an upward spiral
mounting throughout the project’s lifespan.
This chapter outlines the findings of an extensive literature review performed on
the research topic and attempts answering to questions such as “what do we
already know on the subject?” and “how does this research fit into the grand
picture composed by similar studies in the field?”. The chapter ends with a
critical analysis of the findings inline with the researcher’s critical judgment

literature review •
RESEARCH STRATEGY
RESEARCH STRATEGY
According to Cormack (1991), a literature review is «… the process of systematically
identifying published materials which meet predetermined criteria». Regardless if the
review itself claims to be systematic, according to Hek et al. (2000) the searching process
should always be so. Saunders, Lewis, and Thornhill (2003) add that «critical literature
review will form the foundation on which the research is built. It describes the process of
providing a detailed and justified analysis of and commentary on the merits and faults of
the key literature on the research topic». Therefore a literature review contains two very
important characteristics: it should be systematic, so that other researchers following the
same footsteps should be able to replicate the findings, and it should be critic, which
denotes that the researcher’s critical judgment will be used (Saunders, Lewis, & Thornhill
2003) to mitigate findings in producing the review conclusions. This last stage is where
the researcher blends with the systematic part of the literature research process by
adding its own unique touch to the outcome. Since Science requires results to be
possible to be replicated by other researchers – although there is still some discussion
around the participatory role of the researcher on inductive research – it is imperative that
a clear literature research strategy is set as a blueprint of what is yielded by the whole
literature review process.
Saunders, Lewis, and Thornhill (2003) state that despite literature search is an early
activity for most researchers, it is usually necessary to revisit this activity during the
project’s life. This recursiveness can be likened to an upward spiral mounting throughout
the project’s lifespan culminating in the final draft of a written literature review. The
following diagram attempts to depict this spiralling process as stated by Saunders:

RESEARCH STRATEGY
Figure 11 - The Literature Review Process
> adapted from (Saunders, Lewis, & Thornhill 2003) <
RReesseeaarrcchh QQuueessttiioonn
aanndd OObbjjeeccttiivveess
DDeeffiinnee
ppaarraammeetteerrss
GGeenneerraattee aanndd
rreeffiinnee kkeeyywwoorrddss
WWrriitttteenn ccrriittiiccaall rreevviieeww
ooff tthhee lliitteerraattuurree
RReeccoorrdd
EEvvaalluuaattee
OObbttaaiinn
LLiitteerraattuurree
CCoonndduucctt
sseeaarrcchh
UUppddaattee aanndd
rreevviissee ddrraafftt
RReeddeeffiinnee
RReeccoorrdd
EEvvaalluuaattee
OObbttaaiinn
lliitteerraattuurree
CCoonndduucctt
sseeaarrcchh
SSttaarrtt DDrraaffttiinngg
RReevviieeww
RReeddeeffiinnee
CCoonndduucctt
sseeaarrcchh
OObbttaaiinn
lliitteerraattuurree
EEvvaalluuaattee
RReeccoorrdd

RESEARCH STRATEGY
For the sake of simplicity, instead of documenting each and every interaction the author
underwent while searching literature, only the research strategy and its yieldings will be
presented. For that matter, Bell’s check list will be used. Bell (1999) proposes a concise
checklist which provides an action plan for collecting information about the research
topic. This checklist is herein briefly described:
• Define the review topic;
• Identify the key concepts and associated terminology;
• Define parameters:
Ø Language – only materials in English?
Ø Geography – only materials published in the UK?
Ø Time Period – only the last five years?
Ø Type of Materials – Books, journal articles, newspaper articles, Internet
pages, etc.
Ø Sector – NHS, private sector;
• List possible search terms;
• Identify appropriate sources of information to be searched;
• Review and refine search as necessary;
• Document review methods and results.
Not surprisingly, the definition of the research topic and its subsequent well-formed
answerable research question should also be supported by literature. Formulating a
well-defined research question, meaning it must be precise rather than broad and
answerable rather than ill defined, is crucial since it will serve as both starting and end
point of the whole literature review process as per the model depicted in Figure 11 - The

RESEARCH STRATEGY
Literature Review Process on page 57. This view is also shared by Huth (1982). He states
that a well-conceived review always answers the question specified at its beginning.
Furthermore, the research question or the research objectives might conceal several
subtopics within themselves and separate review cycles on those subtopics may be
necessary. For this research, a quick review of the research objectives described on the
Purpose and Goals and Scope sections on pages 50 and 51 will yield several subtopics
that need to be addressed, namely “SQL Injection”, the main topic, attached to it comes
“Relational Databases”, “SQL”, “Logical Attacks” and “Code-Injection”, then “Web” and
“e-Business” and finally “Taxonomy Formulation”.
One could legitimately ask from where did such terms came from? The answer is
literature review. Despite if other activities or methods were used, for example the
researcher’s own gained experience, documented scientific knowledge must be used as
rationale for each and every claim. This principle also applies when claiming the existence
of a scientific emptiness in one particular field as a basis for conducting research and
consequently formulating the research question. Proof for that claim is required, and
therefore a literature review process is compulsory. Of course the researcher’s own gained
experience still plays an important role. Systematic thinking and acting is not an easy task
and takes time to learn. Experience is ultimately an ally guiding the steps toward efficient
finding of the information resources required to answer the burning question on the
researcher’s mind. Although the activities engaged to formulate the research topic,
question and objectives were not herein documented, the process followed was the one
depicted on Figure 11 - The Literature Review Process on page 57, and its yieldings
laid-out on the introductory chapter. This initial review led to the identification of possible
key concepts and associated terminology surrounding the research topic, which were
later used on this literature review. The resulting list of terms is the one yielded by the

RESEARCH STRATEGY
above-mentioned breakdown of the research question and its objectives, in particular
“SQL Injection”, “Logical Attacks”, “Code-Injection” and “Taxonomy”.
In regards to search parameters, i.e. language, geography, time period, type of materials
and sector, the topic is itself transversal to all of these and no predefined scope reduction
other than logistics and human limitations were introduced. Literature clearly prefers to
centre the research topic on the Web (Anley 2002b;Boyd & Keromytis 2004;Cerrudo
2002;Huang et al. 2004;Kost 2003), thus making it global and multilingual, although the
linguistic knowledge of the researcher limits him to English, Portuguese and French
sources. The research topic also concerns corporations as they began to adhere to Web
applications by connecting their systems to the Web and database-driven Web
applications have become widely deployed on the Internet (Halfond & Orso 2005b). For
that reason, in regards to sectors, both academic and privately held information sources
were considered, though it has been observed a tremendous lack of academic literature
on the subject, whereas the number of rich and ingenious available resources scattered
across hacking sites and underground communities is absolutely remarkable. Not
surprisingly, the timeframe of the collected information sources spans from mid 90’s until
present days, which roughly coincides with the dawn of e-Commerce and the
subsequent raising of Web attacks (Álvarez & Petrovic 2003;Buehrer, Weide, & Sivilotti
2005).
The following information sources were the primary search engines used when hunting
out for literature using the search terms identified:
• Biblioteca do Conhecimento Online – http://www.b-on.pt;
• Wiley Interscience – http://www3.interscience.wiley.com;
• SpringerLink – http://www.springerlink.com;

RESEARCH STRATEGY
• IEEE Xplore – http://www.IEEE.org;
• ACM Digital Library – http://portal.acm.org;
• Web of Science – http://portal.isiknowledge.com;
• ProQuest – http://proquest.umi.com;
• Scitation – http://scitation.aip.org;
• Citibase Search – http://citebase.eprints.org;
• Google – http://www.google.com;
• Google Scholar – http://scholar.google.com (Beta);
• E-Donkey peer-to-peer network.
These primary search engines served as starting point for the literature review process and
were revisited each time a search and review cycle took place. At that stage, internal
evidence was the leading factor used for steering the actions to be undertaken in the
forthcoming review cycles as the researcher has opted to engage the formal critical
analysis phase at the very end of the review process.

Hacking With Sql Injection Exposed - A Research Thesis

Hacking With Sql Injection Exposed - A Research Thesis

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Hacking With Sql Injection Exposed - A Research Thesis

Ähnlich wie Hacking With Sql Injection Exposed - A Research Thesis (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Hacking With Sql Injection Exposed - A Research Thesis