Mihara: Blanked the page

2017-04-24T11:26:19Z

Blanked the page

← Older revision		Revision as of 14:26, 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: Created page with " = 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 attack..."

2017-04-24T11:18:35Z

Created page with " = 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 attack..."

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.

== 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 
Curriculum: Cyber Security Engineering 
Group: C11 
Date created: April 24, 2017 
Last modification: April 24, 2017 

= 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]

XSS Attack Vectors - Revision history

Mihara: Blanked the page

Mihara: Created page with " = 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 attack..."