OK, broken access control, what type of vulnerability is this?
Well, before we define it, let's first see what access control itself is.
Access control is how Web application grants access to content and functions to some users notice that
is said to some users, so not all of them.
Access control is part of the application that decides who gets to see which content and who doesn't,
sometimes x control can be strictly tied to authorization and session.
And in some cases, it might even be the exact same vulnerability as broken authentication, which we
already covered.
However, there is more to it than that.
Once we covered broken authentication, we mostly focused on breaking the session and the indication
of the user broken access.
Control, on the other hand, can also target not only sessions but for example, different files or
directories on the webpage.
Perhaps some users have access to certain files that are on the Web page and the others don't.
If the access control is not performed properly, we could also get access to those files.
Same goes with directories.
Perhaps there are some directories that are only meant for admin to use and visit, but they have no
access control and can easily be visited by adding the directory name to the link.
This is also broken access control, vulnerability besides different files.
It might also allow us to see other user information.
Now all of this is once again due to developers mistake.
If the access control is not implemented properly, then you might have the broken access vulnerability
and it could look something like this.
Let's say we have a random site that has a function to choose a file and perhaps download it on your
machine.
Choosing a file should have its own access control, we can assume that this random file is stored somewhere
on the server, but so are all the other files that we don't have an option to download.
So have they implemented a good and valid filter that will only allow us to download the files that
they offer?
Well, if we can find out if it tried something like this.
What if we type instead of friend of father?
We tiepin slash, azzi slash.
If we get the output of dependability file or if it downloads it to our page, we have an example of
broken access control.
We downloaded something that we should not have been able to.
This type of vulnerability can also be called either or, in other words, insecure, direct object
reference.
This vulnerability occurs when an application uses user supplied input to access objects directly,
and we will see more examples about it in the practical lessons.
So let's first of all, start with our try Haxby platform.
OK, here we are on our platform and we have broken access control challenge, which is task number
18 now.
As usual, I advise you to read to all of the broken access control tasks, which in this case is task
number 17 and task number 18.
I have already started the machine.
Here is the IP address to the machine.
And now we need to perform these challenges right here.
So let's first of all, navigate to this page by copying IP address and pasting it right here.
So not viewer, what user are you and we have the field to login with username and password.
Let's check whether they supplied us with some information as to how to log in to this page.
And here it is.
The user name is not and the password is test.
One, two, three, four.
Let's pipe that in.
And let's submit this.
And it gives us a rather simple page that only type S I am not with the exclamation mark.
But if we take a look at the link, we have this parameter right here that says not equals one, and
this is the parameter that we can try to tamper with.
We can conclude that this parameter could have something to do with the user ID, for example.
Maybe this parameter that equals to one is strictly made for our note account.
So what would happen if we change it to two?
Well, we don't get anything what would happen if we change it to three, for example?
We still don't get anything.
Let's try changing it to zero.
Press enter and here's the flack.
We got the flag from a different account, which means that we have an example of broken access control
vulnerability on this virtual machine.
This was rather easy.
All we had to do is change this parameter right here.
But it's all possible due to them not filtering our input correctly.
They don't have any control over this parameter as to what the user can do with it.
In real Web applications, this input right here should be very well filtered that if you try to change
the session or try to change the user I.D., it just goes back to your own account.
It doesn't let you see the information from different users.
And in our case, this is our flag that we need to specify as the answer.
Look at the other users note and let's page the flag submitted and it's the correct answer.
OK, so this was rather easy.
Now let's look at some a little bit more difficult examples on our always be a virtual machine see on
the next lecture.