Stored Cross-Site-Scripting(XSS): A Beginner’s Guide

Sounds confusing but simple as it is!

Stored XSS occurs when malicious input is stored by a web application (think of it as being saved in a database) and later served to other users.

When an attacker injects malicious code in an input field of the website, which commonly include comment box and forums, it is known as Stored Cross-Site-Scripting.

When another user visits the affected page, the stored script can execute in their browser.

Okay, that was a long explanation. Let's break it down using Portswigger lab.

Step 1: An attacker injects a payload into a comment section of a website.

Step 2: You visit that website.

Step 3: The stored payload executes in your browser.

Every time you visit the website, the payload can execute again. That's why Stored XSS is also known as Persistent XSS.

Why is Stored XSS dangerous?

The reason it is dangerous is because it can impact multiple users without the attacker having to interact with each user individually.

Imagine you are visiting a website you regularly use. You open a page, and suddenly something unexpected happens.

You could become a victim of a Stored XSS attack without ever knowing that someone had injected malicious content into the website.

But How is this different from Reflected XSS?

In Reflected XSS, the malicious input is usually included in a request and immediately reflected back in the website's response.

Think of it as:

Attacker -> Request -> Website -> Victim

However, in Stored XSS, the malicious input is first stored by the application and is later served to users who visit the affected page.

Think of it as:

Attacker -> Website stores input -> Victim visits page -> Script executes

That's the main difference: Reflected XSS is not stored, while Stored XSS is persistent.