Difference between revisions of "Talk:XSS (Cross Site Scripting) Prevention Cheat Sheet"

Revision as of 17:37, 20 February 2012

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.

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."

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.

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

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)”