Cross Site Scripting Flaw - Revision history

Wichers: /* References */

2013-09-14T01:46:41Z

‎References

Shady: References

2013-05-12T17:07:20Z

References

Wichers at 17:32, 22 April 2010

2010-04-22T17:32:33Z

Adar Weidman: /* Related Attacks */ Add XSHM

2010-02-08T16:14:55Z

‎Related Attacks: Add XSHM

Wichers: /* How to Determine If You Are Vulnerable */

2009-09-21T20:45:53Z

‎How to Determine If You Are Vulnerable

Wichers at 20:39, 21 September 2009

2009-09-21T20:39:06Z

Jason Li: This page is linked by an external page (Application Security and Development STIG: disa.mil)

2009-04-28T20:34:22Z

This page is linked by an external page (Application Security and Development STIG: disa.mil)

KirstenS: /* References */

2009-02-21T14:49:09Z

‎References

KirstenS: /* References */

2009-02-21T14:48:24Z

‎References

KirstenS: /* How to Protect Yourself */

2009-02-21T14:46:29Z

‎How to Protect Yourself

@@ Line 63: / Line 63: @@
 ==References==
-* [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet]]
+* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
 * OWASP Guide to Building Secure Web Applications and Web Services, [[Data Validation]]
 * OWASP Testing Guide, [[Testing for Cross site scripting]]
 * The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
-* XSS Cheat Sheet: http://ha.ckers.org/xss.html
+* XSS Cheat Sheet: [[XSS Filter Evasion Cheat Sheet]] New home for the old: ha.ckers.org/xss.html site.
 * CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
 * CERT "Understanding Malicious Content Mitigation" http://www.cert.org/tech_tips/malicious_code_mitigation.html
@@ Line 74: / Line 74: @@
 * XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com
 * Cross-Site Scripting Security Exposure Executive Summary: http://technet.microsoft.com/en-us/library/cc750326.aspx
-* Have Your Cake and Eat it Too (.NET validation) https://www.owasp.org/index.php/Have_Your_Cake_and_Eat_It_Too
+* [[Have Your Cake and Eat It Too]] (.NET request validation)
 [[Category:FIXME|add links

@@ Line 73: / Line 73: @@
 * [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation with Stinger)]]
 * XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com
 [[Category:FIXME|add links

@@ Line 88: / Line 88: @@
 [[Category:OWASP ASDR Project]]
 [[Category:Vulnerability]]
 [[Category:Externally Linked Page]]

@@ Line 47: / Line 47: @@
 ==Related [[Attacks]]==
 * [[Cross-site Scripting (XSS)]]
 <!--
 ==Related [[Vulnerabilities]]==

@@ Line 18: / Line 18: @@
 ===How to Determine If You Are Vulnerable===
-There are three known types of cross site scripting: reflected, stored, and DOM injection. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:
+There are three known types of cross site scripting: [[Cross-site_Scripting_(XSS)#Reflected_XSS_Attacks | reflected]], [[Cross-site_Scripting_(XSS)#Stored_XSS_Attacks | stored]], and [[DOM_Based_XSS | DOM injection]]. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:
 echo $_REQUEST['userinput'];

@@ Line 6: / Line 6: @@
 ==Description==
-Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (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 in the output it generates without validating or encoding it.
+Cross site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into otherwise benign and trusted web sites. Cross site scripting flaws are the most prevalent flaw in web applications today. Cross site scripting 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 in the output it generates without validating or encoding it.
 Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request is less suspicious looking to the user. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols. For this reason, attempting to “filter out” these scripts is not likely to succeed. Instead we recommend validating input against a rigorous positive specification of what is expected. XSS attacks usually come in the form of embedded JavaScript. However, any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more.
@@ Line 18: / Line 18: @@
 ===How to Determine If You Are Vulnerable===
-XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.
+There are three known types of cross site scripting: reflected, stored, and DOM injection. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:
 ==Risk Factors==
 TBD
+-->
 ==Examples==
+* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206
-TBD
+* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966
 ==Related [[Attacks]]==
 * [[Cross-site Scripting (XSS)]]
+<!--
 ==Related [[Vulnerabilities]]==
 * [[Vulnerability 1]]
 * [[Vulnerabiltiy 2]]
 ==Related [[Controls]]==
 * [[Control 1]]
 * [[Control 2]]
 ==Related [[Technical Impacts]]==
 * [[Technical Impact 1]]
 * [[Technical Impact 2]]
+-->
 ==References==
 * The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
 * XSS Cheat Sheet: http://ha.ckers.org/xss.html
 * CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
-* CERT “Understanding Malicious Content Mitigation” http://www.cert.org/tech_tips/malicious_code_mitigation.html
+* CERT "Understanding Malicious Content Mitigation" http://www.cert.org/tech_tips/malicious_code_mitigation.html
 * Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html
 * [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation with Stinger)]]
 * XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com
@@ Line 66: / Line 77: @@
 * Cross-Site Scripting Security Exposure Executive Summary: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/ExSumCS.asp
 * Have Your Cake and Eat it Too (.NET validation) http://www.owasp.org/columns/jpoteet/jpoteet2
 ]]
 [[Category:FIXME|add links
+<nowiki>[[Category:Input Validation Vulnerability]]</nowiki>
-In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
+]]
 __NOTOC__
 [[Category:OWASP ASDR Project]]

← Older revision		Revision as of 20:34, 28 April 2009
Line 102:		Line 102:
	[[Category:OWASP Top Ten Project]]		[[Category:OWASP Top Ten Project]]
	[[Category:Vulnerability]]		[[Category:Vulnerability]]
		+	[[Category:Externally Linked Page]]

← Older revision		Revision as of 14:46, 21 February 2009
Line 20:		Line 20:
	XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.		XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

−	~~===How to Protect Yourself===~~
−	The best way to protect a web application from XSS attacks is ensure that your application performs validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed. The validation should not attempt to identify active content and remove, filter, or sanitize it. There are too many types of active content and too many ways of encoding it to get around filters for such content. We strongly recommend a ‘positive’ security policy that specifies what is allowed. ‘Negative’ or attack signature based policies are difficult to maintain and are likely to be incomplete.

−	Encoding user supplied output can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an executable form. Applications can gain significant protection from javascript based attacks by converting the following characters in all generated output to the appropriate HTML entity encoding:
−
−	~~{\| border="1"~~
−	~~\|+ HTML Entities~~
−	~~! Character !! Encoding~~
−	\|-
−	~~\| < \|\| &lt; or &#60;~~
−	\|-
−	~~\| > \|\| &gt; or &#62;~~
−	\|-
−	~~\| & \|\| &amp; or &#38;~~
−	\|-
−	~~\| " \|\| &quot; or &#34;~~
−	\|-
−	~~\| ' \|\| &apos; or &#39;~~
−	\|-
−	~~\| ( \|\| &#40;~~
−	\|-
−	~~\| ) \|\| &#41;~~
−	\|-
−	~~\| # \|\| &#35;~~
−	\|-
−	~~\| % \|\| &#37;~~
−	\|-
−	~~\| ; \|\| &#59;~~
−	\|-
−	~~\| + \|\| &#43;~~
−	\|-
−	~~\| - \|\| &#45;~~
−	\|}
−
−	This list is an example of dangerous characters. Do not be lured into thinking that output encoding via blacklisting is sufficient for XSS protection. The HTMLEntityEncode function at [http://www.owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java] is a whitelist HTML Entity Output Encoding mechanism for Java.
−
−	Also, it's crucial that you turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via Javascript even when document.cookie is disabled or not supported on the client. This attack is mounted when a user post a malicious script to a forum so when another user clicks the link, an asynchronous HTTP Trace call is triggered which collects the users cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. This is easily mitigated by removing support for HTTP TRACE on all webservers.
−
−	The [[:Category:OWASP Filters Project\|OWASP Filters project]] is producing reusable components in several languages to help prevent many forms of parameter tampering, including the injection of XSS attacks. In addition, the [[:Category:OWASP WebGoat Project\|OWASP WebGoat Project]] training program has lessons on Cross-Site Scripting and data encoding.

	==Risk Factors==		==Risk Factors==