Почему путь / C: badfile иногда не перехватывается при обработке пользовательских ошибок ASP.NET?

Question

У меня возникла странная ситуация, которая недавно возникла при сканировании системы безопасности, и мне сложно объяснить это. Короче говоря, следующий URL всегда возвращает HTTP 400 и YSOD:

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

Этот сайт является ASP.NET 4 и размещен на MaximumASP под IIS7.5. Этот сайт настроен с включенными пользовательскими ошибками и страницей перенаправления по умолчанию. Об этом свидетельствует то, что проверка запроса вывела вас на страницу ошибки: http://www.mypal4me.com/?%3Cscript%3E

Единственный способ отправить этот запрос на пользовательскую страницу ошибок - это добавить <error statusCode="400" path="/error.htm" responseMode="ExecuteURL" /> запись в system.webServer.httpErrors в web.config (очевидно, это не было сделано на сайте выше, но на других сайтах MaximumASP).

Так что мой вопрос двоякий:

1. Почему этот запрос не перехватывается обычной обработкой ошибок .NET, и в результате появляется пользовательская страница ошибок?
2. Почему я вижу это только на MaximumASP - я не могу воспроизвести HTTP 400 с этим шаблоном в любой другой среде IIS / ASP.NET.

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, вы можете настроить набор допустимых символов, используя новый Атрибут requestPathInvalidChars конфигурации httpRuntime элемент, как показано в следующем примере:

Answer 2

Вероятно, это фильтрация запросов, особенно ей не нравится бит C: из-за боязни, что это какая-то атака с обходом каталога.Многие настройки безопасности веб-хостов будут блокировать suck url.

Наиболее вероятным предположением об используемом продукте является UrlScan, http://learn.iis.net/page.aspx/473/using-urlscan

, так как эта фильтрация выполняется на гораздо более низком уровне в вызовев цепочке, сам запрос никогда не передается в процесс приложения asp.net (так как многие из атак, которые смягчаются, предназначены для того, чтобы обманным путем заставить IIS возвращать файлы вне папки вашего приложения).Таким образом, подпрограммы ошибок, определенные приложением, не увидят его, однако будет запущена страница с ошибками IIS (которую вы настраиваете через webc.config).