Injecting into SQL
Almost every web application employs a database to store the various kinds of information that it needs in order to operate. For example, a web application deployed by an online retailer might use a database to store the following information:
■ User accounts, credentials, and personal information
■ Descriptions and prices of goods for sale
■ Orders, account statements, and payment details
■ The privileges of each user within the application
The means of accessing information within the database is Structured Query Language, or SQL. SQL can be used to read, update, add, and delete information held within the database.
SQL is an interpreted language, and web applications commonly construct SQL statements that incorporate user-supplied data. If this is done in an unsafe way, then the application may be vulnerable to SQL injection. This flaw is one of the most notorious vulnerabilities to have afflicted web applications. In the most serious cases, SQL injection can enable an anonymous attacker to read and modify all data stored within the database, and even take full control of the server on which the database is running.
As awareness of web application security has evolved, SQL injection vulnerabilities have become gradually less widespread, and more difficult to detect and exploit. A few years ago, it was very common to encounter SQL injection vulnerabilities that could be detected simply by entering an apostrophe into a HTML form field, and reading the verbose error message that the application returned. Today, vulnerabilities are more likely to be tucked away in data fields that users cannot normally see or modify, and error messages are likely to be generic and uninformative. As this trend has developed, methods for finding and exploiting SQL injection flaws have evolved, using more subtle indicators of vulnerabilities, and more refined and powerful exploitation techniques. We will begin by examining the most basic cases and then go on to describe the latest techniques for blind detection and exploitation.
There is a very wide range of databases in use to support web applications. While the fundamentals of SQL injection are common to the vast majority of these, there are many differences. These range from minor variations in syntax through to significant divergences in behavior and functionality that can affect the types of attack that you can pursue. For reasons of space and sanity, we will restrict our actual examples to the three most common databases you are likely to encounter, namely Oracle, MS-SQL, and MySQL. Wherever applicable, we will draw attention to the differences between these three platforms. Equipped with the techniques we describe here, you should be able to identify and exploit SQL injection flaws against any other database, by performing some quick additional research.
Exploiting a Basic Vulnerability
Consider a web application deployed by a book retailer that enables users to search for products based on author, title, publisher, and so on. The entire book catalog is held within a database, and the application uses SQL queries to retrieve details of different books based on the search terms supplied by users. When a user searches for all books published by Wiley, the application performs the following query:
SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ This query causes the database to check every row within the books table, extract each of the records where the publisher column has the value Wiley , and return the set of all these records. This record set is then processed by the application and presented to the user within an HTML page.
In this query, the words to the left of the equals sign comprise SQL key- words and the names of tables and columns within the database. All of this portion of the query was constructed by the programmer at the time the application was created. The expression Wiley , of course, is supplied by the user, and its significance is as an item of data. String data in SQL queries must be encapsulated within single quotation marks, to separate it from the rest of the query.
Now, consider what happens when a user searches for all books published by O’Reilly. This causes the application to perform the following query:
SELECT author,title,year FROM books WHERE publisher = ‘O’Reilly’
In this case, the query interpreter reaches the string data in the same way as before. It parses this data, which is encapsulated within single quotation marks, and obtains the value O . It then encounters the expression Reilly’ , which is not valid SQL syntax and so generates an error:
Incorrect syntax near ‘Reilly’.
Server: Msg 105, Level 15, State 1, Line 1
Unclosed quotation mark before the character string ‘
When an application behaves in this way, it is wide open to SQL injection. An attacker can supply input containing a quotation mark to terminate the string that he controls, and can then write arbitrary SQL to modify the query that the developer intended the application to execute. In this situation, for example, the attacker can modify the query to return every single book in the retailer’s catalog, by entering the search term:
Wiley’ OR 1=1–
This causes the application to perform the following query:
SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ OR 1=1–‘
This modifies the WHERE clause of the developer’s query to add a second condition. The database will check every row within the books table and extract each record where the publisher column has the value Wiley or where 1 is equal to 1. Because 1 is always equal to 1, the database will return every record within the books table.
Bypassing a Login
In some situations, a simple SQL injection vulnerability may have an immediately critical impact, regardless of any further attacks that could be built upon it. Many applications that implement a forms-based login function use a database to store user credentials and perform a simple SQL query to validate each login attempt. A typical example of this query is:
SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’
This query causes the database to check every row within the users table and extract each record where the username column has the value marcus and the password column has the value secret . If a user’s details are returned to the application, then the login attempt is successful, and the application creates an authenticated session for that user.
As with the search function, an attacker can inject into either the username or the password field to modify the query performed by the application, and so subvert its logic. For example, if an attacker knows that the username of the application administrator is admin , he can log in as that user by supplying any password and the following username:
admin’–
This causes the application to perform the following query:
SELECT * FROM users WHERE username = ‘admin’–‘ AND password = ‘foo’
which because of the comment symbol is equivalent to
SELECT * FROM users WHERE username = ‘admin’
and so the password check has been bypassed altogether.
Suppose that the attacker does not know the username of the administrator. In most applications, the first account in the database is an administrative user, because this account is normally created manually and then used to generate all other accounts via the application. Further, if the query returns the details for more than one user, most applications will simply process the first user whose details are returned. An attacker can often exploit this behavior to log in as the first user in the database by supplying the username:
‘ OR 1=1–
This causes the application to perform the query
SELECT * FROM users WHERE username = ‘’ OR 1=1–‘ AND password = ‘foo’
which because of the comment symbol is equivalent to
SELECT * FROM users WHERE username = ‘’ OR 1=1
which will return the details of all application users.
NEXT is..Finding SQL Injection Bugs……………..,.,.,.,.,.,.,,.
