Cross-Site Scripting (XSS) - Revision history

KKerbl: /* Client XSS */

2024-12-21T14:02:36Z

Client XSS

← Older revision		Revision as of 14:02, 21 December 2024
Line 25:		Line 25:

	=== Client XSS ===		=== Client XSS ===
	Client XSS ~~occurs~~ when untrusted data is used to ~~update~~ the DOM ~~with an~~ unsafe JavaScript ~~method. This is where DOM-based would fit in~~.		Client XSS happens when untrusted data is used directly to manipulate the DOM (Document Object Model) via unsafe JavaScript methods on the client side.

	== XSS attack consequences ==		== XSS attack consequences ==

KKerbl: /* Server XSS */

2024-12-21T14:02:02Z

Server XSS

← Older revision		Revision as of 14:02, 21 December 2024
Line 22:		Line 22:

	=== Server XSS ===		=== Server XSS ===
	Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location. Both Reflected Server XSS and Stored Server XSS count as Server XSS.		Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location (e.g., database). Both Reflected Server XSS and Stored Server XSS count as Server XSS.

	=== Client XSS ===		=== Client XSS ===

KKerbl at 13:58, 21 December 2024

2024-12-21T13:58:33Z

@@ Line 69: / Line 69: @@
 '''Security Audits and Code Reviews''': Conducting regular security audits and code reviews to help identify and remediate potential vulnerabilities. Third-party security assessments can provide an independent assessment of your application's security posture.
@@ Line 150: / Line 119: @@
 These files and scripts form the backbone of the XSS demonstrations. Ensure they are set up correctly and tested in a controlled environment to replicate the attacks.
 == References ==

KKerbl at 13:56, 21 December 2024

2024-12-21T13:56:55Z

@@ Line 26: / Line 26: @@
 === Client XSS ===
 Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.
 == XSS attack consequences ==
@@ Line 150: / Line 103: @@
 These demonstrations illustrate the risks of XSS attacks and their potential to steal sensitive data like cookies. Understanding these methods is crucial for identifying and mitigating vulnerabilities. Always practice responsibly in controlled environments like OWASP Mutillidae II to promote safer web applications.
 == References ==

KKerbl at 13:56, 21 December 2024

2024-12-21T13:56:14Z

@@ Line 73: / Line 73: @@
 These files and scripts form the backbone of the XSS demonstrations. Ensure they are set up correctly and tested in a controlled environment to replicate the attacks.
 == XSS attack consequences ==
@@ Line 149: / Line 116: @@
 '''Security Audits and Code Reviews''': Conducting regular security audits and code reviews to help identify and remediate potential vulnerabilities. Third-party security assessments can provide an independent assessment of your application's security posture.
 == References ==

KKerbl: /* References */

2024-12-21T13:53:28Z

References

← Older revision		Revision as of 13:53, 21 December 2024
Line 152:		Line 152:
	== References ==		== References ==

			* https://owasp.org/www-community/Types_of_Cross-Site_Scripting
	* https://owasp.org/www-community/attacks/xss/		* https://owasp.org/www-community/attacks/xss/
	* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html		* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html

KKerbl: /* Types */

2024-12-21T13:53:06Z

Types

← Older revision		Revision as of 13:53, 21 December 2024
Line 20:		Line 20:
	=== DOM Based XSS (Type 0) ===		=== DOM Based XSS (Type 0) ===
	DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.		DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

			=== Server XSS ===
			Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location. Both Reflected Server XSS and Stored Server XSS count as Server XSS.

			=== Client XSS ===
			Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript method. This is where DOM-based would fit in.

	==Demonstrations==		==Demonstrations==

KKerbl at 13:47, 21 December 2024

2024-12-21T13:47:14Z

← Older revision		Revision as of 13:47, 21 December 2024
Line 2:		Line 2:
	== Cross-Site Scripting (XSS) ==		== Cross-Site Scripting (XSS) ==

	[[Image:xss_diagram.png\|300px\|thumb\| The operational principle of Cross-Site Scripting (XSS)]]		[[Image:xss_diagram.png\|300px\|thumb\| The operational principle of stored Cross-Site Scripting (XSS)]]


Line 19:		Line 19:

	=== DOM Based XSS (Type 0) ===		=== DOM Based XSS (Type 0) ===
	DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is ~~like reelected XSS~~ most of the time in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.		DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

	==Demonstrations==		==Demonstrations==

KKerbl: /* Types */

2024-12-21T13:41:23Z

Types

← Older revision		Revision as of 13:41, 21 December 2024
Line 12:		Line 12:


	=== Reflected XSS(Type I) ===		=== Reflected XSS (Type I) ===
	Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc.		Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc.

	=== Stored XSS(Type II) ===		=== Stored XSS (Type II) ===
	Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.		Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.

	=== DOM Based XSS(Type 0) ===		=== DOM Based XSS (Type 0) ===
	DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is like reelected XSS most of the time in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.		DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is like reelected XSS most of the time in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

KKerbl: /* Types */

2024-12-21T13:41:06Z

Types

← Older revision		Revision as of 13:41, 21 December 2024
Line 8:		Line 8:

	== Types ==		== Types ==
	There are two ways to classify XSS attacks. Up until 2012 ~~the~~ types DOM-based (Type 0), ~~stored~~/persistent (Type I) and ~~reflected~~/~~non-~~persistent (Type II) ~~were used~~. However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.		There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.
	[[File:Server-XSS_vs_Client-XSS_Chart.png\|200px\|thumb]]		[[File:Server-XSS_vs_Client-XSS_Chart.png\|200px\|thumb]]

	=== Stored (Type I) ===
			=== Reflected XSS(Type I) ===
			Reflected XSS or non-persistent XSS can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc.

			=== Stored XSS(Type II) ===
	Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.		Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.

	~~=== Reflected (Type II) ===~~		=== DOM Based XSS(Type 0) ===
	Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.		DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is like reelected XSS most of the time in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

	=== DOM Based (Type 0) ===
	DOM-based Cross-Site Scripting ~~(XSS) is a type of XSS attack that~~ occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks ~~can occur~~ when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is ~~then sent to~~ a ~~user's browser, where it is executed~~. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

	==Demonstrations==		==Demonstrations==