sanitizing URL input against XSS, starring Security Metrics

Security Metrics PCI scanning reveals hard to find XSS vulnerabilities.

[wickedskaman]

Hello everybody,

Long time listener, first time caller here.

I have a bone to pick with Security Metrics... or my code.

I have an ASP.NET (framework 2.x) site using C# which has failed Security Metrics' PCI scan due to 'XSS vulnerabilities'.

Data input is being sanitized in all the usual places. Any potentially malicious URL strings are caught and sent to a custom 404 page which describes "technical difficulties". However, Security Metrics says that seeing the malicious URL string in the Location header is a no-no even if it is not being directly displayed to the user. I changed the header to prevent outputting the original URL but we are still failing the test and Security Metrics cannot present us with an example of the vulnerability.

Examples they have sent execute no XSS and are not displayed on error pages or in the Location header.

My big question is, then... how do I go about sanitizing all user input that goes into the URL bar? Does anyone know of a way to sanitize the request before redirecting it to the error page? I have asked the Great Google and fiddled around with my own ideas and I haven't been able to come up with a good solution. Thoughts?

Thanks.

[jdMorgan]

I hope I'm understanding the mechanism you're describing here...

If you mean that you are literally redirecting (e.g. 303, 301, or 302 status response) if you see bad input, then don't do that.

Instead, internally rewrite the submission-acknowledgment URL (i.e use ISAPI Rewrite) or 'include' different page-content via script, depending on whether the input was good or bad. Because this approach stays within the context of the current HTTP transaction, you can pass the 'bad string' as an internal server variable instead of including it in the URL.

If that makes no sense in the context of your current approach, then maybe you can redirect only if the submitted input is 'good', rather than if it is 'bad'.

Jim

[wickedskaman]

Thanks for the reply, Jim.

I think part of the problem is I am having a hard time understanding the request/response process in IIS/.NET.

We do have ISAPI filters and I initially tried to tackle the problem from this angle. Unfortunately, we were not passing the scan.

Much of the malicious code is being read as an error by .NET and redirecting through the custom errors system. Thus, I don't know at what point in the request/response process I can intercede with some logic to weed out the loser requests. Can I include the logic in a Master page or is there something in the process I am missing?

[marcel]

Thus, I don't know at what point in the request/response process I can intercede with some logic to weed out the loser requests.

You can catch all unhandled errors in Global.asax

void Application_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError().GetBaseException();
string error = String.Format("There was an error generated, the error was: {0}", ex.Message);
}

how do I go about sanitizing all user input that goes into the URL bar?

Here are a few pointers to help out:
- Always use Stored procedures or parametrized queries.
- If you are expecting an integer (ie. ?id=123) then convert the querystring value to an integer. Convert.ToIn32(Request.QueryString["id"]).

Edit - fixed small coding errors

[edited by: marcel at 9:42 pm (utc) on Jan. 29, 2010]

[Ocean10000]

URLScan might be more what you are looking for, and is free and most likely installed on your server by default. URLScan will happen before it is handed off to Asp.Net on Windows 2003.

URLScan is an ISAPI filter that allows Web site administrators to restrict the kind of HTTP requests that the server will process. By blocking specific HTTP requests, the URLScan filter prevents potentially harmful requests from reaching the server and causing damage.

These are some reference which I think you will find very very informative in securing your website.
How To: Use URLScan [msdn.microsoft.com]
Improving Web Application Security: Threats and Countermeasures [msdn.microsoft.com]
.NET Security [msdn.microsoft.com]

[wickedskaman]

marcel and ocean1000... thanks for that information. That all looks like some good reading. I'll let you all know how it goes. :)

[wickedskaman]

Thanks you to all who responded to my inquiries. It has shed much needed light to educate me on .NET and IIS infrastructure.

In the end I went back to Jim's suggestion and ISAPI filters to see if there was something I missed. Indeed I did and settled on the following before our redirecting of non-www URLs to include www rule:

RewriteRule [^?]*\?.*(?:\<script\>|\<\/script\>).* $0 [F,I]

I had written a similar rule before but had apparently redirected to the front page at this point instead of to $0 for a 404 and did it at the end of the list of ISAPI filters we had installed (ISAPI_Rewrite). I think this was allowing a 301 redirect before reaching my filtering rule, thus leaving the naughty URL query string in the Location header as well as in the default 301 page shown to Telnet under certain circumstances.

I don't know if this inclusion necessarily makes our server safer. The offending string was never shown to end users and even if it was shown to Telnet in the 301 redirect page it was never executed.

Well, now we know Security Metrics is happy and can go on living full and productive lives without fears of meaningless merchant fees.

For anyone in the future happening across this via Mighty Google, there was some good reading here: [helicontech.com...]