Only the foolish believe that this form
of attack is obsolete. The truth is that SQL Injection was rated as
one of the top ten attack methods used on applications in 2007 and
again as recent as 2010. Applications in production are subject to
as many as 71 SQLi attacks per hour, with high value applications
being attacked 800-1300 times per hour. So what's at risk? How does
SQLi work? And how do I defend my application against SQLi? Let's
find out.
Some of the most powerful applications
use a database to store their data. On the back-end data is accessed
via SQL statements that are either fixed or are customized based on
user input. The goal of attackers is to make the application run an
SQL query that was not intended by the application programmers, with
the result being attackers gaining access to information they should
not be authorized to have, or they can manipulate data or even
control an entire database.
The user interface to input the data should be considered the gateway by which the injection occurs. SQL statements are often structured similar to this:
SELECT thiscolumn FROM thistable WHERE data = '$value';
The user interface to input the data should be considered the gateway by which the injection occurs. SQL statements are often structured similar to this:
SELECT thiscolumn FROM thistable WHERE data = '$value';
If the database table we are accessing
is called 'member_information', and the column in the table we are
trying to capture data from is 'birth_date', and the column we are
verifying user input against is 'last_name', then since the “$value”
is the variable container representing input from the user if the
user submits the value “Smith” into the user interface the
application handler would execute the following SQL
statement:
SELECT birth_date FROM member_information WHERE data = 'Smith';
Although simplified, this is a very common approach to verifying data in a database. This particular statement would probably return the targeted members recorded birth date. Unfortunately, this approach can be subject to manipulation by using SQLi to return other-than expected results to the application user. Continuing with our last example, what if the user input the following instead of “Smith”:
SELECT birth_date FROM member_information WHERE data = 'Smith';
Although simplified, this is a very common approach to verifying data in a database. This particular statement would probably return the targeted members recorded birth date. Unfortunately, this approach can be subject to manipulation by using SQLi to return other-than expected results to the application user. Continuing with our last example, what if the user input the following instead of “Smith”:
anything' OR 'x'='x
Note the placement of the apostrophes.
Since $value parameter of the pre-defined SQL statement already
includes apostrophes to enclose the variable, the intentional
placement of further apostrophes gives opportunity to the SQL
injector to extend the query to include more parameters – which is
the core of SQLi. This extended statement now looks like this:
SELECT birth_date FROM
member_information WHERE data = 'anything' OR 'x'='x';
This is a perfectly valid SQL
statement, but instead of returning one value based on one record it
would now return the birth_date from every instance where the
targeted data was true (because x will always equal x). This means
that the return would be the birth_date for every record in the
table.
This is perhaps the most basic way to understand how SQL injection works. It's easy to see how this strategy can be easily harnessed and configured to extract sensitive information or even identify information regarding the schema of a particular database. On outset that may not look like too much of a reward for a successful cyber attack, but considering the data maintained by financial organizations and in military or government databases the gains could be far worth every bit of effort.
Is there a way to protect against SQLi? Yes there is, but that's an article for another day.
This is perhaps the most basic way to understand how SQL injection works. It's easy to see how this strategy can be easily harnessed and configured to extract sensitive information or even identify information regarding the schema of a particular database. On outset that may not look like too much of a reward for a successful cyber attack, but considering the data maintained by financial organizations and in military or government databases the gains could be far worth every bit of effort.
Is there a way to protect against SQLi? Yes there is, but that's an article for another day.
Thrilling as always.
ReplyDelete