I was excited this afternoon when I thought that I'd stumbled upon a universal XSS vulnerability in verbose ColdFusion error messages. While testing a site, I had noted that a verbose debug error message (see below) echoed back many of the request headers, including the Referrer and User-Agent (aka Browser) headers.

Error Occurred While Processing Request

#Form.XXX#

Naturally, curiosity got the best of me and I attempted to inject JavaScript into the headers only to find that yes indeed, the injected JavaScript was echoed back without being sanitized, which makes for a nice XSS vulnerability on all ColdFusion sites which don't suppress such error messages. Alas, my hopes were dashed when I realized that I'd been beaten to the punch. Despite the setback, I was still curious to see how many sites would be affected by the vulnerability and was blown away when my friend Google suggested that the number may be in the six figure range.

Knowing that, my curiosity was peaked again, so I started poking around to see if I could find other third party or custom web apps which exposed XSS vulnerabilities by echoing back raw request headers. A bit of creative Googling suggested that many have made the same mistake:

• "Error Occurred While Processing Request" referrer
• intitle:"PHPWrap Error"
• intitle:"CGIWrap Error" " -"Local -Information -and -Documentation"
• "The requested URL" "was not found on this server"
• intitle:"File Not Found" intext:"HTTP_USER_AGENT"

The moral of this story is that we must think broadly when defining user input. Data does not need to come from a web form to be considered user supplied input. Headers, cookies, hidden form fields, etc. all come from the client and can therefore be manipulated by an attacker. When building web apps, we need to define user input as ANYTHING that is sent from the client to the server.

- michael