WEBVTT

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


00:00:06.200 --> 00:00:08.900 align:middle line:84%
Welcome back to Using Components
with Known Vulnerabilities

00:00:08.900 --> 00:00:10.070 align:middle line:90%
session.

00:00:10.070 --> 00:00:13.100 align:middle line:84%
In this second part, we'll
exploit a known vulnerability

00:00:13.100 --> 00:00:15.330 align:middle line:90%
in our target application.

00:00:15.330 --> 00:00:17.690 align:middle line:84%
We will jump straight to
our intentionally vulnerable

00:00:17.690 --> 00:00:20.750 align:middle line:84%
application and then move
on to the mitigation part.

00:00:20.750 --> 00:00:28.090 align:middle line:90%


00:00:28.090 --> 00:00:30.220 align:middle line:84%
We can now retrieve
our JSON Web Token

00:00:30.220 --> 00:00:32.275 align:middle line:84%
from browser's cookies
or local storage.

00:00:32.275 --> 00:00:41.130 align:middle line:90%


00:00:41.130 --> 00:00:43.970 align:middle line:84%
Next, we will decode
our JSON web token.

00:00:43.970 --> 00:00:59.870 align:middle line:90%


00:00:59.870 --> 00:01:02.090 align:middle line:84%
JSON web tokens
have three sections,

00:01:02.090 --> 00:01:07.030 align:middle line:84%
all of them base64 encoded
and split by a dot.

00:01:07.030 --> 00:01:09.000 align:middle line:84%
The first section
is called header,

00:01:09.000 --> 00:01:11.280 align:middle line:84%
and it includes information
about token type

00:01:11.280 --> 00:01:14.112 align:middle line:84%
and the algorithm used to
compute token signature.

00:01:14.112 --> 00:01:20.520 align:middle line:90%


00:01:20.520 --> 00:01:22.770 align:middle line:84%
The second section
is called payload,

00:01:22.770 --> 00:01:25.005 align:middle line:84%
and it holds the
actual data or claims.

00:01:25.005 --> 00:01:27.940 align:middle line:90%


00:01:27.940 --> 00:01:30.580 align:middle line:84%
The third and last
section is the signature.

00:01:30.580 --> 00:01:33.700 align:middle line:90%


00:01:33.700 --> 00:01:35.980 align:middle line:84%
Tokens can be signed
by the server using

00:01:35.980 --> 00:01:38.980 align:middle line:84%
a key so the server is able
to verify that the token is

00:01:38.980 --> 00:01:41.770 align:middle line:84%
legitimate when it is
sent back by the client

00:01:41.770 --> 00:01:43.630 align:middle line:90%
in subsequent requests.

00:01:43.630 --> 00:01:47.210 align:middle line:84%
The signature is
calculated by base64 URL

00:01:47.210 --> 00:01:50.350 align:middle line:84%
encoding the header and
payload, concatenating them

00:01:50.350 --> 00:01:53.710 align:middle line:84%
with a period as a separator,
and passing the resulting value

00:01:53.710 --> 00:02:00.280 align:middle line:84%
to an algorithm, such as
the SHA-256 with a secret.

00:02:00.280 --> 00:02:03.070 align:middle line:84%
The name of the algorithm
used to compute the signature

00:02:03.070 --> 00:02:05.590 align:middle line:84%
is what goes into the
JSON web token headen

00:02:05.590 --> 00:02:08.740 align:middle line:84%
so that the same algorithm can
be used to verify a token's

00:02:08.740 --> 00:02:10.570 align:middle line:90%
authenticity.

00:02:10.570 --> 00:02:13.420 align:middle line:84%
This was a quick overview
of JSON web tokens.

00:02:13.420 --> 00:02:15.460 align:middle line:84%
But you're better
reading more about this

00:02:15.460 --> 00:02:19.720 align:middle line:84%
since JSON web tokens are very
popular and its use widespread.

00:02:19.720 --> 00:02:24.540 align:middle line:90%


00:02:24.540 --> 00:02:28.130 align:middle line:84%
So now let's talk about
the JWT common library's

00:02:28.130 --> 00:02:30.620 align:middle line:84%
vulnerability we
will try to exploit.

00:02:30.620 --> 00:02:34.190 align:middle line:84%
JWT libraries have to implement
at least two mandatory signing

00:02:34.190 --> 00:02:38.180 align:middle line:90%
algorithms, none and HFS 256.

00:02:38.180 --> 00:02:41.840 align:middle line:84%
The none algorithm is a
curious addition to JWT.

00:02:41.840 --> 00:02:43.970 align:middle line:84%
It is intended to be
used for situations

00:02:43.970 --> 00:02:47.720 align:middle line:84%
where the integrity of the
token has already been verified.

00:02:47.720 --> 00:02:51.230 align:middle line:84%
Some libraries treat the tokens
signed with the none algorithm

00:02:51.230 --> 00:02:54.020 align:middle line:84%
as a valid token with
a verified signature.

00:02:54.020 --> 00:02:56.480 align:middle line:84%
You must be seeing
where this is going.

00:02:56.480 --> 00:03:00.650 align:middle line:84%
We will replace the alg property
in the JWT header of our token

00:03:00.650 --> 00:03:01.700 align:middle line:90%
by none.

00:03:01.700 --> 00:03:03.920 align:middle line:84%
Then change some date
in the payload section

00:03:03.920 --> 00:03:06.110 align:middle line:90%
and remove the signature.

00:03:06.110 --> 00:03:09.338 align:middle line:84%
If Juice Shop is vulnerable,
our temporary JWT

00:03:09.338 --> 00:03:10.130 align:middle line:90%
should be accepted.

00:03:10.130 --> 00:03:12.940 align:middle line:90%


00:03:12.940 --> 00:03:16.030 align:middle line:84%
Let's copy and paste the
JWT header into our terminal

00:03:16.030 --> 00:03:16.810 align:middle line:90%
to decode it.

00:03:16.810 --> 00:03:30.240 align:middle line:90%


00:03:30.240 --> 00:03:33.030 align:middle line:84%
Now we copied the decoded
header, modified the alg

00:03:33.030 --> 00:03:36.690 align:middle line:84%
property, and encoded back
using base64 command line tool.

00:03:36.690 --> 00:03:50.140 align:middle line:90%


00:03:50.140 --> 00:03:52.930 align:middle line:84%
Let's copy and paste a new
header into our text editor,

00:03:52.930 --> 00:03:56.080 align:middle line:84%
appending a dot to separate
it from the payload section we

00:03:56.080 --> 00:03:57.460 align:middle line:90%
will append here later.

00:03:57.460 --> 00:04:05.780 align:middle line:90%


00:04:05.780 --> 00:04:07.910 align:middle line:84%
We need to do the
same with the payload.

00:04:07.910 --> 00:04:10.100 align:middle line:84%
Let's copy and paste
it into our terminal

00:04:10.100 --> 00:04:11.420 align:middle line:90%
so that we can decode it.

00:04:11.420 --> 00:04:22.580 align:middle line:90%


00:04:22.580 --> 00:04:25.280 align:middle line:84%
Now we copy and paste
the decoded payload,

00:04:25.280 --> 00:04:27.140 align:middle line:84%
modified email
property to something

00:04:27.140 --> 00:04:29.690 align:middle line:84%
that should not exist
in Juice Shop database,

00:04:29.690 --> 00:04:32.870 align:middle line:84%
and encode the modified
JSON payload using base64.

00:04:32.870 --> 00:04:58.310 align:middle line:90%


00:04:58.310 --> 00:05:01.850 align:middle line:84%
Again, let's copy and paste the
outcome into our text editor.

00:05:01.850 --> 00:05:11.230 align:middle line:90%


00:05:11.230 --> 00:05:13.960 align:middle line:84%
We won't add a signature,
since our token is not

00:05:13.960 --> 00:05:16.600 align:middle line:84%
signed according to
our new JWT header.

00:05:16.600 --> 00:05:19.780 align:middle line:90%


00:05:19.780 --> 00:05:22.990 align:middle line:84%
Now we are going to replace the
token in our browser's cookies

00:05:22.990 --> 00:05:25.960 align:middle line:84%
and local storage with our
crafted JSON web token.

00:05:25.960 --> 00:05:37.030 align:middle line:90%


00:05:37.030 --> 00:05:40.330 align:middle line:84%
Let's now access some pages and
see whether Juice Shop accepts

00:05:40.330 --> 00:05:42.160 align:middle line:90%
our crafted JSON web token.

00:05:42.160 --> 00:05:48.860 align:middle line:90%


00:05:48.860 --> 00:05:50.750 align:middle line:84%
As you can see,
the complaint form

00:05:50.750 --> 00:05:54.107 align:middle line:84%
shows the email address we
replaced in the JSON web token.

00:05:54.107 --> 00:05:55.565 align:middle line:84%
Let's see if we
can post a message.

00:05:55.565 --> 00:06:06.830 align:middle line:90%


00:06:06.830 --> 00:06:09.320 align:middle line:90%
It looks like we have done it.

00:06:09.320 --> 00:06:11.300 align:middle line:84%
Let's check the customer
feedback feature.

00:06:11.300 --> 00:06:14.490 align:middle line:90%


00:06:14.490 --> 00:06:16.140 align:middle line:84%
It also shows the
email address we

00:06:16.140 --> 00:06:18.270 align:middle line:90%
replaced in the JSON web token.

00:06:18.270 --> 00:06:19.815 align:middle line:90%
Let's also post some feedback.

00:06:19.815 --> 00:07:07.070 align:middle line:90%


00:07:07.070 --> 00:07:09.020 align:middle line:84%
Based on what we
have experienced,

00:07:09.020 --> 00:07:14.330 align:middle line:84%
that JSON web token library used
by Juice Shop is vulnerable.

00:07:14.330 --> 00:07:17.420 align:middle line:84%
Next we will discuss what makes
the application vulnerable

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

00:07:19.990 --> 00:07:21.000 align:middle line:90%