-: SQL Injection.
What is SQL?
SQL, or Sequel, stands for the structured query language.
And it's the way that a web application communicates
to a database server to ask for information.
Because this is the language used to communicate
with the databases and the databases hold lots
of valuable information,
this has become a popular target for attacks.
This brings us to the concept of an SQL Injection,
which is an attack consisting of the insertion or injection
of an SQL query via input data form
that the client sends to the web application.
SQL injections are just a specific type
of code injection, though.
A generalized injection attack is the insertion
of additional information or code through data input
from a client to an application.
This code injection can occur using any type of code, though.
But the most common are SQL, HTML,
XML, and LDAP injections.
By far though, SQL injections are by far the most common.
And so we're going to talk about that in this lesson
as we go through.
Just as SQL injections are used to insert SQL statements
into a web application, these other types
of code injection can also be used as an attack method, too.
And so keep that in mind.
Now, before we start to discuss how an SQL injection works,
it's important to know how a normal SQL query
or request is performed.
Let's pretend that you wanted to log into this website.
First, you have to enter your username.
So, I'm going to enter jason as mine
and then you have to enter your password.
So, I'm going to enter my oh so super secure password
of pass123, for this example.
With both of those entered in, I go and click
on the Login button,
and the website will send my username and password
to the database to verify
if the username matches the password stored in the database.
This is done by sending a SQL or structured query that says
select any records from the user table in the database
where the user_id = 'jason',
and the password = 'pass123'.
So, if the query finds a record in the table
that has both the username of jason
and the password of pass123,
it's going to return the value of true to the web application.
And the web application can perform
whatever the next action it's supposed to do in.
In this case, it logs me into the website
and displays whatever the authenticated user homepage is.
Now, if the username and password combination weren't found
in that database table called users,
then it's going to return false,
and the web application would give me some kind
of a message saying please enter your password again.
This is how it's supposed to work.
But how does it work with an SQL injection?
Let's try logging into this website again.
But this time, I'm going to perform an SQL injection.
So, we go back to the Login page,
and I'm going to enter the username of jason once more.
Then instead of entering my password,
I'm going to enter the Escape character,
which is a backward single quote mark,
and the statement, `OR 1=1;.
Now, this isn't my password, obviously.
But instead, this is some code that I'm trying
to inject into the SQL statement
that the web application is going to send to the database
when I click Login.
So, let's click the Login button,
and you can now see the full SQL statement
that the web application has generated
and sent to the database.
Select any records from the user table in the database
where the user_id = 'jason'.
So far, this is the same
as our earlier legitimate login attempt.
And where the password = '` OR 1=1 ;'.
What is happening here?
Well, this is showing us
that the statement is now being sent to the database,
but when it reaches that Escape character,
that backward single quote,
it's going to treat every thing after it
as a command to process.
This changes the context of the initial query.
Instead of saying Jason's username
and his password are the same as the one in the database
and therefore you accept it, it's now asking,
is Jason's username the same one in the database,
and is his password either password or does 1=1?
Now, notice the difference here
because this is the key to an SQL injection.
The first login we did is only going to give us
a true statement
if I correctly enter the username and password
that match what was already stored in the database.
That's what should happen.
But in the second statement,
the one I modified using my SQL injection,
it's going to become true as long as I entered a username
that was in the database,
and either the correct password, or 1=1.
Now, I don't know where you come from,
but where I come from, 1=1 every single second
of every single day.
So this statement is always going to return a true value
to the web application.
And I'm instantly going to be logged in to that website.
So, without entering the proper username and password,
you now have been granted access.
This is not good for security, as you can guess.
So how are we going to prevent this from happening?
Well, SQL injection and code injections can be prevented
very easily if you do proper input validation
and use the concept of least privilege
when you're accessing a database from a web application.
By validating the input from the username and password boxes
that I entered, the web application could have detected
that Escape character and simply given me an error
instead of allowing that code to be sent
to the database as part of the SQL statement.
This is why input validation is so important
to the security of our applications,
and why a programmer should never ever trust any input
received from a user inside of their programs.
Always validate the data you receive from a user first.
This will help you prevent all kinds of code injections
like SQL injections, HTML injections, XML injections,
and LDAP code injections from being successful.
Now, for the exam, any time you see a question
that shows something like an `OR 1=1, or any other statement
that will always return a true value,
it's going to be an SQL injection.
I don't care if it says 7=7, 123=123, or whatever,
if you see something like this on the certification exam,
you know automatically,
they're talking about an SQL injection.
And you should perform input validation to prevent it.
Databases are critical to our web applications,
and SQL itself isn't a bad thing.
Used properly, it's how we can retrieve information
from our databases and store information into our databases.
Just remember to always secure your databases
and validate the statements being sent to them
from your web applications.
In the next lesson, I'm going to show you a full demonstration
of how an SQL injection can be used to get all sorts
of information out of the database,
including people's usernames and their passwords.
Understanding this demonstration is not required
for the Security+ exam, but it is quite interesting
to see how these attacks unfold in the real world.