In this lesson,
we're going to discuss SQL injection attacks.
Now, before we dive into SQL injection attacks, though,
we need to talk a little bit about SQL in general
and provide some background.
Now, when you're dealing with databases,
you have to have a way to talk to the database
in order to read, write,
or search for data within that database.
This is done using statements
in the structured query language,
more commonly referred to as SQL.
Now, there are four main actions in SQL that are used
to manipulate data within a database.
These four actions are select, insert, delete, or update.
Now to select something means
that we want to read data from the database
to insert something means we want to write
that data into the database.
To delete something means we want to remove
that data from the database
and to update something means I want to overwrite data
that's already in the database with a newer version.
Now let's take a quick look at out SQL works
in the real world.
When you try to log into a website,
you may encounter a basic log in form
asking you for your username and password.
Let's pretend I enter Jason as my username
and pass123 as my password, and then click log in.
Next the website will send my username
and password over to the database
and make a query to determine if my username
and password match what's already stored in the database.
To do this, we're going to use an SQL statement.
For example, it might say select * from users
where user ID = Jason and password = pass123.
Now this information goes over to the database
and the database is going to compare it
to determine if we have a match.
If we do, we're going to get access granted
and everything is wonderful,
but if we don't, we're going to get access denied
and then we can't log into the server.
Now this is a very basic
and major oversimplification how SQL really works.
If you're a database engineer,
I know I made this much simpler than it really is,
but this is really the baseline knowledge
that everybody watching this video needs to have
before we can move forward and talk about SQL injections.
So please don't send me a bunch of hate mail
over my oversimplification here.
Alright, now let's move into a code injection.
Now, a code injection is
the insertion of additional information
or code through a data input form that a client takes
and then sends it to an application.
Code injection is really a generic form,
but what we really want to focus on here is an SQL injection
in this lesson
because that's how an attacker is going to insert
malicious SQL statements into our application
and cause a lot of havoc for us.
Now, an SQL injection attack consists of the injection
of an SQL query through the input form that a client uses
to send data to a web application.
When you're conducting an SQL injection,
the attacker is going to be trying to insert parameters
or code into the SQL statement that's going to be used
to query that database.
To do this, the attacker can inject their input
as a URL parameter by entering data into form fields,
modifying cookies, changing post data,
or even using HTTP headers
to find an SQL injection vulnerability.
While this sounds like a lot of work, it really is easy
to automate this process as an attacker
because there are many great tools out there
that focus on SQL injections and exploits.
So as a defender, it is our job
to protect our databases from SQL injections,
and to do that we have to understand
how SQL injections actually work.
So let's go back to our example of logging into a website
and see how the SQL injection could exploit our site.
First we have the login form used by our clients
to enter their username and password.
As an attacker I'm going to put in the user
that I want to log in
as in this case Jason,
and then I'm going to insert the password,
but I don't know the password of pass123
because I don't know Jason's password.
So I'm simply going to put in an apostrophe
or 1=1;
Now I know that looks a bit weird, right?
But what I'm doing here is actually going to be injecting
that code when I hit the login button
that takes the data from the form
and it starts it into the SQL statement on the backend.
So now we have the command that says select* from users
where user ID = Jason
and password =''
OR one = one;'
Notice when I sent that to the system,
I'm going to get that into the system
and it's going to say access granted.
Now why is that?
Well, the reason is
because I just performed an SQL injection.
What actually ended up happening here is
that we inserted something like an apostrophe that served
as an escape character.
So what I did was actually injected everything
after the apostrophe into the SQL statement
that the system was going to evaluate.
And so instead of saying entering the password pass123,
I'm saying, tell me, does the password
for Jason match the password for Jason
or does one equal one?
Now let me ask you a quick question. Does one equal one?
Yes, one = one, right?
Every single day it's going to be a true statement.
So anytime we run this command, we're doing Boolean logic
to find out is it a true or false statement?
And the true statement is always going to be returned
as true when checking this password
because even if we don't have the right password for Jason,
one always = one.
And this was an OR statement using Boolean logic.
So even if the password was wrong, we still have it.
And in this case, we entered a blank password
or one = one,
and therefore we're able to see that our password,
even though it doesn't match the database,
still gets a true statement
because the or condition has one = one,
which is always true.
This way the SQL statement overall returns it true
and we get access into the system.
This is why preventing SQL injections is so important
because anytime you can create a true statement,
you're going to be able to log right into the database.
So what is the best way to prevent an SQL injection?
Well, the single best way to prevent an SQL injection is
to use input validation
and sanitize any input received from your users.
Now for the exam, anytime you see something
with an apostrophe and a something = something,
I want you to instantly think that the answer has to do
with an SQL injection attempt.
Every single time.
Be aware the log entry they show you doesn't have
to be one = one, though it can be anything
that has a true statement.
Seven = seven, 15 = 15, A = A whatever.
It doesn't matter as long
as the statement will always return true,
this is a form of SQL injection.
I guarantee you on the exam you're going to get at least
a few questions on identifying SQL injections.
This is a common topic they love to ask about
because it's really important.
So if you're asked about an SQL injection
and how to prevent it, what is the right answer?
Input validation.
If you can validate or sanitize the input,
you can prevent an SQL injection from occurring
because you can simply filter out those apostrophes
or something = something statements
from the input the user gave you.
Another great way to prevent an SQL injection is
to place a web application firewall
between the client and the server.
Since the web application firewall can perform
input sanitization for you,
if you can't rewrite the application code yourself
because you don't own the application,
another clue to a question asking about SQL injections
is if the question involves a database,
because the most common attack against
a database is going to be an SQL injection.
Remember all these tricks when you get to exam day,
they're really going to come in handy, I promise.