Top 10 2007-Cross Site Scripting - Revision history

Wichers at 02:40, 19 April 2010

2010-04-19T02:40:36Z

KirstenS: /* Verifying Security */

2009-03-05T12:57:10Z

‎Verifying Security

KirstenS: /* Vulnerability */

2009-01-27T01:38:45Z

‎Vulnerability

KirstenS: /* References */

2008-09-18T12:42:12Z

‎References

KirstenS: /* References */

2008-09-18T12:41:48Z

‎References

KirstenS: /* References */

2008-09-18T12:41:12Z

‎References

KirstenS: /* References */

2008-09-18T12:40:08Z

‎References

KirstenS: /* References */

2008-09-18T12:39:02Z

‎References

KirstenS at 12:37, 18 September 2008

2008-09-18T12:37:10Z

KirstenS at 18:58, 12 August 2008

2008-08-12T18:58:29Z

← Older revision		Revision as of 02:40, 19 April 2010
Line 75:		Line 75:

	{{Top_10_2007:BottomTemplate\|usenext=NextLink\|next=-Injection Flaws\|useprev=PrevLink\|prev=-Methodology\|usemain=MainLink\|main=}}		{{Top_10_2007:BottomTemplate\|usenext=NextLink\|next=-Injection Flaws\|useprev=PrevLink\|prev=-Methodology\|usemain=MainLink\|main=}}
		+
		+	[[Category:OWASP Top Ten Project]]

@@ Line 27: / Line 27: @@
 The goal is to verify that all the parameters in the application are validated and/or encoded before being included in HTML pages.
-'''Automated approaches: '''Automated penetration testing tools are capable of detecting reflected XSS via parameter injection, but often fail to find persistent XSS, particularly if the output of the injected XSS vector is prevented via authorization checks (such as if a user inputs hostile data which only admins can see sometime later). Automated source code scanning tools can find weak or dangerous APIs but usually cannot determine if validation or encoding has taken place, which may result in false positives. Neither tool type is able to find DOM based XSS, which means that Ajax based applications will usually be at risk if only automated testing takes place.
+'''Automated approaches: '''Automated penetration testing tools are capable of detecting reflected XSS via parameter injection, but often fail to find persistent XSS, particularly if the output of the injected XSS vector is prevented via authorization checks (such as if a user inputs hostile data which only admins can see sometime later). Automated source code scanning tools can find weak or dangerous APIs but usually cannot determine if validation or encoding has taken place, which may result in false positives. Neither tool type is able to find DOM based XSS, which means that Ajax based applications will usually be at risk if only automated testing takes place.[[category:FIXME|KSitnick-Stored XSS is called persistent XSS here; we probably should use the same name consistently, or at least mention above that they're the same thing (if that's true)]]
 '''Manual approaches: '''If a centralized validation and encoding mechanism is used, the most efficient way to verify security is to check the code. If a distributed implementation is used, then the verification will be considerably more time-consuming. Testing is time-consuming because the attack surface of most applications is so large.

@@ Line 21: / Line 21: @@
 Attacks are usually implemented in JavaScript, which is a powerful scripting language. Using JavaScript allows attackers to manipulate any aspect of the rendered page, including adding new elements (such as adding a login tile which forwards credentials to a hostile site), manipulating any aspect of the internal DOM tree, and deleting or changing the way the page looks and feels. JavaScript allows the use of XmlHttpRequest, which is typically used by sites using AJAX technologies, even if victim site does not use AJAX today.
-Using XmlHttpRequest, it is sometimes possible to get around a browser’s same source origination policy - thus forwarding victim data to hostile sites, and to create complex worms and malicious zombies that last as long as the browser stays open. AJAX attacks do not have to be visible or require user interaction to perform dangerous [http://www.owasp.org/index.php/Top_10_2007-A5 cross site request forgery (CSRF) attacks].
+Using XmlHttpRequest, it is sometimes possible to get around a browser’s same source origination policy - thus forwarding victim data to hostile sites, and to create complex worms and malicious zombies that last as long as the browser stays open. AJAX attacks do not have to be visible or require user interaction to perform dangerous [[Top_10_2007-A5|cross site request forgery (CSRF) attacks]].
 == Verifying Security ==

@@ Line 68: / Line 68: @@
 *OWASP [[:Category:OWASP_Stinger_Project|Stinger Project]] (A Java EE validation filter)
 *OWASP [[OWASP_PHP_Filters|PHP Filter Project]]
-*OWASP [[:Category:OWASP_Encoding_Project|Encoding Project]] - [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project http://www.owasp.org/index.php/Category:OWASP_Encoding_Project]
+*OWASP [[:Category:OWASP_Encoding_Project|Encoding Project]]
 *RSnake, XSS Cheat Sheet, [http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html ]
 *Klein, A., DOM Based Cross Site Scripting, [http://www.webappsec.org/projects/articles/071105.shtml http://www.webappsec.org/projects/articles/071105.shtml ]

@@ Line 68: / Line 68: @@
 *OWASP [[:Category:OWASP_Stinger_Project|Stinger Project]] (A Java EE validation filter)
 *OWASP [[OWASP_PHP_Filters|PHP Filter Project]]
-*OWASP Encoding Project - [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project http://www.owasp.org/index.php/Category:OWASP_Encoding_Project]
+*OWASP [[:Category:OWASP_Encoding_Project|Encoding Project]] - [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project http://www.owasp.org/index.php/Category:OWASP_Encoding_Project]
 *RSnake, XSS Cheat Sheet, [http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html ]
 *Klein, A., DOM Based Cross Site Scripting, [http://www.webappsec.org/projects/articles/071105.shtml http://www.webappsec.org/projects/articles/071105.shtml ]

@@ Line 66: / Line 66: @@
 *OWASP – [[Cross-site Scripting (XSS)]]
 *OWASP – [[Testing for Cross site scripting]]
-*OWASP [[:Category:OWASP_Stinger_Project|Stinger Project]] (A Java EE validation filter) – [http://www.owasp.org/index.php/Category:OWASP_Stinger_Project http://www.owasp.org/index.php/Category:OWASP_Stinger_Project]
+*OWASP [[:Category:OWASP_Stinger_Project|Stinger Project]] (A Java EE validation filter)
-*OWASP PHP Filter Project - [http://www.owasp.org/index.php/OWASP_PHP_Filters http://www.owasp.org/index.php/OWASP_PHP_Filters]
+*OWASP [[OWASP_PHP_Filters|PHP Filter Project]]
 *OWASP Encoding Project - [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project http://www.owasp.org/index.php/Category:OWASP_Encoding_Project]
 *RSnake, XSS Cheat Sheet, [http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html ]

@@ Line 64: / Line 64: @@
 *CWE: CWE-79, Cross-Site scripting (XSS)
 *WASC Threat Classification: [http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml]
-*OWASP – Cross site scripting, [http://www.owasp.org/index.php/Cross_Site_Scripting http://www.owasp.org/index.php/Cross_Site_Scripting ]
+*OWASP – [[Cross-site Scripting (XSS)]]
-*OWASP – Testing for XSS, [http://www.owasp.org/index.php/Testing_for_Cross_site_scripting http://www.owasp.org/index.php/Testing_for_Cross_site_scripting]
+*OWASP – [[Testing for Cross site scripting]], [http://www.owasp.org/index.php/Testing_for_Cross_site_scripting http://www.owasp.org/index.php/Testing_for_Cross_site_scripting]
 *OWASP Stinger Project (A Java EE validation filter) – [http://www.owasp.org/index.php/Category:OWASP_Stinger_Project http://www.owasp.org/index.php/Category:OWASP_Stinger_Project]
 *OWASP PHP Filter Project - [http://www.owasp.org/index.php/OWASP_PHP_Filters http://www.owasp.org/index.php/OWASP_PHP_Filters]

@@ Line 1: / Line 1: @@
 {{Top_10_2007:TopTemplate|usenext=NextLink|next=-Injection Flaws|useprev=PrevLink|prev=-Methodology|usemain=MainLink|main=}}
-[[Cross-site scripting]], better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content.
+[[Cross-site Scripting (XSS)|Cross-site scripting]], better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content.
 XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface web sites, insert hostile content, conduct phishing attacks, and take over the user’s browser using scripting malware. The malicious script is usually JavaScript, but any scripting language supported by the victim’s browser is a potential target for this attack.