User:Mihara - Revision history

Mihara: Blanked the page

2017-04-24T11:27:02Z

Blanked the page

← Older revision		Revision as of 14:27, 24 April 2017
Line 1:		Line 1:

	~~= Cross-Site Scripting (XSS) attacks =~~

	Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.


	~~== Attack Vectors ==~~

	~~XSS attacks can be categorised into 3 types.~~

	~~=== Persistent XSS (Stored XSS) ===~~

	The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
	When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

	~~=== Non-Persistent XSS (Reflected XSS) ===~~
	By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

	~~=== DOM-Based XSS ===~~
	DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.


	~~== XSS vulnerability ==~~

	XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

	~~== Prevention ==~~
	Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.


	~~= Other Details =~~
	~~Author: Masaki Ihara <br/>~~
	~~Curriculum: Cyber Security Engineering <br/>~~
	~~Group: C11 <br/>~~
	~~Date created: April 24, 2017 <br/>~~
	~~Last modification: April 24, 2017 <br/>~~

	~~= References =~~

	~~[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf Cross Site Scripting Attacks Xss Exploits and Defense]~~

	~~[https://wiki.itcollege.ee/index.php/Auditd acunetix:cross-site-scripting]~~

Mihara: /* Other Details */

2017-04-23T21:12:25Z

Other Details

← Older revision		Revision as of 00:12, 24 April 2017
Line 30:		Line 30:

	= Other Details =		= Other Details =
	Author: Masaki Ihara		Author: Masaki Ihara <br/>
	Curriculum: Cyber Security Engineering		Curriculum: Cyber Security Engineering <br/>
	Group: C11		Group: C11 <br/>
	Date created: April 24, 2017		Date created: April 24, 2017 <br/>
	Last modification: April 24, 2017		Last modification: April 24, 2017 <br/>

	= References =		= References =

Mihara: /* References */

2017-04-23T21:11:28Z

References

← Older revision		Revision as of 00:11, 24 April 2017
Line 38:		Line 38:
	= References =		= References =

	[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf ~~XSS~~ Attacks]		[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf Cross Site Scripting Attacks Xss Exploits and Defense]

			[https://wiki.itcollege.ee/index.php/Auditd acunetix:cross-site-scripting]

Mihara: /* Cross-Site Scripting (XSS) attacks */

2017-04-23T21:07:31Z

Cross-Site Scripting (XSS) attacks

← Older revision		Revision as of 00:07, 24 April 2017
Line 29:		Line 29:


	== Other Details ==		= Other Details =
	Author: Masaki Ihara		Author: Masaki Ihara
	Curriculum: Cyber Security Engineering		Curriculum: Cyber Security Engineering
Line 35:		Line 35:
	Date created: April 24, 2017		Date created: April 24, 2017
	Last modification: April 24, 2017		Last modification: April 24, 2017

			= References =

			[https://doc.lagout.org/security/Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf XSS Attacks]

Mihara at 21:03, 23 April 2017

2017-04-23T21:03:15Z

← Older revision		Revision as of 00:03, 24 April 2017
Line 1:		Line 1:

	== Cross-Site Scripting (XSS) attacks ==		= Cross-Site Scripting (XSS) attacks =

	Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.		Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
Line 27:		Line 27:
	== Prevention ==		== Prevention ==
	Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.		Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.


			== Other Details ==
			Author: Masaki Ihara
			Curriculum: Cyber Security Engineering
			Group: C11
			Date created: April 24, 2017
			Last modification: April 24, 2017

Mihara at 20:59, 23 April 2017

2017-04-23T20:59:05Z

← Older revision		Revision as of 23:59, 23 April 2017
Line 24:		Line 24:

	XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.		XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.

			== Prevention ==
			Although it is said that preventing XSS attacks for 100% sure is not feasible as there is always weird ways to bypass otherwise override security implementations, basic input & output filtering should prevent the majority of attack attempts. Since the most common XSS attacks works on the security holes in HTTP query parameters or HTML form submission, it is necessary to properly filter out unexpected user data input & output by whitelisting the data types. The sanitation should not overlook encoded format of HTML as well. Encoding input and output is also effectively helps to prevent XSS attacks.

Mihara: XSS Attack Vectors

2017-04-23T20:56:00Z

XSS Attack Vectors

New page

== Cross-Site Scripting (XSS) attacks ==

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

== Attack Vectors ==

XSS attacks can be categorised into 3 types.

=== Persistent XSS (Stored XSS) ===

The most devastating variant of XSS is Persistent XSS also known as Stored XSS. Persistent XSS attacks involves an attacker injecting a malicious payload that is permanently stored (thus called persistent) on the target application such as within a database. The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page. This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

=== Non-Persistent XSS (Reflected XSS) ===
By far most common type is Non-Persistent XSS also know as Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

=== DOM-Based XSS ===
DOM-based XSS is an unique and advanced form of XSS attack used very similarly to Non-Persistent XSS. This is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM. Also since the payload is embedded into DOM element, usually users cannot see the payload on the response unless user investigate the DOM element.

== XSS vulnerability ==

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. The vulnerabilities exist due to several facts from very basic coding errors by web developers to environmental issues such as the browser itself is not secure by design; it was created to merely make requests and process the results. Although there can be many issues which allow XSS attacks to be performed, improper data input & output management is the most likely the biggest issue on the web pages.