Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more

Exploitation Cont.

In this video, Paulo Silva will demonstrate a continued attempt to insert a payload into the system and expand on vulnerabilities to XSS threats.
This is the original payload. Let’s try something different. This time, we will use an image attack with an empty source attribute, meaning that loading image will fail. In case of error, a model box with the text “XSS” 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 page’s 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 user’s 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, and 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 XSS payload to show token’s value in the model box instead of the word “XSS”.
Instead of typing the payload into 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 admin’s 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 its one browser.
As you can see, there is no active session in attacker’s browser.
The browser doesn’t have a cookie called token, so we will create one with the value stolen from victim’s browser.
We have to do the same in the local storage.
Now, if we reload the page, we are authenticated as Juice Shop admin.
This is called session hijacking, one of XSS possible consequences, and from now on, we can act on admin’s behalf. Next, we will discuss what makes the application vulnerable and how to prevent it.

In this video, the demonstration on identifying if the system is vulnerable to XSS threats is continued

In the last video, you saw an attempt to insert a payload into the system, which was not successful. In this video, you will see a continued attempt to do so. You will also learn what these attempts and failures can tell you about the system to help you plan an alternate attack.

Investigate and share: You have just watched a demonstration on session hijacking. Go to the OWASP Session Hijacking page and read the information there. Do you think that your system is vulnerable to these kinds of attacks? What are you currently doing to mitigate these attacks? In the next video, you will learn more about how to protect your system, but first share your comments in the section below.

This article is from the free online

Advanced Cyber Security Training: OWASP Top 10 and Web Application Fundamentals

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now