Broken Access Control
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »

Video Transcription
00:00
Hey, everyone is Canada Hill Master Instructor, a cyber. In this video, we're gonna talk about Web defense.
00:06
So a quick pre assessment question here, Robert was visiting his favorite website about cute kids, right? We all do that on a daily basis. And out of curiosity, he decided to check out. The side is vulnerable in regard to access controls. So which of the following here is not a way that he can actually test for broken access control?
00:25
All right, so I guess to answer D disabling Web server directory listings. You are correct. So that's not a way to test for broken access control. That's actually one of the things we do to help mitigate against it.
00:36
So you reckon access control, basically restrictions. They're not gonna be enforced on the Web application. That can lead to things like privilege escalation, which you obviously don't want. They can also lead to us losing our data or, you know, sensitive files being stolen by an attacker.
00:51
It's actually pretty common again. A lot of these things boil down to improper configurations when organizations were rolling these out as well as using a lot of default credentials.
01:02
So you know manual testing, doing things like http method or direct object references. Those are things that Attackers can do to try to figure out if the application is vulnerable to the stop of tack.
01:14
How do we check for it on our end of things so we can check and see if we can do any type of privilege escalation? We can check and see if we can do any type of changes to metadata modifying ur ells. If we can do that, that's actually a pretty easy way for an attacker to do the attack.
01:30
The impact again privilege escalation, which then can lead to things where they can create information, the database or create user accounts that can also access data. We don't want them to access that can update data so they can corrupt our data. Or they can also delete the data from the database, which again, we really don't want them to do
01:49
so. How do we prevent it? I talked about already in the pre assessment question. They're disabling Web server directory listings, also implementing better access control, denying by default, logging any types of authentication failures. So have and even in play, putting in place controls where we
02:05
If I try three times and I can't if I'm trying
02:08
with wrong credentials three times it locks me out and then I have to do something to verify It's actually me and not an attacker on and then also invalidating Jason Webb tokens as well.
Up Next
Instructed By
Similar Content