Introducing SQL Injection 339
To get the tables:
http://www.somesite.com/default.php?id=-1 union select ~CA
1,2,group_concat(table_name),4,5,6 from information_schema.tables where ~CA
table_schema=database()—
With the tables presented, you will target the users table:
http://www.somesite.com/default.php?id=-1 union select ~CA
1,2,group_concat(column_name),4,5,6 from information_schema.columns where ~CA
table_schema=database()--
Altering Data with a SQL Injection Attack
Another way to alter data using SQL injection involves using the forms that appear on
many websites. Forms that collect login or other information can be vulnerable to attack
depending on their design and any flaws that are present. Any form that solicits data and is
somehow connected to a database of any type may be vulnerable to SQL injection.
To illustrate this point, let’s consider a form of a common and simple design. This
hypothetical form is one of the commonly encountered forms that any user would use to
recover their password. This form simply requires the user to enter an e-mail address and
then click OK. Once this is done, the application searches the database for the provided
e-mail address. It then sends an e-mail to that address.
However, let’s change things a bit to show how SQL injection works in this situation.
In this case the attacker—you—will attempt to get the application to execute custom SQL
code to either steal information or alter existing information in some way.
First, you must determine what the database and application are doing and how the
database is structured. In this case the application is more than likely using what is known
as a SQL SELECT statement to retrieve data, like so:
SELECT data
FROM table
WHERE emailinput = '$email_input';
Because of the way applications like this function, you would have to make an educated
guess as to how the code is constructed. In this situation, the code is close to the actual
code itself as it originally appeared. You would expect a query to use a variable to hold the
user’s identity since it would need to be able to handle a multitude of inputs.
Remember earlier when you forced an application to generate errors? In this case it is
pretty much the same thing; you must determine how the application reacts when invalid
or unexpected input is provided. Once you know how the application reacts to this type of
input, you can start to formulate malicious SQL strings.
To accomplish this in our example, you input an e-mail address into the form but with a
single quote appended to it, like so: