Welcome back to Broken access control session.
In this second part, we will exploit different authorization issues
in our intentionally vulnerable application.
We will jump straight to the Hands-On exploitation, and then move on
to the mitigation part.
We want to exploit authorization issues to access other users
data or execute actions on their behalf. We
should look for some feature allowing users to submit data
to the system and maybe retrieve it back since
we don't have an account yet. Let's see what Anonymous users can
do.
Customer feedback seems to be available to Anonymous users, allowing
them to submit some comment and rating. Let's
pop up developer tools, to be able to inspect Network
traffic and then submit some feedback.
We have here a post request to feedbacks API, endpoint
and regard. Tech successful. HTTP, response, status
code. Let's see the details.
Our comment and rating were sent as part of the request.
As response, we got another Json object which includes our
submitted data and several other metadata.
Since it was Anonymous feedback, it makes sense user ID
to be no.
From what we got this response. It sounds like submitted feedback is
given an unique identifier.
Having such an indie fire is useful. When you want to perform actions
upon a specific records. We can take
advantage of rest, apis predictive nature and issue.
What could be a request to retrieve our feedback object back
from the API?
Instead of a post request, we should issue a get
request and append record identifiers to the path.
We got the 401 HTTP status code, meaning that
there was an error processing. Our request.
Based on the error message. It looks like we need to be authenticated to
perform such action. Let's create an account and login.
Let's now provide some feedback. But this time authenticated, as
a regular user.
We can see the initial request, to send our feedback to the
server.
Like before we have our commenting rating as part of the request
body, but this time we also have our user ID.
The response is similar to what we had before, but again, it
also includes our user ID note
that this feedback received ID, number nine, making feedback
identifiers on sequential.
Let's try to retrieve this feedback record, back from the server.
Again, instead of a post request we should issue a get and
depend the feedback I did to the path.
This time, we got the 200 status code. Let's
inspect the response.
We've got our feedback back from the server.
What about our Anonymous feedback? Since
we know it's ID. Let's see if we can access it.
A success HTTP status code as before. And
in fact, we were able to retrieve the feedback from the
server strange.
Since the feedback identifiers are sequential, we can keep
going and see what else we can get.
Another anonymous feedback. Let's try
another one.
Okay, another anonymous feedback until now we were able
to retrieve our one feedback and a few other Anonymous records.
Definitely. There's something wrong with the access control. Let's
keep going.
All right, finally some non Anonymous feedback.
Now, we are sure that access control is
definitely broken.
If we can retrieve other users feedback, maybe we
can also delete it.
Instead of a get request this time. We will issue a
delete.
Apparently, the record was successfully deleted trying
to retrieve it back from the server should fail.
And it did.
Not only we were able to retrieve other users feedback, but
we were also able to delete it actions
that should be available to Juice. Shop at means only
definitely the access
control is broken to certainly find other issues.
Next, we will discuss what makes the application vulnerable and
how to prevent it.