Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| modul:m183:learningunits:lu10:lu10a [2025/12/27 19:07] – angelegt dgaravaldi | modul:m183:learningunits:lu10:lu10a [2025/12/27 21:02] (aktuell) – dgaravaldi | ||
|---|---|---|---|
| Zeile 5: | Zeile 5: | ||
| A successful XSS attack can cause serious damage — including compromised user accounts, activation of Trojan code, manipulation of page content to trick users into sharing sensitive data, or exposure of session cookies that allow attackers to impersonate valid users. | A successful XSS attack can cause serious damage — including compromised user accounts, activation of Trojan code, manipulation of page content to trick users into sharing sensitive data, or exposure of session cookies that allow attackers to impersonate valid users. | ||
| - | + | \\ | |
| - | ===== Types of XSS Attacks | + | ==== Types of XSS Attacks ==== |
| There are **two major types** of cross-site scripting attacks commonly discussed: | There are **two major types** of cross-site scripting attacks commonly discussed: | ||
| Zeile 13: | Zeile 13: | ||
| * **Reflected XSS (Non-Persistent)** – A malicious script is embedded in a URL or request, then reflected off the web server back to the user’s browser when the link is visited. | * **Reflected XSS (Non-Persistent)** – A malicious script is embedded in a URL or request, then reflected off the web server back to the user’s browser when the link is visited. | ||
| - | + | \\ | |
| - | + | ==== What is Stored Cross-Site Scripting ==== | |
| - | ===== What is Stored Cross-Site Scripting | + | |
| To execute a **stored XSS attack**, the attacker must find a vulnerability in a web application where user input is stored without proper validation or escaping. A common example is when a comment field or form accepts HTML input and embeds it directly into pages viewed by other users. | To execute a **stored XSS attack**, the attacker must find a vulnerability in a web application where user input is stored without proper validation or escaping. A common example is when a comment field or form accepts HTML input and embeds it directly into pages viewed by other users. | ||
| - | |||
| - | {{stored_xss_example.png? | ||
| **Example**: | **Example**: | ||
| + | \\ | ||
| + | ==== Stored XSS Attack — Step by Step ==== | ||
| + | {{: | ||
| - | ===== Stored XSS Attack — Step by Step ===== | + | - The attacker discovers a page with an input field that allows HTML. |
| - | 1. The attacker discovers a page with an input field that allows HTML. | + | |
| - | 2. They insert malicious JavaScript code into that field. | + | |
| - | 3. The application stores and later serves that code as part of normal content. | + | |
| - | 4. When other users visit the page, their browser executes the attack script. | + | |
| - | ===== How Stored XSS Endangers Users ===== | + | \\ |
| + | ==== How Stored XSS Endangers Users ==== | ||
| Stored XSS is especially dangerous because: | Stored XSS is especially dangerous because: | ||
| - | * It can impact **all users** who view the infected page. | + | |
| - | * Attacker-controlled scripts can steal session credentials or redirect users to phishing sites. | + | * Attacker-controlled scripts can steal session credentials or redirect users to phishing sites. |
| - | * Malicious payloads can embed external JavaScript that reports user data back to the attacker. | + | * Malicious payloads can embed external JavaScript that reports user data back to the attacker. |
| + | \\ | ||
| + | ==== Related Topics ==== | ||
| + | [1]: https:// | ||
| - | ===== Related Topics ===== | + | [2]: https:// |
| - | [1]: https:// | + | |
| - | [2]: https:// | + | |
| - | [3]: https:// | + | |