Well let's talk about broken authentication which is second in the list for the top 10.
Now if you want to go to this page I will link and down in the references.
Or you could just go to Google and say Oh what's broken authentication.
And it should be the first one that pops up.
So when we talk about broken authentication there's a lot of different attacks here.
And if we look at the is the application vulnerable I kind of just want to talk through this and some
of these are going to be very familiar to you.
So when we talk about authentication and we're talking about how can we get access to this application.
Right.
And how can we authenticate to the device.
Now there is a bunch of different options here.
If we go down the list now it says does it permit attacks such as credential stuffing.
So can we just supply a valid list of usernames and passwords and gain access.
You've seen that in the past.
And when you're talking against a web application that's considered broken authentication doesn't allow
brute force attacks.
So there should be some sort of a rate limiting that's happening.
If we are giving a brute force attack to a Web site or for conducting a brute force attack and we are
able to submit hundreds upon hundreds upon hundreds of request then that's an issue.
Right.
And that is going to cause a situation where we are able to log in with an account given enough time.
Another thing is it says does it permit default weak or well-known passwords.
Well Admin Admin is such a real thing.
If you encounter a Web site and you find a log in Portal you should be looking for something like admin
admin or you should be looking for default credentials if it's something that is a well-known service
something like for example Apache Tomcat which you saw in earlier video where we log in with default
credentials in the next video we're going to talk about the next one which is using weak or ineffective
credential recovery or forgot password processes.
And this is where if you have the forgot password process you go there and maybe something like on the
screen is the question for the user or the question that they're going to ask.
And we see this a lot and it's just bad practice because that might be guess of all like What street
did you grow up on.
Well you know there's only so many streets that we can pick out there or if we do a little bit of research
on this person guess what we can probably figure out where they grew up what street they grew up on
and narrow it down.
So you know this is just repetition here on a lot of this stuff skipping down a bit.
Does the Web site have multi factor authentication meaning if we do credential stuffing and we do log
in as the user is it going to block us once we log in with multi factor and say hey we need something
else from you or is it just gonna let us in and other things it's asking about does it expose session
I.D. in the URL so sometimes your session I.D. or your cookie is going to be in your your URL which
is not good.
It's not best practice and it will it rotate your session I.D..
So what happens is when you log in you should get a session I.D..
And it should rotate some Web sites when you go to the Web site.
It gives you a session I.D. and then you log in and then it rotates you log out and it rotates.
Some other Web sites you log in in the session I.D. stays the same.
And you log out in the session I.D. stays the same.
That is what's called session fixation.
And that could get really dangerous as well.
And so just looking over these it's all dealing with authentication issues and that's it's a big bucket
of things that it could fall into and for this one we're not going to talk prevention in a separate
video.
We're just gonna talk prevention kind of as we go in through this but you know you should be checking
your Web site.
You should have multi factor authentication right.
You shouldn't be using weak credentials.
You should be rotating your session I.D..
A lot of this is kind of like common sense but it's over a thought or overlooked.
I should say when developing applications.
So these are just easy wins for us.
You should have a you know rate limiting when you're doing brute force attacks or you should have like
a captcha on there or something that will prevent me from attacking your Web site or your log in over
and over and over.
You should not be allowing wi credentials.
You should be doing checks for those.
You should have you know just preventative measures in place for all of these sorts of attacks.
And for reference this is great down here again the cheat sheets on different things and different types
of attacks in here session fixation you could see actually in my history because I navigate to this
quite a bit.
This is one that we find quite a lot.
And we'll cover this one gets the reporting section.
So keep that in mind.
Again we'll all have a great example of session fixation for you in the reporting section.
So from here we're going to go into a how to video it when we're just to talk about testing for it and
looking for broken authentication.
And I'm going to talk about some minor findings that we might encounter as well and how we're going
to look for those and just how we would test for this.
More so than how or or the vulnerabilities that are there.
And I'll explain that next video why we're doing that.
So I'll catch you over the next video and we start testing for broken authentication.