Why is the path "/C:badfile" sometimes not being caught by ASP.NET custom error handling?

I've got a bit of an odd situation that recently came up in a security scan and I'm having trouble explaining it. In short, the following URL always returns HTTP 400 and a YSOD:

http://www.mypal4me.com/C:badfile

This site is ASP.NET 4 and is hosted on MaximumASP under IIS7.5. This site is configured with custom errors turned ON and a default redirect page. This is evidenced by causing request validation to throw you off to the error page: http://www.mypal4me.com/?%3Cscript%3E

The only way we've found to send this request off to the custom error page is to add an <error statusCode="400" path="/error.htm" responseMode="ExecuteURL" /> entry under system.webServer.httpErrors in the web.config (obviously this hasn't been done on the site above but has on other MaximumASP sites).

So my question is twofold:

1. Why is this request not being caught by the usual .NET error handling and the custom error page served as a result?
2. Why do I o开发者_StackOverflow中文版nly see this happen at MaximumASP - I can't reproduce an HTTP 400 with that pattern in any other IIS/ASP.NET environment.

---

http://msdn.microsoft.com/en-us/library/s57a598e.aspx

ASP.NET 4 also enables you to configure the characters that are used by the URL character check. When ASP.NET finds an invalid character in the path portion of a URL, it rejects the request and issues an HTTP 400 (Bad request) status code. In previous versions of ASP.NET, the URL character checks were limited to a fixed set of characters. In ASP.NET 4, you can customize the set of valid characters using the new requestPathInvalidChars attribute of the httpRuntime configuration element, as shown in the following example:

---

It's likely request filtering, specially it doesn't like the C: bit, fearing that it is a directory travesal attack of some sort. Many webhosts security settings will block suck a url.

A most likely guess at the the product in use is UrlScan, http://learn.iis.net/page.aspx/473/using-urlscan

Because this filtering runs at a much lower level in the call chain, the request itself is never passed to your asp.net application process (As many of the attacks that are mitigated are designed to trick IIS into returning files outside your application folder). Thus any application defined error routines won't see it, however an IIS error page (which is what your configuring via webc.config) will be triggered.