Finding SQL Injection Bugs

In the most obvious cases, a SQL injection flaw may be discovered and conclusively verified by supplying a single item of unexpected input to the application. In other cases, bugs may be extremely subtle and may be difficult to distinguish from other categories of vulnerability or from benign anomalies that do not present any security threat. Nevertheless, there are various steps that you can carry out in an ordered way to reliably verify the majority of SQL injection flaws.

String Data

When user-supplied string data is incorporated into an SQL query, it is encapsulated within single quotation marks. In order to exploit any SQL injection flaw, you will need to break out of these quotation marks.

Numeric Data

When user-supplied numeric data is incorporated into an SQL query, the application may still handle this as string data, by encapsulating it within single quotation marks. You should, therefore, always perform the steps described previously for string data. In most cases, however, numeric data is passed directly to the database in numeric form and so is not placed within single quotation marks. If none of the previous tests points towards the presence of a vulnerability, there are some other specific steps you can take in relation to numeric data.

Injecting into Different Statement Types

The SQL language contains a number of verbs that may appear at the beginning of statements. Because it is the most commonly used verb, the majority of SQL injection vulnerabilities arise within SELECT statements. Indeed, discussions about SQL injection often give the impression that the vulnerability only occurs in connection with SELECT statements, because the examples used are all of this type. However, SQL injection flaws can exist within any type of statement, and there are some important considerations that you need to be aware of in relation to each.

Of course, when you are interacting with a remote application, it is not normally possible to know in advance what type of statement a given item of user input will be processed by. However, you can usually make an educated guess based upon the type of application function you are dealing with. The most common types of SQL statements and their uses are described here.

SELECT Statements

SELECT statements are used to retrieve information from the database. They are frequently employed in functions where the application returns information in response to user actions, such as browsing a product catalog, viewing a user’s profile, or performing a search. They are also often used in login functions where user-supplied information is checked against data retrieved from a database.

As in the  examples, the entry point for SQL injection attacks is nor- mally the WHERE clause of the query, in which user-supplied items are passed to the database to control the scope of the query’s results. Because the WHERE clause is usually the final component of a SELECT statement, this enables the attacker to use the comment symbol to truncate the query to the end of his input without invalidating the syntax of the overall query. Occasionally, SQL injection vulnerabilities occur that affect other parts of the SELECT query, such as the ORDER BY clause or the names of tables and columns.

INSERT Statements

INSERT statements are used to create a new row of data within a table. They are commonly used when an application adds a new entry to an audit log, creates a new user account, or generates a new order. For example, an application may allow users to self-register, specifying their own username and password, and may then insert the details into the users table with the following statement:

INSERT INTO users (username, password, ID, privs) VALUES (‘daf’,‘secret’, 2248, 1)

If the username or password field is vulnerable to SQL injection, then an attacker can insert arbitrary data into the table, including his own values for ID and privs . However, to do so he must ensure that the remainder of the VALUES clause is completed gracefully. In particular, it must contain the correct number of data items of the correct types. For example, injecting into the username field, the attacker can supply the following:

foo’, ‘bar’, 9999, 0)–

which will create an account with ID of 9999 and privs of 0. Assuming that the privs field is used to determine account privileges, this may enable the attacker to create an administrative user.

In some situations, when working completely blind, injecting into an INSERT statement may enable an attacker to extract string data from the application. For example, the attacker could grab the version string of the database and insert this into a field within his own user profile, which can be displayed back to their browser in the normal way.

UPDATE Statements

UPDATE statements are used to modify one or more existing rows of data within a table. They are often used in functions where a user changes the value of data that already exists — for example, updating her contact information, changing her password, or changing the quantity on a line of an order.

A typical UPDATE statement works in a similar way to an INSERT statement, except that it usually contains a WHERE clause to tell the database which rows of the table to update. For example, when a user changes her password, the application might perform the following query:

UPDATE users SET password=’newsecret’ WHERE user = ‘marcus’ and password= ‘secret’

This query in effect verifies that the user’s existing password is correct and, if so, updates it with the new value. If the function is vulnerable to SQL injection, then an attacker can bypass the existing password check and update the password of the admin user by entering the following username:
admin’–

DELETE Statements

DELETE statements are used to delete one or more rows of data within a table, for example when users remove an item from their shopping basket or delete a delivery address from their personal details.

As with UPDATE statements, a WHERE clause is normally used to tell the data-base which rows of the table to update, and user-supplied data is most likely to be incorporated into this clause. Subverting the intended WHERE clause can have far-reaching effects, and the same caution described for UPDATE statements applies to this attack.

NEXT is The UNION Operator………………..,,,.,,,,,.,.,.,.

Posts to Review:

Injecting Code Injecting into SQL Attacking Access Controls Attacking Access Controls