Talk:XSS (Cross Site Scripting) Prevention Cheat Sheet - Revision history

Mseil: Migrated a bug for ESAPI over to where it belongs.

2017-08-03T20:02:04Z

Migrated a bug for ESAPI over to where it belongs.

Sergey Pomytkin at 17:43, 20 February 2012

2012-02-20T17:43:37Z

Sergey Pomytkin at 17:39, 20 February 2012

2012-02-20T17:39:18Z

Sergey Pomytkin at 17:37, 20 February 2012

2012-02-20T17:37:31Z

Chris Schmidt: /* DOM Based XSS */ new section

2010-02-08T23:51:25Z

‎DOM Based XSS: new section

Blbroussard at 21:37, 29 May 2009

2009-05-29T21:37:05Z

Blbroussard: Rule #5 issues

2009-05-29T21:35:41Z

Rule #5 issues

New page

Rule #5 has a few concerning points:
1. It mentions <a href=http://...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a >, but I think more common is <a href=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a > where the full href contents are untrusted. There should be some mention here about relative links too.

2. Is the following a contradiction?

"Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the %HH escaping format."

"Note that entity encoding is useless in this context."

3. The following is confusing and possibly nonsensical. "Including untrusted data in data: URLs should not be allowed as there is no good way to disable attacks with escaping to prevent switching out of the URL."

Other points about Rule #5:
There are numerous special characters that must be accepted in URLs. The note that entity encoding is useless is not quite right. Entity encoding is useful to stop injecting UP. The problem with it, which should be explained in the article, is that when an anchor tag is clicked on, the entities are interpreted. This usually means that the link has to be clicked on to trigger the payload. However, if there is other javascript on the page which references this href value, it will use the un-encoded value. I've seen this in redirection javascript.

Does forcing the untrusted data to start with http remediate this hole for absolute URLs? My assumption here is that the way to attack here would be to use "Javascript:some javascript" as the untrusted input.

← Older revision		Revision as of 20:02, 3 August 2017
Line 1:		Line 1:
		+	This was somehow entered as a [[bug for ESAPI:https://github.com/ESAPI/esapi-java-legacy/issues/247\|bug for ESAPI:]]
		+	The cheat sheet currently gives three examples of CSS
		+
		+	<style>selector { property : ...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...; } </style> property value
		+	<style>selector { property : "...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE..."; } </style> property value
		+	text</style> property value
		+	only 2 is safe against IE's expression syntax even when correctly encoded (see Issue 236).
		+
		+	The text then goes on to say:
		+
		+	"All attributes should be quoted but your encoding should be strong enough to prevent XSS when untrusted data is placed in unquoted contexts."
		+
		+	which is impossible since in an unquoted context, IE will still honour an encoded expression.
		+
		+	There's a missing syntax:
		+
		+	text</style> property value
		+	It's a dangerous omission since it's the only safe syntax for the style attribute.
		+
		+	I think three things need to be done:
		+
		+	Add syntax example 4
		+	Mark 1 and 3 as "unsafe"
		+	Modify the wording underneath to read "All attributes should be quoted or they will be vulnerable to XSS" or similarly acknowledge that encoding isn't enough in unquoted contexts.
		+
		+	==============
	Rule #5 has a few concerning points:		Rule #5 has a few concerning points:
	It mentions <a href=http://...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a >, but I think more common is <a href=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a > where the full href contents are untrusted. There should be some mention here about relative links too.		It mentions <a href=http://...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a >, but I think more common is <a href=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a > where the full href contents are untrusted. There should be some mention here about relative links too.

@@ Line 33: / Line 33: @@
 Like for code
-<% String url = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) ); %>
+&lt;% String url = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) ); %>
-  <img src='$url'>
 Following input : …
 Will produce executable
 “1.jpg' onerror='alert(document.cookie)”

@@ Line 32: / Line 32: @@
 For instance statement “Most web frameworks have a method for HTML escaping for the characters detailed below. However, this is absolutely not sufficient for other HTML contexts” would be even bolder if accompanied with example of alert statement executable in different contexts after it was HTML escaped.
 Like for code
 String url = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );
   <img src='$url'>
 Following input : …
-Will produce code
+Will produce executable
 “1.jpg' onerror='alert(document.cookie)”

← Older revision		Revision as of 17:37, 20 February 2012
Line 28:		Line 28:

	This also is a direct port of the Java EE Encoders		This also is a direct port of the Java EE Encoders
		+	== Examples ==
		+	Agree with all above. In addition – article will greatly benefit from examples of evil input data examples.
		+	For instance statement “Most web frameworks have a method for HTML escaping for the characters detailed below. However, this is absolutely not sufficient for other HTML contexts” would be even bolder if accompanied with example of alert statement executable in different contexts after it was HTML escaped.
		+	Like for code
		+	String url = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );
		+	<img src='$url'>
		+	Following input : …
		+	Will produce code
		+	“1.jpg' onerror='alert(document.cookie)”

← Older revision		Revision as of 23:51, 8 February 2010
Line 15:		Line 15:

	Does forcing the untrusted data to start with http remediate this hole for absolute URLs? My assumption here is that the way to attack here would be to use "Javascript:some javascript" as the untrusted input.		Does forcing the untrusted data to start with http remediate this hole for absolute URLs? My assumption here is that the way to attack here would be to use "Javascript:some javascript" as the untrusted input.
		+
		+	== DOM Based XSS ==
		+
		+	Consider cross linking and adding information to ESAPI4JS for DOM-Based XSS Protection.
		+
		+	For quick reference it has nearly the same API as ESAPI for Java EE
		+
		+	$ESAPI.encoder().encodeForHTML()
		+	$ESAPI.encoder().encodeForHTMLAttribute()
		+	$ESAPI.encoder().encodeForJavaScript()
		+	$ESAPI.encoder().encodeForCSS()
		+
		+	This also is a direct port of the Java EE Encoders

@@ Line 1: / Line 1: @@
 Rule #5 has a few concerning points:
-. It mentions <a href=http://...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a >, but I think more common is <a href=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a > where the full href contents are untrusted. There should be some mention here about relative links too.
+It mentions <a href=http://...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a >, but I think more common is <a href=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>link</a > where the full href contents are untrusted. There should be some mention here about relative links too.
-. Is the following a contradiction?
+Is the following a contradiction?
 "Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the %HH escaping format."
@@ Line 8: / Line 8: @@
 "Note that entity encoding is useless in this context."
-. The following is confusing and possibly nonsensical. "Including untrusted data in data: URLs should not be allowed as there is no good way to disable attacks with escaping to prevent switching out of the URL."
+The following is confusing and possibly nonsensical. "Including untrusted data in data: URLs should not be allowed as there is no good way to disable attacks with escaping to prevent switching out of the URL."
 Other points about Rule #5:
-  There are numerous special characters that must be accepted in URLs. The note that entity encoding is useless is not quite right. Entity encoding is useful to stop injecting UP. The problem with it, which should be explained in the article, is that when an anchor tag is clicked on, the entities are interpreted. This usually means that the link has to be clicked on to trigger the payload. However, if there is other javascript on the page which references this href value, it will use the un-encoded value. I've seen this in redirection javascript.
 Does forcing the untrusted data to start with http remediate this hole for absolute URLs? My assumption here is that the way to attack here would be to use "Javascript:some javascript" as the untrusted input.