- SQL Injection attacks prey upon the fact
that many modern dynamic web applications rely upon
underlying databases to generate dynamic content.
For example, a web application that relies upon
a simple Database-Driven Authentication mechanism
might store unencrypted user passwords in a database,
and then, when a user attempts to log in,
the application retrieves the correct password
from the database, and compares it to the user's input.
If the passwords match,
the user is successfully logged in to the system.
This is not a good way to implement password authentication,
but it's the reality of how many websites work.
In this type of scenario, the web server requests the
password from the database using a Query written in
the Structured Query Language, or SQL.
SQL is simply the language used by relational databases
that allows users and applications
to create, update, delete, and retrieve data.
You won't need to know how to write SQL for
the security plus exam, but it is helpful to look at
some examples to understand how SQL injection attacks work.
When the web application I mentioned earlier
wants to retrieve a user's password
from the database, it writes a Query.
The first part of that Query, the SELECT statement,
tells the database that we're trying to retrieve information
and the names of the specific fields
that we would like to retrieve.
Our application is asking for the
username and password fields.
The next part of the Query, the FROM clause,
gives the name of the database table
containing the desired information.
And then, the final part of our Query, the WHERE clause,
tells the database the specific
records we are interested in retrieving.
In this case the web application plugs in the username
that the user entered when trying to log in.
So, when I log in to this web application using the username
mchapple, and the password, apple,
the web application generates a SQL Query to the database
that requests the correct password
for a user named mchapple.
If the password I entered matches
the password stored in the database, I'm good to go.
Here's what the database Query would look like,
It's our template from before, but the information
that I entered in the username field
of the web application, mchapple,
now appears in the database Query.
If I were a hacker, this might give me an idea.
What if I tried to alter this Query
by entering some strange information in the
web application's username field.
Specifically, let's say I put this in.
Instead of entering mchapple there,
I enter this very strange text.
My username, mchapple, followed by a single quote,
and then a semicolon, a SQL command,
and then another semicolon and two dashes.
Here's what gets sent to the database in that case.
Now it's important to know two things.
First, the semicolon separates commands in SQL,
and two dashes designate comments,
information that should be ignored.
So here's that Query that's sent to the database,
and let me just rearrange this a little bit
to make it more readable for you.
My little handiwork here actually
sends two separate SQL commands,
and a comment to the database.
The first command retrieves my password as desired,
but the second one actually changes
the password stored in the database for that account.
It doesn't even matter if I entered the correct
password for the first command,
because I've just successfully changed the password
to a value of my choice with a second command.
Back to the web application, I could simply return to
that login screen and now use the
password that I entered to access the application.
The trick to this attack is that
I had to enter a single quote to break myself out
of the quotation marks in the templated SQL statement.
If I was trying to defend against SQL injection attacks,
I can use two techniques,
Input Validation, and Parameterized Queries.
Input Validation occurs when the web application
inspects the input provided by a user
to make sure that it is in an appropriate format.
For example, the input should never
contain a single quotation mark.
This checking should always be
performed by the web application on the server,
where an attacker can't modify the code.
If the developer tries to use a technique known as
client side validation, where the user's
web browser validates the input,
An attacker can easily remove those checks
and bypass the Input Validation security.
The second SQL injection prevention technique is the use
of Parameterized SQL commands, such as store procedures.
Using this technique, SQL statements
are stored on the server, sometimes in a precompiled format.
Where the input provided by applications
is plugged in after the SQL is already processed.
This type of Query also prevents SQL injection attacks.