WEBVTT

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


00:00:06.150 --> 00:00:08.970 align:middle line:84%
Welcome back to Cross-Site
Scripting session.

00:00:08.970 --> 00:00:11.790 align:middle line:84%
In this second part, we will
exploit a cross-site scripting

00:00:11.790 --> 00:00:14.590 align:middle line:84%
vulnerability in our
target application.

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

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

00:00:20.640 --> 00:00:22.360 align:middle line:84%
As discussed in
the previous part,

00:00:22.360 --> 00:00:24.240 align:middle line:84%
we will test the
product search feature

00:00:24.240 --> 00:00:26.280 align:middle line:84%
and understand how it
works and whether it

00:00:26.280 --> 00:00:29.450 align:middle line:84%
is vulnerable to
cross-site scripting.

00:00:29.450 --> 00:00:32.224 align:middle line:84%
Let's pop up developer tools
to inspect the network traffic.

00:00:32.224 --> 00:00:41.850 align:middle line:90%


00:00:41.850 --> 00:00:45.690 align:middle line:84%
Note that our search keyword
now also appears in the URL

00:00:45.690 --> 00:00:47.130 align:middle line:90%
and in the page's body.

00:00:47.130 --> 00:00:54.200 align:middle line:90%


00:00:54.200 --> 00:00:56.050 align:middle line:84%
In the network, we
can see a request

00:00:56.050 --> 00:00:59.080 align:middle line:84%
to a search end point
with a q parameter,

00:00:59.080 --> 00:01:00.985 align:middle line:84%
but it does not include
our search keywords.

00:01:00.985 --> 00:01:10.390 align:middle line:90%


00:01:10.390 --> 00:01:13.270 align:middle line:84%
In fact, the response
returns all products,

00:01:13.270 --> 00:01:15.430 align:middle line:84%
and then they are
filtered client side.

00:01:15.430 --> 00:01:22.290 align:middle line:90%


00:01:22.290 --> 00:01:24.570 align:middle line:84%
If we find a
vulnerability, then it

00:01:24.570 --> 00:01:28.970 align:middle line:84%
will be a client XXS,
as discussed before.

00:01:28.970 --> 00:01:30.670 align:middle line:84%
Let's have a look
at the page's DOM.

00:01:30.670 --> 00:01:45.640 align:middle line:90%


00:01:45.640 --> 00:01:47.710 align:middle line:84%
Using another search
keyword, we see

00:01:47.710 --> 00:01:49.060 align:middle line:90%
that the DOM node is updated.

00:01:49.060 --> 00:01:56.870 align:middle line:90%


00:01:56.870 --> 00:01:59.060 align:middle line:84%
Let's use the XXS
payload we used

00:01:59.060 --> 00:02:01.430 align:middle line:84%
as example in the first
part of this session.

00:02:01.430 --> 00:02:22.520 align:middle line:90%


00:02:22.520 --> 00:02:24.950 align:middle line:84%
The payload also
appears in the URL,

00:02:24.950 --> 00:02:28.280 align:middle line:84%
but this time, it isn't visible
next to the search results

00:02:28.280 --> 00:02:29.060 align:middle line:90%
title.

00:02:29.060 --> 00:02:31.760 align:middle line:84%
Nevertheless, we can
find it in the DOM.

00:02:31.760 --> 00:02:35.460 align:middle line:90%


00:02:35.460 --> 00:02:38.970 align:middle line:84%
The model box was not triggered,
meaning that our payload was

00:02:38.970 --> 00:02:40.470 align:middle line:90%
not executed.

00:02:40.470 --> 00:02:43.560 align:middle line:84%
Some frameworks have XXS
prevention mechanisms,

00:02:43.560 --> 00:02:45.510 align:middle line:90%
and this may be the case.

00:02:45.510 --> 00:02:48.600 align:middle line:84%
In such cases, we should try
to bypass such mechanisms

00:02:48.600 --> 00:02:50.900 align:middle line:90%
testing different payloads.

00:02:50.900 --> 00:02:52.000 align:middle line:90%