Target Website Link

So when looking for broken access control vulnerabilities.

We're trying to see if we can access or modify information that does not belong to us.

We can do this by trying to access or modify data without logging in.

And then we can create an account on the target to have application if it allows you to create accounts and see if you can access or modify data that belongs to another user.

And we'll have a lot of examples of this as we go through this section.

So don't worry about it.

But let's start with something very simple just to get you warmed up and also to get you used to intercepting and modifying data using burp proxy.

I'll include a link to the example in the resources of the lecture as usual.

And usually I would test every single functionality and press every single button within the website as a normal user.

And then I would go to the my account and create a user on the target website.

Because usually once you create a user on the target website and login, you will have access to more features.

So for example you might be able to add comments or reviews and you'll also probably be able to edit your information on your profile.

So that opens up a lot more functionality and therefore opens up a larger attack surface and therefore increasing my chances of discovering bugs.

Now we'll talk more about my hacking methodology later on in the course in the last section.

But right now I'm talking about it because also once you log in, you'll be able to test for access control vulnerabilities and see if you can access or modify data that belong to other users.

Now in this website you can't create an account because it's a test website.

But they are giving us an account that's already created on the target website.

So the user name is weiner and the password is peter.

So we're going to copy this and we're gonna paste it here in the user name and in the password we're gonna log in.

And perfect, as we log in as you can see and like I said earlier, you already have an extra feature in here which allows you to update your email.

So that's why when you create an account you should go ahead and

go through the whole website and see what extra features opened up.

Once done with that,

you should test for access control vulnerabilities and see if you can access data that belong to other users.

Now we're not doing a full pen test or a full bug hunt.

We will talk more about that in the last section of the course.

I'm gonna go directly to where the bug is and that is in the admin page.

So we saw earlier how to use ferobuster to discover such paths.

We're assuming you've already done that.

And we're going to the admin page, we're gonna load it as is usually before intercepting the requests and as you can see it's telling you you can only access the admin if you're logged in as administrator makes sense.

Now let's turn on our interceptor and let's go back to the admin page.

Hit enter and perfect as usual we're going to intercept the request in here.

We can see it's a get request to the admin end point to the admin page and usually you would actually have disclosed because I opened it in the last lecture.

So if you click in here you'll be able to see all of the requests and I have all the categories unfolded as well because I manually unfolded them.

So in a real life scenario it will look like this.

And if you click on the request parameters you can see the get request and the path it's going to.

You have nothing in the query or in the body parameters so nothing to test them there.

But we have two cookies being sent.

And as you can see one of the cookies is very interesting because the name of it is admin and its value is false.

So let's see what happens if we set this value to true.

We're gonna hit enter and we're going to forward this request and perfect now that we set that cookie to true, as you can see we got access to the admin page.

This admin page right here as you can see it's very simple just for testing but nevertheless this is a real bug that you would be able to submit in a real bug hunt and in a pentest, you should definitely include that in your report.

Now, usually admin panels allow you to do so much more than simply deleting users.

But in here if you go ahead and try to delete a user, for example the user carlos and let's turn off our interceptor because we want this to go ahead because we don't want to intercept anything.

You'll see you're going to get the error again.

Admin interface only available to logged in users.

You're getting this error because when we clicked on the delete our cookie was set to false again.

Therefore the request was executed as a normal user and not as admin.

So you'll have to intercept it again and set it to true.

And if this admin page offered more functionality, you'll have to intercept every single request and manually change the value of the cookie to True.

Alternatively, we can use defined under place functionality of Burp suite.

So if we go on the options in here and go to the match and replace.

You can see we have already a number of rules preset by the developers of Burp suite.

But what we want to do is we want to add our own rule and we want to say that every time you see a certain string we want to replace it with something else.

Now for us to get that string we actually have to go and intercept the request again.

So I'm gonna turn on the interceptor. I'm gonna go back to the admin page and I'm gonna find the cookie which sets the admin to false.

So it's this cookie right here, so it's saying admin is equal to false.

I am gonna copy this, I am going to go to my options to define and replace.

I'm going to click on add to add a rule and I'm going to say every time you see admin is equal to false, I want you to replace it with admin is equal to true.

We're going to say okay and we're gonna make sure that this rule that we just created is ticked.

So now I won't even need to intercept anything.

So let me just drop this package whatever it was.

I'm gonna turn off my interceptor and once I load the web page in here the data is gonna go through burp proxy but it's not gonna be intercepted.

It's just gonna automatically replace every time it sees admin equal to false, it's gonna replace it with admin is equal to true.

So let me show you I'm gonna hit enter in here and perfect I'm already at the admin page.

If I go to home I already have access to the admin page because burp is automatically replacing admin is equal to false with admin is equal to true.

So if I have an admin page that has a lot of features in here.

I'll be able to use it just like an admin user without having to intercept every single request and manually modifying it in here in Burp.

Now this match and replace feature is very useful in so many scenarios.

So I'm just using this as an example to show you how to use this feature.

But as you go ahead and start pen testing and bug hunting, you're going to notice a lot of scenarios while you'll need to automatically find a certain string and replace it with something else.

And this feature is going to come very very handy.

So just to complete this I'm gonna have to delete the user called carlos.

And perfect as you can see I'm able to delete this user because like I said, burp is automatically setting my privileges to admin.

Now, once done, you want to make sure that you go back to your rule and either untick it.

So that burp stops applying it to every packet that it intercepts or you can simply remove it from the lists if you're not going to use it anymore.

This is very important so that it won't interfere with any further tests that you're going to carry on on your target web application