WEBVTT

00:00:00.000 --> 00:00:07.870 align:middle line:90%


00:00:07.870 --> 00:00:10.930 align:middle line:84%
Welcome back to Broken
Access Control session.

00:00:10.930 --> 00:00:13.900 align:middle line:84%
In this second part, we will
exploit different authorization

00:00:13.900 --> 00:00:17.200 align:middle line:84%
issues in our intentionally
vulnerable application.

00:00:17.200 --> 00:00:19.640 align:middle line:84%
We will jump straight to
the hands-on exploitation,

00:00:19.640 --> 00:00:22.980 align:middle line:84%
and then move on to
the mitigation part.

00:00:22.980 --> 00:00:24.810 align:middle line:84%
We want to exploit
authorization issues

00:00:24.810 --> 00:00:27.660 align:middle line:84%
to access other users
data or execute actions

00:00:27.660 --> 00:00:29.190 align:middle line:90%
on their behalf.

00:00:29.190 --> 00:00:31.260 align:middle line:84%
We should look for some
feature allowing users

00:00:31.260 --> 00:00:34.722 align:middle line:84%
to submit data to the system
and maybe retrieve it back.

00:00:34.722 --> 00:00:36.180 align:middle line:84%
Since we don't have
an account yet,

00:00:36.180 --> 00:00:38.130 align:middle line:84%
let's see what
anonymous users can do.

00:00:38.130 --> 00:00:46.720 align:middle line:90%


00:00:46.720 --> 00:00:49.750 align:middle line:84%
Customer feedback seems to be
available to anonymous users,

00:00:49.750 --> 00:00:52.990 align:middle line:84%
allowing them to submit
some comment in writing.

00:00:52.990 --> 00:00:54.820 align:middle line:84%
Let's pop up
developer tools to be

00:00:54.820 --> 00:00:57.955 align:middle line:84%
able to inspect network traffic
and then submit some feedback.

00:00:57.955 --> 00:01:22.690 align:middle line:90%


00:01:22.690 --> 00:01:26.470 align:middle line:84%
We have here a POST request
to feedback's API endpoint,

00:01:26.470 --> 00:01:29.050 align:middle line:84%
and we got a successful
HTTP response.

00:01:29.050 --> 00:01:30.535 align:middle line:84%
That's good, let's
see the details.

00:01:30.535 --> 00:01:34.120 align:middle line:90%


00:01:34.120 --> 00:01:37.000 align:middle line:84%
Our comment and rating were
sent as part of the request.

00:01:37.000 --> 00:01:41.050 align:middle line:90%


00:01:41.050 --> 00:01:43.180 align:middle line:84%
As a response, we got
another JSON object

00:01:43.180 --> 00:01:44.860 align:middle line:84%
which includes
our submitted data

00:01:44.860 --> 00:01:46.300 align:middle line:90%
and several other metadata.

00:01:46.300 --> 00:01:58.330 align:middle line:90%


00:01:58.330 --> 00:01:59.920 align:middle line:84%
Since it was
anonymous feedback, it

00:01:59.920 --> 00:02:03.680 align:middle line:90%
makes sense user ID to be "no".

00:02:03.680 --> 00:02:05.270 align:middle line:84%
From what we got
as a response, it

00:02:05.270 --> 00:02:09.910 align:middle line:84%
sounds like submitted feedback
is given a unique identifier.

00:02:09.910 --> 00:02:12.100 align:middle line:84%
Having such identifier
is useful when

00:02:12.100 --> 00:02:15.370 align:middle line:84%
you want to perform actions
upon a specific record.

00:02:15.370 --> 00:02:18.400 align:middle line:84%
We can take advantage of
REST API's predictive nature

00:02:18.400 --> 00:02:20.260 align:middle line:84%
and issue what
could be a request

00:02:20.260 --> 00:02:22.870 align:middle line:84%
to retrieve our feedback
object back from the API.

00:02:22.870 --> 00:02:27.790 align:middle line:90%


00:02:27.790 --> 00:02:31.720 align:middle line:84%
Instead of a POST request,
we should issue a GET request

00:02:31.720 --> 00:02:33.940 align:middle line:84%
and append record
identifier to the path.

00:02:33.940 --> 00:02:37.780 align:middle line:90%


00:02:37.780 --> 00:02:41.330 align:middle line:84%
We got the 401 HTTP status
code, meaning that there was

00:02:41.330 --> 00:02:44.690 align:middle line:90%
a error processing our request.

00:02:44.690 --> 00:02:46.400 align:middle line:84%
Based on the error
message, it looks

00:02:46.400 --> 00:02:49.400 align:middle line:84%
like we need to be authenticated
to perform such action.

00:02:49.400 --> 00:02:51.080 align:middle line:84%
Let's create an
account and log in.

00:02:51.080 --> 00:02:56.500 align:middle line:90%


00:02:56.500 --> 00:02:59.680 align:middle line:84%
Let's now provide some feedback,
but this time, authenticated

00:02:59.680 --> 00:03:00.790 align:middle line:90%
as a regular user.

00:03:00.790 --> 00:03:26.930 align:middle line:90%


00:03:26.930 --> 00:03:29.240 align:middle line:84%
We can see the initial
request to send our feedback

00:03:29.240 --> 00:03:29.930 align:middle line:90%
to the server.

00:03:29.930 --> 00:03:39.730 align:middle line:90%


00:03:39.730 --> 00:03:41.800 align:middle line:84%
Like before, we have
our comment in writing

00:03:41.800 --> 00:03:44.350 align:middle line:84%
as part of the request
body, but this time, we also

00:03:44.350 --> 00:03:45.490 align:middle line:90%
have our user ID.

00:03:45.490 --> 00:03:48.540 align:middle line:90%


00:03:48.540 --> 00:03:51.100 align:middle line:84%
The response is similar
to what we had before,

00:03:51.100 --> 00:03:54.420 align:middle line:84%
but again, it also
includes our user ID.

00:03:54.420 --> 00:03:57.090 align:middle line:84%
Note that this feedback
received ID number 9,

00:03:57.090 --> 00:04:01.650 align:middle line:84%
making feedback identifiers
sound sequential.

00:04:01.650 --> 00:04:03.960 align:middle line:84%
Let's try to retrieve
this feedback record back

00:04:03.960 --> 00:04:04.740 align:middle line:90%
from a server.

00:04:04.740 --> 00:04:09.450 align:middle line:90%


00:04:09.450 --> 00:04:12.690 align:middle line:84%
Again, instead of a POST
request, we should issue a GET

00:04:12.690 --> 00:04:14.580 align:middle line:84%
and append the feedback
ID to the path.

00:04:14.580 --> 00:04:19.110 align:middle line:90%


00:04:19.110 --> 00:04:21.690 align:middle line:84%
This time, we've got
a 200 status code.

00:04:21.690 --> 00:04:22.815 align:middle line:90%
Let's inspect the response.

00:04:22.815 --> 00:04:27.430 align:middle line:90%


00:04:27.430 --> 00:04:30.940 align:middle line:84%
We've got our feedback
back from the server.

00:04:30.940 --> 00:04:33.880 align:middle line:84%
What about our
anonymous feedback?

00:04:33.880 --> 00:04:36.790 align:middle line:84%
Since we know its ID, let's
see if we can access it.

00:04:36.790 --> 00:04:47.360 align:middle line:90%


00:04:47.360 --> 00:04:50.270 align:middle line:84%
A success HTTP status
code as before,

00:04:50.270 --> 00:04:52.730 align:middle line:84%
and in fact, we were
able to retrieve

00:04:52.730 --> 00:04:54.710 align:middle line:90%
the feedback from the server.

00:04:54.710 --> 00:04:57.340 align:middle line:90%
Strange.

00:04:57.340 --> 00:04:59.980 align:middle line:84%
Since the feedback
identifiers are sequential,

00:04:59.980 --> 00:05:02.350 align:middle line:84%
we can keep going and
see what else we can get.

00:05:02.350 --> 00:05:16.120 align:middle line:90%


00:05:16.120 --> 00:05:17.980 align:middle line:90%
Another anonymous feedback.

00:05:17.980 --> 00:05:19.050 align:middle line:90%
Let's try another one.

00:05:19.050 --> 00:05:29.930 align:middle line:90%


00:05:29.930 --> 00:05:31.520 align:middle line:84%
Okay, another
anonymous feedback.

00:05:31.520 --> 00:05:33.170 align:middle line:84%
Until now, we were
able to retrieve

00:05:33.170 --> 00:05:35.998 align:middle line:84%
our one feedback and a few
other anonymous records.

00:05:35.998 --> 00:05:38.540 align:middle line:84%
Definitely, there is something
wrong with the access control.

00:05:38.540 --> 00:05:39.370 align:middle line:90%
Let's keep going.

00:05:39.370 --> 00:06:22.060 align:middle line:90%


00:06:22.060 --> 00:06:25.480 align:middle line:84%
All right, finally some
non-anonymous feedback.

00:06:25.480 --> 00:06:29.670 align:middle line:84%
Now, we are sure that access
control is definitely broken.

00:06:29.670 --> 00:06:31.980 align:middle line:84%
If we can retrieve
other users' feedback,

00:06:31.980 --> 00:06:34.080 align:middle line:90%
maybe we can also delete it.

00:06:34.080 --> 00:06:41.010 align:middle line:90%


00:06:41.010 --> 00:06:43.935 align:middle line:84%
Instead of a GET request, this
time, we will issue a DELETE.

00:06:43.935 --> 00:06:55.770 align:middle line:90%


00:06:55.770 --> 00:06:58.620 align:middle line:84%
Apparently, the record
was successfully deleted.

00:06:58.620 --> 00:07:13.320 align:middle line:84%
Trying to retrieve it back
from the server should fail,

00:07:13.320 --> 00:07:16.910 align:middle line:90%
and it did.

00:07:16.910 --> 00:07:19.790 align:middle line:84%
Not only were we able to
retrieve other users' feedback,

00:07:19.790 --> 00:07:22.280 align:middle line:84%
but we were also
able to delete it,

00:07:22.280 --> 00:07:26.690 align:middle line:84%
actions that should be available
to Juice Shop admins only.

00:07:26.690 --> 00:07:29.060 align:middle line:84%
Definitely, the access
control is broken.

00:07:29.060 --> 00:07:31.950 align:middle line:84%
You'll certainly
find other issues.

00:07:31.950 --> 00:07:34.890 align:middle line:84%
Next, we will discuss what
makes the application vulnerable

00:07:34.890 --> 00:07:37.430 align:middle line:90%
and how to prevent it.

00:07:37.430 --> 00:07:39.000 align:middle line:90%