Моя компания выполняет проверки соответствия PCI, и каждый раз, когда мы каждый раз звоним, это сообщение об ошибке “Сведения об ошибке в ASP.NET”.
Описание: обнаружено подробное сообщение об ошибке ASP.NET… и он обеспокоен тем, что мы показываем потенциальных хакеров нашу версию ASP.NET, версию IIS и т.д.
Вещью, которая запускает эту информацию, является просмотр на “наш сайт”/Trace.axd, и если вы получаете сообщение об ошибке Trace следующим образом:
Ошибка трассировки Описание: текущие настройки трассировки предотвращают просмотр trace.axd удаленно (по соображениям безопасности). Однако его можно было просматривать браузерами, работающими на локальной серверной машине.
который находится в нижней части страницы:
————————————————– —————————— Информация о версии: версия Microsoft.NET Framework: 2.0.50727.4234; Версия ASP.NET: 2.0.50727.4223
Самое забавное, что сообщение об ошибке говорит о том, что трассировка отключена, и вам нужно изменить web.config, чтобы увидеть ее! У моего web.config есть (exerpt):
<configuration>
<system.web>
<trace enabled="false" requestLimit="10" pageOutput="false" localOnly="true" />
Я считаю, что это правильная иерархия для инструкции disable trace. Я не понимаю, почему сервер отвечает сообщением о том, что трассировка отключена, если она отключена. Если это нормальное поведение, то почему наш PCI-сканер жалуется на разглашение слишком большой информации?
Любая помощь, которая заставляет ее перестать быть настолько разговорчивой, очень ценится.
Кстати, если это имеет значение, мои пользовательские ошибки выглядят так:
<system.web>
<customErrors mode="Off" defaultRedirect="~/Errors/GeneralError.aspx">
<error statusCode="404" redirect="~/Errors/PageNotFound.aspx" />
</customErrors>
Во-первых, убедитесь, что CustomErrors включены, используя:
<customErrors mode="On"
или даже
<customErrors mode="RemoteOnly"
Что касается trace.axd, ваш web.config корректен и имеет trace enabled="false" чтобы этот URL-адрес не был навигационным. Я считаю, что он показывал только эту информацию об ошибках, потому что ваши пользовательские страницы ошибок не использовались.
Ни одно из этих решений не работало для нас, потому что обработчик зарегистрирован и обходит конвейер MVC. Наше решение состояло в том, чтобы удалить обработчик до регистрации mvc-обработчиков.
<system.webServer>
<handlers>
<remove name="TraceHandler-Integrated" />
<remove name="TraceHandler-Integrated-4.0" />
Работал как шарм и возвращал 404 по запросу.