Welcome back to cross-site scripting session and
the second part. We will exploit a cross-site scripting
vulnerability in our Target application. We
will jump straight to our intentionally vulnerable application and
then move on to the mitigation part as
discussed. In the previous part. We will test the product search
feature and understand how it works. And whether it is
vulnerable to cross-site scripting
Let's pop up developer tools to inspect a network traffic.
Note that our search keyword now also appears in
the URL and in the pages body.
The network, we can see request to search and
point with the Q parameter, but it
does not include our search keyword.
In fact, the response returns all products and
then they are filtered client site.
If we find a vulnerability then it will be a client access
as discussed before.
Let's have a look at Pages dumb.
Using another search keyword. We see that the Dom node
is updated.
Let's use the x axis pillowed. We used. As example
in the first part of this session.
The payload also appears in the URL, but this
time, it isn't visible next to the search results title.
Nevertheless. We can find it in the
dome.
The model box was not triggered. Meaning that our payload
was not executed. Some Frameworks have
X access prevention mechanisms. And this may be the
case in such cases. We should try to bypass such
mechanisms, testing different payloads.
This is the original payload. Let's try something different
this time. We will use an
image tag with an empty Source, attribute. Meaning
that loading image will fail in
case of error and model box with the text X
access should be shown.
Let's copy and paste it in the search box.
Here it is. Our model box.
As you can see, the payload is also in the URL.
It doesn't appear in the pages body, but it
was added to the Dom.
Since the payload is in the URL, if we
send it to another user, then it will be executed in
the users browser.
Let's go a step further, first. We need to know what
information is stored in the browser when we are authenticated.
We have several cookies and
one item in the local storage. The
token is also stored as a cookie in
both are used for authentication purposes. The
value is a Json web token, which we can decode and
see what's inside. As long as the payload section, is not encrypted.
In this case, we can see the email password and
role among several other details.
Let's now change our X access payload to
show tokens value. In the model box, instead of the word xss.
Instead of typing the payload in the search input field. We
can craft a malicious URL to send to our victims.
Assuming Juice Shop admin receives and visits this URL. Then
the model box should show the value of admins
token.
Instead of opening a model box, attackers can
use other techniques to receive the value on the servers controlled
by them.
Assuming this is what happened. Let's see, what an attacker can
do with the token on each one browser.
As you can see, there's no active session in attackers browser.
The browser doesn't have a cookie called token. So
we will create one with the value stolen from
victims browser.
We have to do the same in the local storage.
Now, if you reload the page.
We are authenticated as Joyce shop. Admin.
This is called session hijacking. One of x-axis possible
consequences. And from now on we can
act on admins behalf. Next we
will discuss what makes the application vulnerable and
how to prevent it.