🎭 XSS Exposed: The Good, the Bad, and the Ugly! 🧑‍💻
Tags: security, webdev, javascript, cybersecurity
Published: 2024-04-24 13:31:26





![hacking in progress](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6qknfc7kpr4oosqstihy.gif)

## Stored XSS (Persistent XSS)

**Mechanism**: In Stored XSS, the malicious script is permanently stored on target resources, such as in a database, message forum, visitor log, comment field, or other locations where data is stored. Whenever the stored data is viewed, the malicious script is sent to the user's browser and executed.

**Example**: Suppose a user submits a comment on a blog that includes a script tag `(<script>alert('XSS')</script>)`. The comment is stored in the website's database. Every time anyone views that comment, the script runs in their browser.

**Impact**: This type affects multiple users—anyone who accesses the stored data—and can remain a problem until the malicious data is removed from the database or sanitized.

## Reflected XSS

**Mechanism**: Reflected XSS occurs when user input is immediately returned by web applications without proper input validation and escaping, which causes the browser to execute it as part of the HTML. The malicious content is not stored by the server but reflected off the web application to the user's browser in real-time.

**Example**: If a user clicks on a malicious link like `http://example.com/page?input=<script>alert('XSS')</script>`, the web server might include the script directly in the response. The script executes when the page loads.

**Impact**: The attack is usually a one-time occurrence for each click or visit, and often requires some form of social engineering to make the victim visit a URL with the malicious script.

## DOM XSS

**Mechanism**: DOM XSS attacks occur when a web application's client-side scripts write data provided by the user to the Document Object Model (DOM) without proper sanitization, allowing an attacker to run malicious scripts in the user's browser. The malicious payload is typically not processed or stored by the server but is triggered due to improper handling of the DOM by JavaScript running in the browser.

**Example**: A website uses JavaScript to take the user's input from the URL parameter and directly updates the DOM with this `input`, such as using `innerHTML` to display it. If the input includes a script, it will be executed by the browser.

**Impact**: Like Reflected XSS, DOM XSS exploits the environment in the victim’s browser and does not necessarily involve the server. It relies on the way JavaScript manipulates the DOM and user inputs.

## Key Differences Summarized:

- **Source and Location of Payload**:
      -    **Stored XSS**: The payload is stored on the server (e.g., database) and affects multiple users.
      -  **Reflected XSS**: The payload is reflected off the server in real-time and typically affects users who click a malicious link.
      -  **DOM XSS**: The payload manipulates the DOM in real-time and does not involve the server; it is purely a client-side issue.

- **Persistence**:
    - **Stored XSS**: Persistent.
    - **Reflected and DOM XSS**: Non-persistent; the script runs during a single interaction.

- **Trigger Method**:
    - **Stored XSS**: Triggered whenever the stored data is loaded.
    - **Reflected XSS**: Triggered by user interactions such as clicking a malicious link.
    - **DOM XSS**: Triggered by DOM manipulation vulnerabilities in the client-side code.

happy hacking....