A1: Broken Object Level Authorization

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 »

1 hour 43 minutes
Video Transcription
everyone Welcome back to the course. So in the last video, we just talked a little bit about what a wasp actually is again. The open Web application security project is an organization that's international and the whole focus is Web security.
In this video, we're gonna talk about the first item on the S top 10 list. So broken object level authorization. We're gonna talk about what it actually is. We'll also talk about ways that you can prevent or mitigate it.
So what is broken Object level authorization. Well, what happens is an attacker will take the i d of their resource in the AP in the a p. I call. They're making and then they're basically going to swap that out with somebody else's resource. I d. So the resource idea of another user
And if you don't have proper authorization checks in place with your a p, I, then that attacker will get access to whatever that other user has access to.
And so this is sometimes called. This attack is sometimes called a secure, direct object reference or ideo i door.
How can we prevent against this?
Well, one of the ways to prevent against it is
authorization checks so we can implement authorization checks with a hierarchy and user policies. We can also use I ds that are stored in the session object itself and not rely on ideas that the client ascending So and that example I gave the Attackers sending the I d. So we can not rely on that. And then it doesn't matter what I do that the Attackers actually sending to us.
We can check authorization each time that there's a client request to access the database. Right. So, um,
again going back to authorization checks and then we can use random or non decibel I d. So an example might be where you have something like a P I.
And then you force last shop one ford slash like financials, right? Ah, And then the attacker just randomly. Guess is that it's the next area might be a p I for its last shop, too.
Four slash financial financials. So we don't want to have decibel ideas like that, right, Because that's shop one and then shopped to and then you could make a determination that's probably shop three shop for etcetera. So that's what we're talking about with random i DS and non decibel ideas wouldn't make it more difficult for an attacker to actually be able to perform this type of attack.
So a quick quiz question all the following are ways to prevent either attacks except
which one of those
our city guest
number three rate limiting you would be correct. So again, that's something we didn't cover. But you'll notice we're going to be mentioning rate limiting as a way to mitigate many of the upcoming attacks.
So in this video, we just talked about what broken object level authorization is. We also talked about some ways to prevent or mitigate mitigate against it again. Authorization checks is a big one using random or non decibel I DS and also not using I DS that are sent directly from the client we canoes ideas that are stored directly in the session object
Up Next