5.1 Broken Access Control

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

12 hours 9 minutes
Video Transcription
Hi, everyone. Welcome back to the core. So in the last video, we wrapped up our lab on XML External entities or X x e.
In this video, we're gonna talk about broken access control. Now, I just want to give you a quick reminder that for all the labs, with the exception of the Capstone one, all the labs will have a step by step guide, but that's available to download in the supplement of Resource is section. Also, all these power points are available there as well. In addition to that
carry LeBlanc who's one of the th on this particular course? We're teaching assistants. He created some awesome practice questions. So be sure to download a CZ Well, all in the supplement of resource is section.
So just a quick pre assessment question here to get us started. David was visiting his favorite website about cute kittens. I mean, like, who doesn't like that? Right
On a curiosity, he decided check of the side is vulnerable in regard to access control. So what? So we could test for broken access controls. Which one of these is not a way that he could test for broken access control
or as if he said, answer a D that is correct. So disabling Web server directory listings is actually way to help prevent against a risk of broken access, control and all the other items or ways that you can see if you're vulnerable to access control issues.
So we're learning objectives again. As usual, we talk about the risk grading. First, we'll move into, like, what is broken isis control. How do we check for it? Wasted mitigated. What kind of impact it has, etcetera, etcetera.
So the rating system here you old is you'll notice, like only one like major thing under the technical impact. So you know, again, the main thing there is since we're
using someone else's credentials in some respect, right? Like we're not having that re authenticated. Say, yeah, I am an admin. We're basically just logging in its ourselves as a user. And then we're able to go do all sorts of things, like deleting accounts, actually seeing other accounts, updating records, the leading records, all sorts of stuff.
So, as I mentioned, you know, we're not restricting the user and the situation where we have broken access control, we're not restricting the user So essentially the authenticated user. So they've authenticated. But what we're strips them are restrictions on them. It's not being properly enforced. So I may set you up and say, like, Yeah, you know,
your account will only have this access, but it's actually not being enforced by either the system for ourselves,
a cz humans.
And, as I mentioned, that could lead to things like privilege escalation. So, for example, from a regular user, I can log in as myself, and then I can escalate and pretend I'm an admin. No,
with that aspect of having that access now, it puts a risk of, you know, data as well. So you may delete my data. You may alter the data et cetera,
and then, you know, this may give you access to sensitive files, right? So if you pretend you're an admin, if you're able to get that access than now, you may back have access to a lot of intellectual property or other sensitive files for the company
so isn't prevalent. Well, yes, it's it's prevalent, mostly because it's difficult to run like automated detection, you know, and then also ah, a lot of times application developers are lacking functional testing for these particular vulnerabilities, so they may not catch everything
out the door. And again, that's why we need to get more automated tools out there. So we could make this a lot easier,
and we will probably find a lot more instances of it. Hopefully by the next will not hopefully, right? I don't want it to occur, by the way, but we may see it higher on the list the next time around. The whole lost produces a list
also, You know,
changing the http method is somewhat common by Attackers. So what That means, you know, you're changing it from, say, get versus put, you know, something like that where we're instead of us, you know, pulling information. We're pushing information. So as an attacker, we're pushing information to the Web server
and then, you know, direct our object references as well.
So how to check? So what can we do to check this stuff? How do we know we're vulnerable to it?
If we could modify the you are ill, that's that's one indication s. So if we could modify the euro l and then all of a sudden we can access you know, like an administrator Kim an administrator account or, you know, like password files or something like that. Then we definitely know that we're vulnerable to that. If we could do key changing key changing
from there. Once we've done these things, if we can escalate privileges
if you know we can Ultimate data Or, you know, even if we can change around like once we've authenticated can we change around different pages and then get authenticated at somebody else as we have changing around the different pages. So that's something else to keep in mind as well.
So the impact, you know, as I mentioned a few times, privilege escalation. So that way, you know, I I as an attacker could pretend on you. And it's killing my friend privileges because you're an administrator and I want that access.
It is a mention with the data. You know they can. They can create data. They can upload it, taken delete data, they concur, just corrupt it if they want to. So all these aspects, or why it's important for us to mitigate against this risk.
So speaking of mitigation or prevention, we want to deny by default, we also want to make sure we have proper access controller that we're using strong access control in place. We want a disabled Web server Directory listings, as I mentioned before, also log any failure. So he failed. Log in attempts, especially if they're failed. Logan attempts for like an admin account,
my cheri love those and are taking action on those
and then a value and validating Jason Webb tokens as well. There's another method that we can use.
So just a quick post assessment question here. Ways to prevent against broken isis control include all the following except
all right. So if he said cooking tampering, you are correct. So again, an attacker will be altering or tampering with the cookie to try to break in. But we would not be doing that as a defender. Rule. Try to forgive, to prevent against this.
All right, so in this video we talked about broken access control
in the next video. Where did go over our lab on broken access control So you could see what some of the topics we talked about actually look like in the real world
Up Next