- Have you ever heard of an injection attack?
It's the number one critical security risk
for web applications according to the OWASP Top 10 rankings.
I'm Infosec Skills author John Wagnon,
and I'm gonna show you exactly why
injection attacks are one of the most common
and dangerous risks on the internet today.
When you access a website,
you're actually accessing several different components,
several different technologies.
There's a web server that has text,
and pictures, and forms and all those things,
and other elements for the site that you're accessing.
But in addition, there's almost always
this database that's connected to that,
that holds a lot of information related to that website.
For example, a database might hold the names and addresses
of users, or maybe even more sensitive information,
like medical data or credit card numbers.
You know, bank information, things like that.
Injection attacks happen when an attacker takes advantage
of poorly written code that allows this attacker
to gain access to the database containing those types
of data that are intended to be protected.
So you might've heard of a SQL injection attack.
A SQL injection attack is a common type
of these injection attacks.
So, remember that database we were just talking about?
Well a database uses a specific language to talk.
It's called the Structured Query Language, or SQL,
and that uses SQL to carry out these commands
that make the database run.
SQL commands are used to do all kinds of things,
like insert data, remove data, find data,
manipulate that database, right?
When a web application is written,
if the code used to write it
doesn't check things like manipulated SQL commands,
then it could inadvertently allow a SQL command to run
against the database and allow an attacker to gain access
to that database or to that web application,
and gain access to all the data stored in the database.
So here's an example.
Let's say you have a web application that has
a username and password combination
that allows a user access to that website.
Let's also say that the same web application
has that database on the backend that stores
usernames and passwords, and that sensitive information.
So when a user enters a username and password,
a SQL query is created,
and it's executed to search against that database
to verify that that user is who they say they are.
If the matching entries are found on the database,
then the user is authenticated to the website.
But if the application doesn't do proper user input checks,
then an attacker could come in.
And they could manipulate the username or the password field
so that the resulting input creates
this strange, yet valid SQL command.
If the attacker uses the proper SQL syntax,
then they could manipulate the database
to return these statements, these true statements,
back to the web application, and then
the web application would grant user access to that site.
So, in this example, the username could be manipulated
to be something like a single quote,
and then the word "or",
and then a one equals one.
But what that does, is it gets translated
into a SQL command that might look something like
select star from users where name equals
quote or one equals one.
So, while this username looks really strange
in the website login box,
it looks completely valid to the database on the backend,
that holds the username and password fields.
The database is looking for a username
that matches the input value that the user supplied.
If the values match, then the database returns
a true response to the web application,
and the application allows the user access
into the web application.
Well, in this specific case, the SQL command
has been manipulated to tell the database
to return a true statement, or a true response.
As long as the username is either quote,
or as long as the statement one equals one is true.
Well, of course there's no username that is a quote, right?
But the logical statement one equals one
is, of course, true.
So the database would return a true response
back to the web application.
And so now this user, or in fact, the attacker,
would be granted access into the web application.
And so, SQL is not the only type of injection attack.
You can also use this same approach for things like
lightweight directory access protocol, or LDAP servers.
The syntax is slightly different between LDAP and SQL,
but the idea is exactly the same.
You manipulate the user input so that
the backend system will be tricked into granting access
or spilling data that was intended to be protected.
So these injection attacks lead to
dozens of breaches every year where
millions of records are compromised.
How do you defend against injection attacks,
like the ones we've just talked about?
Well, you should check all of your user input,
using things like prepared statements or stored procedures.
So essentially you want to make sure
that the user input coming into
your web application is what you expect it to be.
You can also implement things like the
concept of least privilege, where you only allow users
the minimum amount of access and permission to do their job.
You can see that injection attacks are really dangerous,
but there are things you can do to stop them.
That's why it's important that
cybersecurity professionals should know how
these attacks work and how they can mitigate them.
Check out my Infosec Skills learning path
for the OWASP Top 10 to learn all about
injection attacks, and many more.