All right, so let's get into webapp penetration testing now and we're going to start with injections.
This doesn't just include single injection, it includes all kinds of injections.
So command injections, ximo parsers.
You can see that here in the security weaknesses sections.
But, you know, this is a major threat vectors.
We're going to look at a single injection.
It allows an attacker to interfere with queries that the application makes to the database.
So depending on how the query is written and the type of application that you're targeting, this might
allow an attacker to subvert the applications logic and completely bypass authentication.
Maybe they could access sensitive data, destroy tables and in some cases even grant them a reversal
on the victim host.
So, you know, this is pretty bad.
And some of the other things that could happen is if the results of the query are returned in the applications
response, then a threat actor can actually use lethal injection to fetch data from other tables using
a union that's a skill specific keyword.
And the only catches you just need to make sure you have the number of columns and data types.
So if you're going to union two tables together, they need to have the same columns, the number of
columns in the same data types.
But what I want to do now is I just want to kind of show you what this is.
So when you get into this, it tells you right in the hospital says, you know, you just supply data
is not validated, filtered or sanitized.
Right.
So there's no validation done.
Then this can result in single injection if the data isn't filtered, meaning, you know, certain characters
are left intact or not filtered or stripped or escaped.
And that can lead to issues.
And if the data isn't sanitized or it's not rewritten or encoded in some way so that the data is not
treated as code, then you can run into issues.
And this is actually a pretty good example here where they show you in this attack example.
So you can see the string.
And what's going to happen here is this webapp example.
Dotcom has a route for app and I can't view there's I'd value that.
You can see that this idea value is coming from the git request and the skip parameter value.
Right.
So there's no sanitisation, there's no validation.
It's just the raw attacker, controllable values being concatenated into SQL code.
Therefore, that value becomes code and it's executable.
If the attacker puts in a single tick, what they can do is, well, you can see where hit right here.
What's happening?
There's a single tick here.
Is another single take here, so if I put in a single tick for ID, then I will close the query here
and then I put or.
Single tick one, tick equals tick one, something close the query out.
Right, so this we're close now, it's closed out, so it's OK, the customer, it can be whatever value
it said equal to or it could be equal to this one is equal to one.
There should be another single take here.
Looks like they forgot that value.
And since one is equal to one, that's true.
This entire work clause basically disappears.
There's no we're condition.
And so it will then therefore select all columns from a table called accounts.
And the date has just been dumped.
Right.
So that's pretty much how that works at a high level.
Let's get into how we can actually run this attack so we get into a gift shop and let's see what we
can do here.
So one of the places to check for this is the login form, right?
That's the first place I would like to check.
And because, you know, we might be able to log in by simply commenting out the where clause, kind
of like we saw earlier, where there's some password check.
So let's go ahead and bring up the network tools.
So we can see what's happening behind the scenes.
All right, so we've got the network there for the email, I'm just going to put in a single tick,
another single tick, and I'm actually going to filter this through berp.
And it was going to take a peek at what Polisar to see what technologies are being run here.
So, Jake, query something called Osorno Watpac.
So, you know, that's just some light sort of Rickon using Mobilizer, which is a browser plug in.
If we go into berp, we can make sure the intercept is off the back here.
Let's click login.
And we get this verbose objects.
This is this is a finding right here, right?
Although it doesn't say anything, it does say something.
It doesn't tell me as an attacker, you know, what the specific error was, but it tells me that this
particular website has poor security hygiene, which means there are probably other problems with it.
And if you look at the post request.
You can see there was an internal server error, right?
You can see what we sent in the request of McCain back in the response if we click over to the response.
You'll see this verbose error.
I mean, this is not good, right?
We don't want to see this as a web developer, but it's giving us the full security.
Right.
I can copy that.
Let's see if we can make sense of it so we know the sequel injection here.
And what we could do is we can try to figure this out, so a select all columns from a table called
Users where the email address is, we put in a single tick and the password is some hash.
You know, it's looking for the password and then it's looking for this value deleted and it's hard
to know.
So if we could just comment out the password and delete that section, we might be able to log in.
Right, because then it's just going to say select staff from users where email equals whatever email
just happens to exist, maybe the administrator, then maybe we can just log in that way.
Let's take a look at this.
Hashes We can Google it.
You can actually see that hash is just the hash of a single tick.
Right.
That's all it is, is indicative of a single tick.
What we're going to do is going to look at the post request.
You can see the single tick here and you can see it selected.
This is the code in Hex.
And here's the verbose message.
So what we can do is send this to SQL map so we could say copy to file.
Well, just name it, you start school, just name it, injection that school.
There it is.
All right, so what we can do in the meantime is one scrap.
What we want to do is run 06 map grap request.
Yeah, tech, our request, wow, so we can say pseudo sequel, map tech are injection and then we'll
do Bache because.
Never ask for your input, use the default behavior, right?
And then we want the detections to be set to the maximum for the level and the risk closer to five and
three accordingly.
With that run.
And in the meantime, what they do.
So here it's funny, this is a good example of why running tools might not always solve your problem,
because you can see this is the post parameter.
Jason, email does not appear to be dynamic.
It might not be injectable.
Right.
We know it's injectable because we're getting this verbose error, saying this parameter right here
might not be injectable.
All right.
But we know it is.
So what are we going to do?
How are we going to play with this?
Let's send it to repeater control our shift, control our control space to resend.
Let's build out this query.
Let's see if we can just say like or one equals one Tuktoyaktuk.
And that looks like it did something.
I'm now seeing an admin username here.
I mean, something definitely happened.
We got this email.
And we even have a security token now, we just need to basically follow through with this, Sasha.
Let's try this again.
But the intercept on Wassa Log-in.
This is the request, we don't want that, we want the post forward.
Here's the Post.
Tech or one equals one tech tech tech to come about the password portion board.
That's the that's the request.
For what everything else through and now you can see we are here.
And you log in as admin, so we just got in through sequel injection, we just bypass authentication,
you can actually see why.
Because this query down here, we basically commented out and password in this hash, so it's not even
bothering to check for the password is just seeing it's just selecting all columns from users where
the email address is a single tick.
Or one is equal to one now, by the way, it didn't have to be one equal, the one I could have said
it to any true condition, it could have been born equal to Vye, but one equals one is usually what
most people use, you know, for the same reason that people use alert and cross-eyed scripting in the
way to defend against this is to use parameterization.
Right.
And you can see this is best prevented, SQL injection is best prevented through the use of parameterize
queries, and basically what you're doing is you're preparing the query ahead of time so that SQL knows
that what follows is not executable code.
It's just data.
And this is the appropriate way of protecting an application and actually shows you how to do this in
a bunch of different frameworks.
All right.
I encourage you guys to explore a sequel injection more wherever there's a place where you can insert
data.
That's a place to test, so, for example, this search box might be injectable, you know, searched
the network tab inside of your browser.
Look at the responses filtering through berp and see if you can get something that looks like it's an
injection and pay attention to verbose output.
You know, this Web application didn't just barf up all these details.
This should never have been exposed.
Right.
You're going to have a single injection vulnerability.
Don't need the attacker with verbose error messages like this.
Right.
So in the next lecture, we are going to get into broken authentication.
So I will see you in the next lecture.