All right, you guys, on the last lecture, we dug into insecure direct object reference, which is
a vulnerability class subtype of broken access control.
Now we're going to get into security misconfiguration, as you can see in our top 10.
You know, this is a fairly broad attack, right?
You could have unpatched floors or access to default accounts on these pages of protected files and
directories.
And this basically tells you, you know, what the security weaknesses are and the potential impact.
One of the attacks, obviously, is that it can give attackers unauthorized access to system data and
functionality.
Obviously, it's not something that you want.
And depending on what the attacker is able to access, it could result in a total business application
compromised.
OK, so obviously we want to make sure that the application isn't vulnerable and we want to prevent
this to make sure it's not vulnerable.
We need to scan it.
We need to test it.
We're going to do it manually.
And one of the things we're looking for here is we want to see if there's, you know, error handling
that reveals stack traces or other overly informative error messages.
You're basically telling me attacker what to do on this next move by barfing verbose error responses.
Right.
The application needs to gracefully handle non-standard or unexpected input.
And that's what we're going to test right now.
So here we are in a wasp juice shop and we are still signed in with our Bonnie at Security plus pro
dotcom account and one I'm going to do is take off.
Intercept, which it is off, and we're just going to, you know, just click around.
Just click around the application.
We're just trying to, you know, just make sure that everything responds the way we would expect if
I put, like, a bunch of ones in here, what gives me a limit?
There you see it says one 60.
Now, you could try to try this in too many and you can possibly get around this possibly and repeat
her, but again, we're just trying to see if there's something we can do here to break the application.
Let's go back to Berp and look at some of these requests so I can sort by the number put the most recent
request at the top.
And you can see there's a bunch of requests here.
Let's see, this is rest user, who am I?
What if I just change this to like, I don't know, he uses that doesn't exist, control our control,
shift our control space, descend, and then we'll has changed us to like Bonnie.
Sent unexpected path.
Look at that unexpected path, rest user Vonne.
And look what it's doing, it's actually telling you.
I think this big.
I can't get into actually telling you.
Way too much information.
And the response.
It's given me the local path.
To the Web application and is barfing local directories up to shop.
That's my webroot.
Obviously, this is not something you want to attack or to have.
And it's also revealing the exact lines inside these JavaScript files that were invoked as a result
of this error message.
Now, you should never display information like this to an attacker.
Attacker should not see this or even to use it.
This first of all, you from a non security perspective, it just provides it a bad user experience
and it's unprofessional.
You need to gracefully handle error messages, too, from an attacker perspective.
It's eating them in their recon exercise.
Now, they know that this is the webroot.
So if I'm going to drop a Web show on this box or maybe, you know, I'm able to get a remote command
execution or I'm able to maybe explain to local file include that's where I'm going to look.
Right.
So, you know, obviously we don't want this.
It's even telling us the framework we're using, which is no jazz and the express framework.
You know, way too much information is included in this 500 internal server error attack.
I would just want a to scan the box, look at all the HTP status codes that are 500, and then look
at a body that would just give me what I need to watch my next move, my attack.
Obviously, I this is a serious vulnerability.
Make sure that your Web applications will handle, not standard input.
In the next lecture, we will get into cross site scripting.
I'll see you in the next lecture.
You we come by.