Blind & Stored Cross-site Scripting (XSS) – Generic Bug Bounty Report

In this article, we will discuss how a bug hunter received a bounty of $3000 on his finding on Blind & Stored Cross-Site Scripting (XSS), and how you can reproduce.

What is Blind Cross-Site Scripting?

Blind XSS vulnerabilities are a variant of persistent XSS vulnerabilities. They occur when the attacker input is saved by the web server and executed as a malicious script in another part of the application or in another application.

For example, an attacker injects a malicious payload into a contact/feedback page and when the administrator of the application is reviewing the feedback entries the attacker’s payload will be loaded.

The attacker input can be executed in a completely different application (for example an internal application where the administrator reviews the access logs or the application exceptions).

Example of Web Applications & Web Pages Where Blind XSS Attacks Can Occur

These are the wild places you should target when finding Blind XSS during bug hunting, they contain Blind XSS vulnerabilities.

• Contact/Feedback pages
• Log viewers
• Exception handlers
• Chat applications / forums
• Customer ticket applications
• Web Application Firewalls
• Any application that requires user moderation

What is Stored Cross-Site Scripting?

Stored cross-site scripting (also known as second-order or persistent XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.
If an attacker can control a script that is executed in the victim’s browser, then they can typically fully compromise that user.

The location of the stored data within the application’s response determines what type of payload is required to exploit it and might also affect the impact of the vulnerability.

Entry Points to Look Out In Hunting Stored XSS

• Parameters or other data within the URL query string and message body.
• The URL file path.
• HTTP request headers that might not be exploitable in relation to reflected XSS.
• Any out-of-band routes via which an attacker can deliver data into the application.

Steps to Reproduce

Proof of Exploitation

The file is from the attacker’s Nginx-server logs and in the file you can see that a Lahitapiola employee (notice the IP-address) has opened attachments and triggered the XSS which sent the employees cookies to the attacker’s server.

Summary

The reporter/attacker was able to perform a Blind-Stored XSS against the secure messaging system for LocalTapiola customers.

It occurs when the data provided by the attacker is saved by the server, and then permanently displayed on “normal” pages returned to other users.

Thank you very much for your time and I wish you good luck in your bug hunting.