Stored XSS (Persistent XSS)

Stored Cross-Site Scripting (Stored XSS), also known as Persistent XSS, occurs when an attacker is able to inject malicious JavaScript into a web application's persistent data, such as a database, that will later be displayed to users who visit the affected page. This type of attack is persistent because the injected script remains in the server-side storage (such as a database or file) and can affect any user who accesses the page, not just the attacker.

How Stored XSS Works

1. Injection:

   • The attacker submits malicious JavaScript or HTML code through a form or URL parameter that is stored on the server.
   • This could happen in a comment field, user profile information, forum post, or any input field that is stored in a database or other backend storage.

2. Persistence:

   • Unlike reflected XSS, which only affects a user immediately after they click a crafted link, stored XSS remains on the server. The malicious payload stays there and is delivered to users repeatedly.

3. Execution:

   • When other users load the page containing the malicious content, the JavaScript or HTML is executed within their browsers. The script runs as if it were part of the legitimate content of the website.

4. Impact:

   • The malicious script can do things like steal user cookies, hijack user sessions, manipulate page content, or perform actions on behalf of the user, such as submitting forms or redirecting the user to a phishing page.

Example of Stored XSS

Consider an online forum where users can post comments. If the forum doesn't properly sanitize input, an attacker could post a comment like this:

<script>alert('Hacked!');</script>

This comment is stored in the forum's database. Later, when other users visit the page where the comment is displayed, the browser will execute the malicious <script> tag, showing an alert box with the message "Hacked!" on the victim's browser.

If the attacker crafts a more malicious script, they could steal cookies or send requests to another user's account, performing unauthorized actions.

Steps in a Stored XSS Attack

1. Identify a Vulnerable Input Field:

   • The attacker looks for input fields where user data is stored and later reflected back on the page without proper sanitization. Common examples include user profile settings, comment sections, or any form that allows HTML or script input.

2. Inject the Malicious Script:

   • The attacker submits a payload, which could be a simple script like <script>alert('XSS');</script>, or more complex scripts designed to steal sensitive data or perform actions on behalf of other users.

3. Persistence:

   • The malicious code is stored in a database or other persistent storage. It becomes a permanent part of the application's content, potentially affecting many users who later interact with the page containing the injected script.

4. Victim Interaction:

   • When other users visit the page or load the content (such as a comment, profile, or post), the malicious script is executed in their browser, potentially leading to the theft of sensitive data, session hijacking, or other malicious actions.

Impact of Stored XSS

1. Session Hijacking:

   • By injecting a script that steals a user's session cookie, an attacker can impersonate the victim and perform actions as them, like accessing their account or making unauthorized transactions.

2. Credential Theft:

   • Malicious scripts can prompt users to enter sensitive information (e.g., usernames, passwords, credit card details) into a fake form that sends the data to the attacker.

3. Defacement:

   • Attackers can manipulate the appearance of a website, changing content or design to damage the reputation of the website or trick users.

4. Phishing:

   • Attackers can inject fake login forms, which trick users into submitting their credentials to malicious websites.

5. Spread Malware:

   • Malicious scripts can redirect users to malicious websites that exploit browser vulnerabilities or download malware.

Mitigating Stored XSS

1. Input Validation:

   • Ensure that any user-generated content is validated on both the client-side and server-side. Validate the type, length, format, and range of input. Reject input that contains potentially dangerous characters like <, >, &, and ".
   • Use allow-lists (whitelisting) for valid input values and reject anything that falls outside those acceptable inputs.

2. Output Encoding/Escaping:

   • HTML Encoding: Encode special characters before rendering them on the page. For instance, < should be rendered as <, > as >, and so on. This prevents the browser from interpreting the content as executable HTML or JavaScript.
   • JavaScript Encoding: For data embedded in JavaScript, use proper encoding methods (e.g., JSON.stringify()).
   • Attribute Encoding: When injecting user content into HTML attributes (e.g., within href, src, or alt attributes), encode special characters to prevent scripts from executing.

3. Use Content Security Policy (CSP):

   • CSP can significantly reduce the risk of XSS by controlling which domains can serve executable content, disallowing inline scripts, and preventing loading of scripts from unauthorized sources.

4. Sanitize Input:

   • Use input sanitization libraries like OWASP Java HTML Sanitizer or DOMPurify that remove malicious HTML and JavaScript content from user input before storing or displaying it.

5. HttpOnly and Secure Cookies:

   • Use the HttpOnly attribute for cookies to prevent access to cookies via JavaScript, which makes it harder for attackers to steal session cookies via XSS.
   • Set the Secure flag to ensure cookies are only sent over HTTPS.

6. Regular Security Audits:

   • Perform regular code reviews, vulnerability assessments, and penetration testing to identify and fix potential XSS vulnerabilities in your application.

7. Avoid Inline JavaScript:

   • Avoid inline JavaScript (<script>...</script> tags) within HTML pages. Use external JavaScript files with proper CSP settings to prevent the execution of injected scripts.

Example of Fixing Stored XSS

If a web application allows users to post comments and stores them in a database, the server-side code should sanitize the user input before storing it. For example:

Vulnerable (without sanitization):

<!-- Attacker posts this comment -->
<p>Nice post! <script>alert('XSS');</script></p>

Sanitized (with encoding):

<!-- Server-side sanitization or encoding -->
<p>Nice post! &lt;script&gt;alert('XSS');&lt;/script&gt;</p>

After encoding, the browser will display the raw script tags as text rather than executing them, mitigating the XSS risk.

Tools for Detecting Stored XSS

1. OWASP ZAP (Zed Attack Proxy): A penetration testing tool that helps in discovering XSS vulnerabilities, including stored XSS.
2. Burp Suite: A widely-used web vulnerability scanner that can help identify stored XSS flaws.
3. Acunetix: A web application scanner that checks for a variety of vulnerabilities, including stored XSS.