In this lesson, we're going to discuss
SQL and XML injection attacks.
Now, an injection attack occurs
when an attacker sends malicious data to a system,
which is then processed as part of a command or query,
which can lead to unintended consequences.
Now, regardless of whether the attacker is trying
to conduct an SQL injection or an XML injection,
the concept and the goal of the attack is similar,
to send some kind of code into our systems
so that, that attacker can perform
some kind of malicious action.
So let's go ahead and cover an SQL injection first,
and we'll talk a little bit about the background of SQL
so you can understand how it works.
Now, when you're dealing with a database,
you have to have a way to talk to that database
in order to read, write, or search for data inside of it.
Now, this is done by using statements in a language known
as the Structured Query Language, or SQL.
Now, there are four main actions inside of SQL
that you can use to manipulate
the data held inside of a database.
These are select, insert, delete, and update.
Now, to select something means that we want to read
that data from the database.
To insert something means
that we want to write 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 that data
in the database with a newer version.
Now let's take a quick look at how SQL works
in the real world.
When you try to log into a website, you may encounter
a basic login form asking for your username and password.
Let's pretend I enter Jason as my username
and Pass123 as my password, and then I click login.
Next, the website is going to send my username and password
over to the database and make a query to determine
if my username and password match what is being stored
inside of the database.
To do this, it's going to use an SQL statement.
For example, I might have the statement
of Select * from Users where user_id = 'Jason'
and password = 'Pass123'.
Now, this information goes into the database,
and then will determine if there is a perfect match.
If there is a match, we're going to have access granted,
and everything is going to be wonderful.
That is a very basic and major oversimplification
of how SQL works, but at least it gives you a good idea.
Now, if you're a database engineer,
I know I really made that much simpler than it really is,
but this is the baseline knowledge
that everybody watching this video needs to have
before we can move forward
and talk about an SQL injection.
So please don't send me a bunch of hate mail
over my oversimplification.
I'm just trying to make it easier
for everyone to understand.
All right, now let's go ahead
and move into the code injection portion.
Now, a code injection is the insertion
of additional information or code
through a data input form from a client to an application.
Code injection is a generic form,
but what we're going to be focused on specifically right now is
an SQL injection,
which is a specific type of code injection.
This is how a lot of attackers are going to insert
malicious SQL statements into our applications
and cause havoc for us, so it's important to understand.
Now, an SQL injection attack is going to consist
of an injection of an SQL query through the input form
that a client is going to use to send data
over to a web application.
When conducting an SQL injection, the attacker is going to try
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 either inject their input
as a URL parameter by entering the data into a form field,
by modifying cookies, by changing post data,
or by using an HTTP header
to find an SQL injection vulnerability.
Now, while this sounds like a lot of work,
it's actually pretty easy to automate this process
as an attacker, because there's a lot of great tools
out there that focus on SQL injections and exploits.
So as a defender, it's going to be our job
to protect our databases from these SQL injections,
and to do that, we have to understand
how these SQL injections are actually going to work.
Now 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 that's used by the clients
to enter their username and password.
As an attacker, I'm going to put that in as my username
that I want to log in as, and in this case, that's Jason.
Then I'm going to insert the password, but as an attacker,
they don't know what Jason's password is.
Now, you all do, because I already told you it was Pass123,
but as the attacker, what I'm going to do is I'm going to add
an apostrophe and type 'OR 1 = 1;
Now, that looks pretty weird, right?
Well, it does, but the reason that I'm doing this is
because when I put that in and I click the login button,
that data from the form is going to be inserted back
into the SQL statement on the backend
and then query to the database.
Now, what we have just done is we are going to use
that command Select * from Users
where user_id equals the user we entered, which was 'Jason'
and password equals, and then what we entered
for our password, which in this case, was 'OR1 = 1;
Now, notice when I sent that to the system,
what I'm seeing there is that access is granted.
Now, why is that?
It's not because I got the right password.
The reason is because I just performed an SQL injection.
What ends up happening when you have something
like this apostrophe is that it serves
as an escape character.
So what I really was injecting into the SQL statement was
for the system to evaluate whether what I entered
as the password was a match for the password for Jason,
or does one equal one?
Now let me ask you a quick question here.
Does one equal one?
Well yes, one equals one.
Every single day, one is going to equal one.
It's a true statement, so anytime we run this command,
we're going to get a true statement,
because we're checking if password
or one equals one is true, and in this case,
one equals one is always going to be true,
so based on simple Boolean logic,
even if the password was wrong because I put it blank
in this case, I'm still going to be able to get into the system
because I have one equals one as a true condition,
and anytime you're using Boolean logic, if one
of the conditions is true, the entire statement is true
when you're using an OR statement.
This is why I'm going to get an access granted.
I'm going to be able to log into the system as Jason,
even though I didn't have his password.
This is why SQL injections work
when people are trying to break into a database,
because they are forcing a true condition to occur.
Now, this is why preventing an SQL injection
from being able to occur is really important,
and the best way to prevent an SQL injection is
to use something known as input validation,
and to sanitize any data you receive from your users.
Now, for the exam, anytime you see something
with an apostrophe and something that equals something,
I want you to automatically think
this is probably an SQL injection attempt.
Almost every single time, that's going to be the right answer.
Now, be aware anytime you see in the log,
something that is something equals something,
it doesn't always have to be one equals one.
It can be seven equals seven, or 15 equals 15, or whatever.
As long as that statement will always evaluate to true,
it is a form of SQL injection.
I guarantee on the exam you're going to get at least one
or two questions about SQL injections,
and they'll either be focused on you being able to identify
that it was an SQL injection by seeing that one equals one
or something similar like that,
or they're going to ask you how to prevent an SQL injection,
and if you're asked to prevent an SQL injection,
what is the right answer?
It is input validation, so remember that.
If you can validate or sanitize the input,
you're going to be able to prevent an SQL injection
from occurring because you can filter out those apostrophes
or something equals something,
and not send that to the database.
Now, another great way to prevent an SQL injection is
to simply use a web application firewall,
and placing it between the client and the web server,
because the web application firewall will be able to perform
that input sanitization and input validation for you
even if you can't rewrite the application's code itself.
Now, on the exam, if you have a question
that's asking about attacks
against a database, almost always,
the answer is going to be an SQL injection, why?
Because databases use SQL as the way to read
and write information from a database.
So again, keep these tricks in mind for exam day,
and I'm sure they're going to come in handy for you.
All right, now that we've covered SQL injections,
let's move into our coverage of XML injections next.
Now, XML stands for the Extensible Markup Language,
and it's used by web applications
for authentication, authorization,
or other types of data exchange.
XML data is submitted from the client to the server,
or from one server to another.
To protect XML data in transit, it should always be sent
inside of an encrypted tunnel
such as by using a TLS tunnel.
To protect your server when it receives XML data,
you should always conduct input validation
and input sanitization of the data before you process it.
This will protect the server from any kind
of XML exploitation or injection attack
that the attacker is trying to perform.
If you submit XML data without encryption
or without input validation, it's going to be vulnerable
to snooping, spoofing, request forgery,
and injection of arbitrary code, so you want to make sure
you're doing encryption and input validation
anytime you're sending data in XML format.
Now, when you look at XML data,
it's going to appear to be in a human readable format
as a series of tagged fields.
Now, here's a short XML file
that I created containing a practice exam question.
The first line defines the text file as an XML file,
and defines what version of XML
and the type of encoding I want to use.
The second line is going to define
the type of data I'm using in this XML file.
In this case, I'm defining the information contained
as a question for a web application quiz program
that I'm writing.
Next, you're going to see there are four more fields
inside this question type.
The first field is the ID field,
and you'll see here it contains a unique identifier
for this sample question with a label of SECURITY-002-0001.
Next, I have a title field,
and I titled this question as is this an XML vulnerability?
Next, I have choice one and choice two as fields.
Now, the great thing about XML is that it can be configured
with whatever fields you want,
based on your specific application that you're building.
In my case, I'm showing you how I would define my questions
for this quiz application.
Finally, you'll see we have the slash question
and the slash XML tags to close out this data,
just like closing out an HTML tag in a website's code.
Now, if you see something like this on test day,
you should be able to identify it as XML data.
In this example, there is nothing malicious,
it's just regular XML data that's being used
to contain information
and send it to or from a given application.
In this case, it's a quiz application that I'm building.
Now, there are some exploits that you're going to come across
with XML, and so let's talk about a couple of those.
First, we have an XML bomb.
Now, an XML bomb is also known as a billion laughs attack.
Now, an XML bomb takes an XML file
and then uses encoding to encode entities
and expand them into exponential sizes,
which will consume memory on the host,
and potentially crash it.
The reason this is called a billion laughs attack is
that the XML entities referenced in this file are written
as lol one through lol nine.
Each of these references the line before it,
so starting at the bottom with lol nine,
you can see we have 10 lol eights,
and in lol eight, there are 10 lol sevens,
and this pattern continues all the way up,
and essentially it creates a billion lols
because of this factorial nature
of the entity references that's being used.
Now, this simple code can actually consume
up to three gigabytes of memory
due to the repetitive references
that are being made inside this XML file.
So if an attacker is able to get to your server
and have it process this XML file,
it can then start consuming
all of these resources on your web server,
and this is why we call it an XML bomb,
because it acts like a bomb or denial of service attack.
Now, the second type we have is what's known
as an XML external entity, or XXE attack.
This type of attack attempts to embed a request
for a local resource.
Now, this sounds a lot
like a local file inclusion, doesn't it?
And here's an example of an XML external entity attack.
Again notice we have the XML version
and the encoding in the first line.
Next, we have a document type listed as foo,
which is just code or speak
for some kind of a junk variable.
Then we have an element foo ANY,
and we have the entity xxe SYSTEM,
and then the file, "file:///etc/shadow,"
and then we end this out with some kind of data
inside of XML format.
In this case, we're calling that foo as well.
Now, most of this doesn't look too bad or malicious,
but that fourth line that contains
the /etc/shadow file is,
because this XML entity is trying to read the shadow file
of a Linux machine, which contains the password hashes
for that system's accounts.
Now, to prevent XML vulnerabilities from being exploited,
remember, you need to use proper input validation.
Input validation, input validation, input validation,
I keep mentioning it for our different web applications
and exploits because it really is that important.
Anytime you're getting input from a user,
whether it's a URL being inputted, a file being inputted,
a field being entered on a website,
or some kind of XML data being sent over,
we can prevent a lot of security issues
if we just use input validation.
Now, for the exam, if you see something
with XML written in it and it is clearly XML, guess what?
That's most likely going to be an XML vulnerability
that's being exploited.
They might call this an XML vulnerability,
an XML exploitation, or an XML injection.
Whatever term they use, it really doesn't matter.
It really is just XML being exploited
when you see XML format data in a question on the exam.
Now, the only real tricky part with an XML code is
that it often can look like HTML code or JavaScript.
To tell the difference, remember that HTML
or JavaScript uses defined keywords
for each of those bracketed entries,
but with XML, you can make those say whatever you want,
depending on how you configure your XML file.
So on the exam, I want you to take a moment
anytime you see a piece of code, and look at it,
and then determine is it HTML,
is it JavaScript, or is it XML?
If you see something like a font or an image
or an href in the tag, that is going to be HTML.
If you see something like question or ID or type or element
or entity, that's going to be XML.
If you can make this kind of determination,
you're going to have no issues answering questions
that involve XML vulnerabilities,
exploitations, or injections on the exam.
So remember, an injection occurs when an attacker sends
malicious data to a system,
and it's then going to be processed as part
of a commander query that can lead
to unintended consequences.
An SQL injection is an attack technique
where malicious SQL code is inserted into input fields
to manipulate or exploit a database-driven application.
If you see something like apostrophe one equals one,
this is going to be an SQL injection.
XML injections, on the other hand, is an attack technique
where malicious XML code is going to be inserted
into input fields to manipulate
or exploit an XML driven application or service.
If you see any code that appears
to be written in XML format in a log snippet on the exam,
you can take a safe guess that this is an XML injection
that's being attempted by an attacker.