During PCI scanning, I am getting a warning “The remote web server is prone to cross-site scripting attacks.” This is a dedicated RHEL/Apache 2 box, so I’ve got full access to the config files.
In multiple tests, it was determined that the problems was that XSS was being allowed within the URL (GET). It’s easy to validate input from a GET, POST, COOKIE, etc… when there is an actual page - but this is triggered just from the URL itself.
I have determined that by placing the following code after the domain name, it is triggering red flags:
All browsers stop the alert, but some are warning that it had to rewrite the URL to pretect me from the XSS attack.
I also have access to Windows IIS 6 servers - so I began the testing. On the windows machines, this was never a problem. It appears IIS is configured to prevent anything from occuring. However - on the RHEL Apache machine - it was triggering errors.
In case the question comes up - yes, the machine has all the latest updates currently applied.
How can I get Apache to sanitize/eliminate these types of requests? Is there a module or a ReWrite I can apply?
Since I’ve never seen this before, I have to admit that I have no idea what you expect Apache to do. That said, IMHO, it’s the webmaster’s duty to cleanse URIs it provides to its visitors.
Yes I agree it is the webmaster job to clense all input, but this is different since the input is a direct hit on the URL. I guess it can be used in a situation where Register Globals is turned on in PHP but other than that it’s pretty useless.
However, IIS does have a mechanism for this type of thing which is why I am asking about Apache. IIS uses an ISAPI module called URLSCAN. It was a separate componant on IIS5 (Windows 2000) but built in to IIS 6 (and I assume 7). I was just hoping there was something similar for Apache.
I suspect that’s all in the coding of the URI as your example is using “Excluded US-ASCII Characters” as defined in [Uniform Resource Identifiers (URI): Generic Syntax](Excluded US-ASCII Characters).
If a browser wants to violate those “requirements,” then there isn’t much you can do but I’ll bet Apache won’t accept them as valid URLs.
This is solved, and for the sake of completeness I will let everyone know what I have learned.
The company doing the PCI Scanning (Security Metrics) was flagging Apache as being vulnerable to XSS attacks. Well, this simply was not true. It turns out the site was simply using the stock 404 error page, and it was echoing any request thrown at the server (when the page was not found). So - if you placed some javascript in the URL, it would echo it on the 404 page. This was a red flag to Security Metrics, even though it was completely harmless.
A custom 404 message, and the next PCI scan passed without any issues.