![SQL Injection Attacks and Defense](http://prodimage.images-bn.com/pimages/9781597499637_p0_v1_s192x300.jpg)
SQL Injection Attacks and Defense
by Justin ClarkeView All Available Formats & Editions
SQL Injection Attacks and Defense, First Edition: Winner of the Best Book Bejtlich Read Award
"SQL injection is probably the number one problem for any server-side application, and this book unequaled in its coverage." -Richard Bejtlich, Tao Security blog
SQL injection represents one of the most dangerous and well-known, yet
/i>/i>/b>/i>… See more details belowOverview
SQL Injection Attacks and Defense, First Edition: Winner of the Best Book Bejtlich Read Award
"SQL injection is probably the number one problem for any server-side application, and this book unequaled in its coverage." -Richard Bejtlich, Tao Security blog
SQL injection represents one of the most dangerous and well-known, yet misunderstood, security vulnerabilities on the Internet, largely because there is no central repository of information available for penetration testers, IT security consultants and practitioners, and web/software developers to turn to for help.
SQL Injection Attacks and Defense, Second Edition is the only book devoted exclusively to this long-established but recently growing threat. This is the definitive resource for understanding, finding, exploiting, and defending against this increasingly popular and particularly destructive type of Internet-based attack.
SQL Injection Attacks and Defense, Second Edition includes all the currently known information about these attacks and significant insight from its team of SQL injection experts, who tell you about:
- Understanding SQL Injection - Understand what it is and how it works
- Find, confirm and automate SQL injection discovery
- Tips and tricks for finding SQL injection within code
- Create exploits for using SQL injection
- Design apps to avoid the dangers these attacks
- SQL injection on different databases
- SQL injection on different technologies
- SQL injection testing techniques
- Case Studies
- Securing SQL Server, Second Edition is the only book to provide a complete understanding of SQL injection, from the basics of vulnerability to discovery, exploitation, prevention, and mitigation measures.
- Covers unique, publicly unavailable information, by technical experts in such areas as Oracle, Microsoft SQL Server, and MySQL-including new developments for Microsoft SQL Server 2012 (Denali).
- Written by an established expert, author, and speaker in the field, with contributions from a team of equally renowned creators of SQL injection tools, applications, and educational materials.
Editorial Reviews
Product Details
- ISBN-13:
- 9781597499637
- Publisher:
- Elsevier Science
- Publication date:
- 07/02/2012
- Edition description:
- New Edition
- Pages:
- 576
- Sales rank:
- 847,117
- Product dimensions:
- 7.40(w) x 9.20(h) x 1.50(d)
Read an Excerpt
SQL Injection Attacks and Defense
By Justin Clarke
Elsevier Science
Copyright © 2012 Elsevier, Inc.All rights reserved.
ISBN: 978-1-59749-973-6
Excerpt
<h2>CHAPTER 1</h2> <p>What Is SQL Injection?</p> <br> <p><b>Dave Hartley</p> <br> <p>SOLUTIONS IN THIS CHAPTER:</b></p> <p>• Understanding How Web Applications Work</p> <p>• Understanding SQL Injection</p> <p>• Understanding How It Happens</p> <br> <p><b>INTRODUCTION</b></p> <p>People say they know what SQL injection is, but all they have heard about or experienced are trivial examples. SQL injection is one of the most devastating vulnerabilities that impact a business, as it can lead to exposure of all of the sensitive information stored in an application's database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details.</p> <p>So, what exactly is SQL injection? It is the vulnerability that results when you give an attacker the ability to influence the Structured Query Language (SQL) queries that an application passes to a back-end database. By being able to influence what is passed to the database, the attacker can leverage the syntax and capabilities of SQL itself, as well as the power and flexibility of supporting database functionality and operating system functionality available to the database. SQL injection is not a vulnerability that exclusively affects Web applications; any code that accepts input from an untrusted source and then uses that input to form dynamic SQL statements could be vulnerable (e.g. "fat client" applications in a client/server architecture). In the past, SQL injection was more typically leveraged against server side databases, however with the current HTML5 specification, an attacker could equally execute JavaScript or other codes in order to interact with a client side database to steal data. Similarly with mobile applications (such as on the Android platform), malicious applications and/or client-side script can be leveraged in similar ways (see labs. mwrinfosecurity.com/notices/webcontentresolver/ for more info).</p> <p>SQL injection has probably existed since SQL databases were first connected to Web applications. However, Rain Forest Puppy is widely credited with its discovery—or at least for bringing it to the public's attention. On Christmas Day 1998, Rain Forest Puppy wrote an article titled "NT Web Technology Vulnerabilities" for Phrack (<b>www.phrack.com/issues.html?issue=54&id=8#article</b>), an e-zine written by and for hackers. Rain Forest Puppy also released an advisory on SQL injection ("How I hacked PacketStorm," located at <b>www.wiretrip.net/rfp/txt/rfp2k01.txt</b>) in early 2000 that detailed how SQL injection was used to compromise a popular Web site. Since then, many researchers have developed and refined techniques for exploiting SQL injection. However, to this day many developers and security professionals still do not understand it well.</p> <p>In this chapter, we will look at the causes of SQL injection. We will start with an overview of how Web applications are commonly structured to provide some context for understanding how SQL injection occurs. We will then look at what causes SQL injection in an application at the code level, and what development practices and behaviors lead us to this.</p> <br> <p><b>UNDERSTANDING HOW WEB APPLICATIONS WORK</b></p> <p>Most of us use Web applications on a daily basis, either as part of our vocation or in order to access our e-mail, book a holiday, purchase a product from an online store, view a news item of interest, and so forth. Web applications come in all shapes and sizes.</p> <p>One thing that Web applications have in common, regardless of the language in which they were written, is that they are interactive and, more often than not, are database-driven. Database-driven Web applications are very common in today's Web-enabled society. They normally consist of a back-end database with Web pages that contain server-side script written in a programming language that is capable of extracting specific information from a database depending on various dynamic interactions with the user. One of the most common applications for a database-driven Web application is an ecommerce application, where a variety of information is stored in a database, such as product information, stock levels, prices, postage and packing costs, and so on. You are probably most familiar with this type of application when purchasing goods and products online from your e-retailer of choice. A database-driven Web application commonly has three tiers: a presentation tier (a Web browser or rendering engine), a logic tier (a programming language, such as C#, ASP, .NET, PHP, JSP, etc.), and a storage tier (a database such as Microsoft SQL Server, MySQL, Oracle, etc.). The Web browser (the presentation tier, suchh as Internet Explorer, Safari, Firefox, etc.) sends requests to the middle tier (the logic tier), which services the requests by making queries and updates against the database (the storage tier).</p> <p>Take, for example, an online retail store that presentttts a search form that allows you to sift and sort through products that are of particular interest, and provides an option to further refine the products that are displayed to suit financial budget constraints. To view all products within the store that cost less than $100, you could use the following URL:</p> <p>• <b>http://www.victim.com/products.php?val=100</b></p> <br> <p>The following PHP script illustrates how the user input <i>(val)</i> is passed to a dynamically created SQL statement. The following section of the PHP code is executed when the URL is requested:</p> <p>// connect to the database<br> $conn = mysql_connect("localhost","username","password");<br> // dynamically build the sql statement with the input<br> $query = "SELECT * FROM Products WHERE Price < '$_GET["val"]'".<br> "ORDER BY ProductDescription";<br> // execute the query against the database<br> $result = mysql_query($query);<br> // iterate through the record set<br> while($row = mysql_fetch_array($result, MYSQL_ASSOC))<br> {<br> // display the results to the browser<br> echo "Description : {$row['ProductDescription']} <br>".<br> "Product ID : {$row['ProductID']} <br>".<br> "Price : {$row['Price']} <br><br>";<br> }<br></p> <br> <p>The following code sample more clearly illustrates the SQL statement that the PHP script builds and executes. The statement will return all of the products in the database that cost less than $100. These products will then be displayed and presented to your Web browser so that you can continue shopping within your budget constraints. In principle, all interactive database-driven Web applications operate in the same way, or at least in a similar fashion:</p> <p>SELECT *<br> FROM Products<br> WHERE Price <'100.00'<br> ORDER BY ProductDescription;<br></p> <br> <p><b>A Simple Application Architecture</b></p> <p>As noted earlier, a database-driven Web application commonly has three tiers: presentation, logic, and storage. To help you better understand how Web application technologies interact to present you with a feature-rich Web experience, <b>Figure 1.1</b> illustrates the simple three-tier example that I outlined previously.</p> <p>The presentation tier is the topmost level of the application. It displays information related to such services such as browsing merchandise, purchasing, and shopping cart contents, and it communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network. The logic tier is pulled out from the presentation tier, and as its own layer, it controls an application's functionality by performing detailed processing. The data tier consists of database servers. Here, information is stored and retrieved. This tier keeps data independent from application servers or business logic. Giving data its own tier also improves scalability and performance. In <b>Figure 1.1</b>, the Web browser (presentation) sends requests to the middle tier (logic), which services them by making queries and updates against the database (storage). A fundamental rule in a three-tier architecture is that the presentation tier never communicates directly with the data tier; in a three-tier model, all communication must pass through the middleware tier. Conceptually, the three-tier architecture is linear.</p> <p>In <b>Figure 1.1</b>, the user fires up his Web browser and connects to <b>http://www. victim.com</b>. The Web server that resides in the logic tier loads the script from the file system and passes it through its scripting engine, where it is parsed and executed. The script opens a connection to the storage tier using a database connector and executes an SQL statement against the database. The database returns the data to the database connector, which is passed to the scripting engine within the logic tier. The logic tier then implements any application or business logic rules before returning a Web page in HTML format to the user's Web browser within the presentation tier. The user's Web browser renders the HTML and presents the user with a graphical representation of the code. All of this happens in a matter of seconds and is transparent to the user.</p> <br> <p><b>A More Complex Architecture</b></p> <p>Three-tier solutions are not scalable, so in recent years the three-tier model was reevaluated and a new concept built on scalability and maintainability was created: the <i>n</i>-tier application development paradigm. Within this a four-tier solution was devised that involves the use of a piece of middleware, typically called an <i>application server</i>, between the Web server and the database. An application server in an n-tier architecture is a server that hosts an application programming interface (API) to expose business logic and business processes for use by applications. Additional Web servers can be introduced as requirements necessitate. In addition, the application server can talk to several sources of data, including databases, mainframes, or other legacy systems.</p> <p><b>Figure 1.2</b> depicts a simple, four-tier architecture.</p> <p>In <b>Figure 1.2</b>, the Web browser (presentation) sends requests to the middle tier (logic), which in turn calls the exposed APIs of the application server residing within the application tier, which services them by making queries and updates against the database (storage).</p> <p>In <b>Figure 1.2</b>, the user fires up his Web browser and connects to <b>http://www. victim.com</b>. The Web server that resides in the logic tier loads the script from the file system and passes it through its scripting engine where it is parsed and executed. The script calls an exposed API from the application server that resides in the application tier. The application server opens a connection to the storage tier using a database connector and executes an SQL statement against the database. The database returns the data to the database connector and the application server then implements any application or business logic rules before returning the data to the Web server. The Web server then implements any final logic before presenting the data in HTML format to the user's Web browser within the presentation tier. The user's Web browser renders the HTML and presents the user with a graphical representation of the code. All of this happens in a matter of seconds and is transparent to the user.</p> <p>The basic concept of a tiered architecture involves breaking an application into logical chunks, or tiers, each of which is assigned general or specific roles. Tiers can be located on different machines or on the same machine where they virtually or conceptually separate from one another. The more tiers you use, the more specific each tier's role is. Separating the responsibilities of an application into multiple tiers makes it easier to scale the application, allows for better separation of development tasks among developers, and makes an application more readable and its components more reusable. The approach can also make applications more robust by eliminating a single point of failure. For example, a decision to change database vendors should require nothing more than some changes to the applicable portions of the application tier; the presentation and logic tiers remain unchanged. Three-tier and four-tier architectures are the most commonly deployed architectures on the Internet today; however, the <i>n</i>-tier model is extremely flexible and, as previously discussed, the concept allows for many tiers and layers to be logically separated and deployed in a myriad of ways.(Continues...)
Excerpted from SQL Injection Attacks and Defense by Justin Clarke. Copyright © 2012 by Elsevier, Inc.. Excerpted by permission of Elsevier Science.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Customer Reviews
Average Review: