为什么路径“/ C：badfile”有时不会被ASP.NET自定义错误处理捕获？

Question

我有一个奇怪的情况，最近出现在安全扫描中，我很难解释它。简而言之，以下URL始终返回HTTP 400和YSOD：

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

此站点是ASP.NET 4，并在IIS7.5下的MaximumASP上托管。此站点配置为打开自定义错误和默认重定向页面。这可以通过导致请求验证将您带到错误页面来证明：http://www.mypal4me.com/?%3Cscript%3E

我们发现将此请求发送到自定义错误页面的唯一方法是在web.config中的system.webServer.httpErrors下添加<error statusCode="400" path="/error.htm" responseMode="ExecuteURL" />条目（显然这还没有在上面的网站，但在其他MaximumASP网站上。）

所以我的问题有两个：

1. 为什么此请求不会被通常的.NET错误处理捕获，并且结果会出现自定义错误页面？
2. 为什么我只在MaximumASP上看到这种情况 - 我无法在任何其他IIS / ASP.NET环境中重现具有该模式的HTTP 400。

Answer 1

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

  

ASP.NET 4还允许您配置使用的字符   通过URL字符检查。当ASP.NET在中找到无效字符时   URL的路径部分，它拒绝请求并发出HTTP   400（错误请求）状态代码。在以前的ASP.NET版本中   URL字符检查仅限于一组固定的字符。在   ASP.NET 4，您可以使用new自定义有效字符集   httpRuntime配置的requestPathInvalidChars属性   element，如以下示例所示：

     

Answer 2

可能是请求过滤，特别是它不喜欢C：位，担心它是某种类型的目录travesal攻击。许多webhosts安全设置将阻止一个网址。

对使用的产品最有可能的猜测是UrlScan，http://learn.iis.net/page.aspx/473/using-urlscan

由于此过滤在调用链中的运行级别低得多，因此请求本身永远不会传递给您的asp.net应用程序进程（因为许多缓解的攻击旨在诱骗IIS在应用程序之外返回文件夹）。因此，任何应用程序定义的错误例程都不会看到它，但是会触发IIS错误页面（通过webc.config进行配置）。