WEBVTT

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


00:00:06.520 --> 00:00:08.170 align:middle line:90%
This is the original payload.

00:00:08.170 --> 00:00:10.650 align:middle line:90%
Let's try something different.

00:00:10.650 --> 00:00:13.200 align:middle line:84%
This time, we will
use an image attack

00:00:13.200 --> 00:00:15.810 align:middle line:84%
with an empty source
attribute, meaning

00:00:15.810 --> 00:00:18.300 align:middle line:90%
that loading image will fail.

00:00:18.300 --> 00:00:22.140 align:middle line:84%
In case of error, a model
box with the text "XSS"

00:00:22.140 --> 00:00:22.950 align:middle line:90%
should be shown.

00:00:22.950 --> 00:00:27.500 align:middle line:90%


00:00:27.500 --> 00:00:29.600 align:middle line:84%
Let's copy and paste
it in the search box.

00:00:29.600 --> 00:00:35.320 align:middle line:90%


00:00:35.320 --> 00:00:37.060 align:middle line:90%
Here it is, our model box.

00:00:37.060 --> 00:00:41.100 align:middle line:90%


00:00:41.100 --> 00:00:43.425 align:middle line:84%
As you can see, the
payload is also in the URL.

00:00:43.425 --> 00:00:46.570 align:middle line:90%


00:00:46.570 --> 00:00:48.790 align:middle line:84%
It doesn't appear
in the page's body,

00:00:48.790 --> 00:00:52.850 align:middle line:90%
but it was added to the DOM.

00:00:52.850 --> 00:00:56.750 align:middle line:84%
Since the payload is in the URL,
if we send it to another user,

00:00:56.750 --> 00:00:59.160 align:middle line:84%
then it will be executed
in the user's browser.

00:00:59.160 --> 00:01:12.410 align:middle line:90%


00:01:12.410 --> 00:01:13.840 align:middle line:90%
Let's go a step further.

00:01:13.840 --> 00:01:16.120 align:middle line:84%
First, we need to
know what information

00:01:16.120 --> 00:01:18.820 align:middle line:84%
is stored in the browser
when we are authenticated.

00:01:18.820 --> 00:01:57.630 align:middle line:90%


00:01:57.630 --> 00:02:03.450 align:middle line:84%
We have several cookies and
one item in the local storage.

00:02:03.450 --> 00:02:06.330 align:middle line:84%
The token is also
stored as a cookie,

00:02:06.330 --> 00:02:10.470 align:middle line:84%
and both are used for
authentication purposes.

00:02:10.470 --> 00:02:13.590 align:middle line:84%
The value is a JSON web token,
which we can decode and see

00:02:13.590 --> 00:02:16.170 align:middle line:84%
what's inside as long as
the payload section is not

00:02:16.170 --> 00:02:17.179 align:middle line:90%
encrypted.

00:02:17.179 --> 00:02:39.660 align:middle line:90%


00:02:39.660 --> 00:02:42.870 align:middle line:84%
In this case, we can see the
email, password, and role,

00:02:42.870 --> 00:02:44.130 align:middle line:90%
among several other details.

00:02:44.130 --> 00:02:48.820 align:middle line:90%


00:02:48.820 --> 00:02:51.610 align:middle line:84%
Let's now change our
XSS payload to show

00:02:51.610 --> 00:02:54.790 align:middle line:84%
token's value in the model
box instead of the word "XSS".

00:02:54.790 --> 00:03:11.050 align:middle line:90%


00:03:11.050 --> 00:03:13.990 align:middle line:84%
Instead of typing the payload
into the search input field,

00:03:13.990 --> 00:03:16.705 align:middle line:84%
we can craft a malicious
URL to send to our victims.

00:03:16.705 --> 00:03:35.400 align:middle line:90%


00:03:35.400 --> 00:03:38.910 align:middle line:84%
Assuming Juice Shop admin
receives and visits this URL,

00:03:38.910 --> 00:03:41.970 align:middle line:84%
then the model box should show
the value of admin's token.

00:03:41.970 --> 00:03:45.580 align:middle line:90%


00:03:45.580 --> 00:03:48.100 align:middle line:84%
Instead of opening a
model box, attackers

00:03:48.100 --> 00:03:50.350 align:middle line:84%
can use other techniques
to receive the value

00:03:50.350 --> 00:03:53.080 align:middle line:84%
on the servers
controlled by them.

00:03:53.080 --> 00:03:55.480 align:middle line:84%
Assuming this is what
happened, let's see

00:03:55.480 --> 00:03:58.360 align:middle line:84%
what an attacker can do with
the token on its one browser.

00:03:58.360 --> 00:04:15.520 align:middle line:90%


00:04:15.520 --> 00:04:17.649 align:middle line:84%
As you can see, there
is no active session

00:04:17.649 --> 00:04:18.700 align:middle line:90%
in attacker's browser.

00:04:18.700 --> 00:04:31.750 align:middle line:90%


00:04:31.750 --> 00:04:34.630 align:middle line:84%
The browser doesn't have
a cookie called token,

00:04:34.630 --> 00:04:37.060 align:middle line:84%
so we will create one
with the value stolen

00:04:37.060 --> 00:04:38.200 align:middle line:90%
from victim's browser.

00:04:38.200 --> 00:04:47.110 align:middle line:90%


00:04:47.110 --> 00:04:48.970 align:middle line:84%
We have to do the same
in the local storage.

00:04:48.970 --> 00:05:04.050 align:middle line:90%


00:05:04.050 --> 00:05:13.770 align:middle line:84%
Now, if we reload the
page, we are authenticated

00:05:13.770 --> 00:05:14.970 align:middle line:90%
as Juice Shop admin.

00:05:14.970 --> 00:05:38.480 align:middle line:90%


00:05:38.480 --> 00:05:40.640 align:middle line:84%
This is called
session hijacking, one

00:05:40.640 --> 00:05:44.030 align:middle line:84%
of XSS possible consequences,
and from now on, we

00:05:44.030 --> 00:05:46.730 align:middle line:90%
can act on admin's behalf.

00:05:46.730 --> 00:05:49.940 align:middle line:84%
Next, we will discuss what
makes the application vulnerable

00:05:49.940 --> 00:05:52.480 align:middle line:90%
and how to prevent it.

00:05:52.480 --> 00:05:53.000 align:middle line:90%