You may be asking yourself, what does this have to do with actual pen testing?
And why do we need to understand the basics of actual SQL databasing?
I'm glad you asked.
You see, SQL databasing is one of those things that servers and,
excuse me, organizations maintain for those large amounts of data,
where hackers are going to be eyeballing it to see if they can get inside and get key information.
A lot of websites, web applications, and organizations use those SQL databases.
What's the plural for database? Is it S or I?
But they use those databases to be able to maintain a correlated and neat form of being
able to keep information, such as username and passwords, correlating to account numbers,
correlating to how much money you have into your account,
correlating to how many or what types of permissions do you have within the organization
that you're pen testing in at that time.
So there's all sorts of different types of information that is very valuable to a hacker
inside of a SQL database.
And us as pen testers need to be able to know just enough to be able to go through
and identify said key points of information and be able to do our best in defense.
So we're offense through defense.
Yes, offense through defense.
And we're going to try to exfiltrate some data from SQL databases.
Now in this skill, we're going to have a couple of exercises.
And I have a couple of different tricks up my sleeves to be able to help us identify
and do some of these basic level SQL attacks.
We're going to be using injection, SQL injection.
And there are really four types of SQL injection.
First, you got your in band or more along the lines of your classic SQL injection.
It works as the attacker uses the same channel to both send the malicious input and receive
the results.
And one common way that they do this is by using the database error messages to learn
the type of structure that the database is actually maintaining.
So when they start inputting actual queries inside of, let's say, a form where it's submitting
data to the actual database, they'll get the error back and see if they can make any
heads or tails out of what type of database they're working with.
Then we have inference.
And this is sometimes referred to as blind because the attacker can't see the database
output directly.
So they infer the results from the applications responses.
Very similar to how our classic works.
And for some testing purposes, not saying which ones, but you may see that this is actually
taking over the actual classic definition of SQL injection.
Because, again, we're using the responses of the actual SQL server itself to be able
to infer what type of data that we're dealing with here and what type of defenses that are
actually on the system itself.
For those that are familiar with SQL injection and understand the basics of it, you know,
you can always test with that one equals one.
And you may get a response back of true, a Boolean response, meaning true or false.
But if you get that back, then you kind of know that Boolean objectives or queries are
allowed on that SQL server.
If you don't get it back, you can make the inference that it's not and start moving on
to different tactics.
Next, we have our out of band.
And this works with the attacker forcing the database to make a separate network request.
Think like HTTP, HTTPS to another controlled server to exfiltrate data.
So we're getting inside of it and sending data to the actual target that we want elsewhere.
And we've done this kind of exfiltration before.
We would just be applying it to the actual SQL server in this particular instance.
Now, will we get into any type of detailed exfiltration like that in the skill?
No, we're just going to be covering the basics of SQL injection and getting an idea of what
the actual databases, database size look like in terms of how the data is stored and what
we should really be looking for when we're doing our pen test.
Lastly, you may see a reference to what's called second order.
Malicious input is stored safely at first inside of the actual database itself and later
used insecurely in a different context.
So the store payload executes later.
Basically, what we're doing here is inputting code inside of a database.
So at some point later on, the code can be executed to do something malicious.
Now, this may be a very similar recall back to our cross-site scripting skill.
And it follows the same idea.
Now, I know that's a lot of information, but we're going to be bringing this down into nuggets.
You see what I did there.
So let's go ahead and do it to it.