SecurityInnovation/TMContentReview — Issue #96: How to Prevent Cross-Site Scripting
Author: SergeTruth
Created: 2011-11-07 22:43:02+00:00
State: open

I still think this is a bit too simplified.

Step 3. Determine Whether HTML Output Includes Input Parameters
I think this should replace "Input Parameters" with untrusted data.

"In addition to source code analysis, you can also perform a simple test by typing text such as "XYZ" in form fields and testing the output. If the browser displays "XYZ" or if you see "XYZ" when you view the source of the HTML, your Web application is vulnerable to cross-site scripting."
I think this statement is a bit to conclusory. Having input reflected back indicates a possible location of XSS but the tester need to send "" or "javascript:alert(123)" to identify XSS.

Potentially Dangerous HTML Tags
The tags are not the problem. The different attributes and contexts are the problem.

The type of encoding you use depends on the context

Encode URL Output
The code example for this does not highlight the URL context.

Filter User Input
A common technique is to HTML encode everything them reverse HTML encode specific allowed tags.

Set the Correct Character Encoding
This section does not explain the problem well and only muddies the waters. The main issue is relate to a mismatch in how the validation logic view the incoming data and how the application trys to resolve the input. The problem I think you are alluding to has to deal with overly long UTF-8 formats. But other issues occur related to going from larger character sets to smaller character set, vice versa, and interpretation of escaped characters by the output rendering engine.

The code example regular expression in Validating Unicode Characters does not look correct.

It also might be good to talk about JavaScript encoders.

Unfortunately this section does not cover the topic adequately because it does not cover all contexts or DOM based XSS.