Top 10 2010-Test - Revision history

Wichers at 18:22, 2 July 2010

2010-07-02T18:22:52Z

Neil Smithline at 00:11, 29 April 2010

2010-04-29T00:11:42Z

Neil Smithline at 00:07, 29 April 2010

2010-04-29T00:07:15Z

Neil Smithline at 23:24, 28 April 2010

2010-04-28T23:24:40Z

Neil Smithline at 22:51, 28 April 2010

2010-04-28T22:51:15Z

Neil Smithline at 21:51, 28 April 2010

2010-04-28T21:51:22Z

Neil Smithline at 21:09, 28 April 2010

2010-04-28T21:09:28Z

Neil Smithline at 21:07, 28 April 2010

2010-04-28T21:07:47Z

Neil Smithline at 19:43, 28 April 2010

2010-04-28T19:43:25Z

Neil Smithline at 02:37, 26 April 2010

2010-04-26T02:37:03Z

← Older revision		Revision as of 18:22, 2 July 2010
Line 59:		Line 59:
	* [http://ha.ckers.org/xss.html RSnake's XSS Attack Cheat Sheet]		* [http://ha.ckers.org/xss.html RSnake's XSS Attack Cheat Sheet]
	{{Top_10_2010:BottomAdvancedTemplate\|type=box\|useprev=2010PrevLink\|usenext=2010NextLink\|prev=A1-Injection\|next=A3-Broken Authentication and Session Management}}		{{Top_10_2010:BottomAdvancedTemplate\|type=box\|useprev=2010PrevLink\|usenext=2010NextLink\|prev=A1-Injection\|next=A3-Broken Authentication and Session Management}}
−	~~[[Category:OWASP Top Ten Project]]~~

@@ Line 28: / Line 28: @@
 |}
 </center>
-{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=1|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=1|risk=1}}
 You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed.
@@ Line 34: / Line 34: @@
 Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
-{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=2|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=2|risk=1}}
 Preventing XSS requires keeping untrusted data separate from active browser content.
 # The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them. See the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]] for more information about data escaping techniques.
 # Positive or “whitelist” input validation with appropriate canonicalization and decoding is also recommended as it helps protect against XSS, but is <u>not a complete defense</u> as many applications require special characters in their input. Such validation should, as much as possible, decode any encoded input, and then validate the length, characters, format, and any business rules on that data before accepting the input.
-{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=3|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=3|risk=1}}
 The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
 The attacker modifies the ‘CC’ parameter in their browser to:
@@ Line 45: / Line 45: @@
 Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[Top_10_2010-A5 | A5 for info on CSRF]].
-{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=4|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=4|risk=1}}
 {{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 * [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]]

@@ Line 28: / Line 28: @@
 |}
 </center>
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=1|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=1|risk=1}}
 You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed.
@@ Line 34: / Line 34: @@
 Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=2|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=2|risk=1}}
 Preventing XSS requires keeping untrusted data separate from active browser content.
 # The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them. See the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]] for more information about data escaping techniques.
 # Positive or “whitelist” input validation with appropriate canonicalization and decoding is also recommended as it helps protect against XSS, but is <u>not a complete defense</u> as many applications require special characters in their input. Such validation should, as much as possible, decode any encoded input, and then validate the length, characters, format, and any business rules on that data before accepting the input.
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=3|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=3|risk=1}}
 The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
 The attacker modifies the ‘CC’ parameter in their browser to:
@@ Line 45: / Line 45: @@
 Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[Top_10_2010-A5 | A5 for info on CSRF]].
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=4|risk=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=default|number=4|risk=1}}
 {{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 * [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]]

@@ Line 28: / Line 28: @@
 |}
 </center>
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=1}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=1|risk=1}}
 You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed.
@@ Line 34: / Line 34: @@
 Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=2}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=2|risk=1}}
 Preventing XSS requires keeping untrusted data separate from active browser content.
 # The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them. See the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]] for more information about data escaping techniques.
 # Positive or “whitelist” input validation with appropriate canonicalization and decoding is also recommended as it helps protect against XSS, but is <u>not a complete defense</u> as many applications require special characters in their input. Such validation should, as much as possible, decode any encoded input, and then validate the length, characters, format, and any business rules on that data before accepting the input.
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=3}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=3|risk=1}}
 The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
 The attacker modifies the ‘CC’ parameter in their browser to:
@@ Line 45: / Line 45: @@
 Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[Top_10_2010-A5 | A5 for info on CSRF]].
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=4}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=4|risk=1}}
 {{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 * [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]]

@@ Line 34: / Line 34: @@
 Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
-{{Top_10_2010:SubsectionAdvancedTemplate|type=box2|number=2}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type=box|number=2}}
 Preventing XSS requires keeping untrusted data separate from active browser content.
 # The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them. See the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]] for more information about data escaping techniques.

@@ Line 58: / Line 58: @@
 * [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]
 * [http://ha.ckers.org/xss.html RSnake's XSS Attack Cheat Sheet]
-{{Top_10_2010:BottomAdvancedTemplate|box|useprev=2010PrevLink|usenext=2010NextLink|prev=A1-Injection|next=A3-Broken Authentication and Session Management}}
+{{Top_10_2010:BottomAdvancedTemplate|type=box|useprev=2010PrevLink|usenext=2010NextLink|prev=A1-Injection|next=A3-Broken Authentication and Session Management}}
 [[Category:OWASP Top Ten Project]]

@@ Line 49: / Line 49: @@
 {{Top_10_2010:SubsectionExampleTemplate|XSS|}}
 The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
 The attacker modifies the ‘CC’ parameter in their browser to:
-:[[File:Xss-snippet-2.png]]
 This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
@@ Line 70: / Line 69: @@
 * [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]
 * [http://ha.ckers.org/xss.html RSnake's XSS Attack Cheat Sheet]
 {{Top_10_2010:BottomTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A1-Injection|next=A3-Broken Authentication and Session Management}}
-</td></tr></table>
 [[Category:OWASP Top Ten Project]]