Talk:XSS (Cross Site Scripting) Prevention Cheat Sheet

This was somehow entered as a 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: 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 executable

“1.jpg' onerror='alert(document.cookie)”