При просмотре /trace.axd отображается информация о сервере — блокировка показа PCI

Моя компания проводит сканирование на соответствие PCI, и каждый раз нас беспокоит утечка информации о подробных сообщениях об ошибках ASP.NET.

Описание: Было обнаружено подробное сообщение об ошибке ASP.NET... и он обеспокоен тем, что мы показываем потенциальным хакерам нашу версию ASP.NET, версию IIS и т. д.

То, что запускает эту информацию, — это просмотр «нашего сайта»/Trace.axd, и если вы это сделаете, вы получите сообщение об ошибке трассировки, подобное этому:

Описание ошибки трассировки: Текущие настройки трассировки запрещают удаленный просмотр trace.axd (по соображениям безопасности). Однако его могут просматривать браузеры, работающие на локальном сервере.

который имеет это внизу страницы:

-------------------------------------------------- ------------------------------ Информация о версии: Версия Microsoft .NET Framework: 2.0.50727.4234; Версия ASP.NET: 2.0.50727.4223

Самое смешное, что в сообщении об ошибке говорится, что трассировка отключена, и вам нужно изменить web.config, чтобы увидеть это! Мой web.config имеет (отрывок):

<configuration>
  <system.web>
    <trace enabled="false" requestLimit="10" pageOutput="false" localOnly="true" />

Я считаю, что это правильная иерархия для оператора отключения трассировки. Я не понимаю, почему сервер отвечает сообщением о том, что трассировка отключена, если она отключена. Если это нормальное поведение, то почему наш PCI-сканер жалуется на разглашение слишком большого количества информации?

Любая помощь, которая заставит его перестать быть таким разговорчивым, очень ценится.

Кстати, если это имеет значение, мои пользовательские ошибки выглядят так:

<system.web>
    <customErrors mode="Off" defaultRedirect="~/Errors/GeneralError.aspx">
        <error statusCode="404" redirect="~/Errors/PageNotFound.aspx" />
    </customErrors>

asp.net iis-7 pci-dss
person Deverill    schedule 03.02.2014    source источник
comment
Не следует ли <customErrors mode="On"?   -  person MikeSmithDev    schedule 03.02.2014
comment
Да, конечно. Это самая большая часть - он больше не показывает детали. Есть ли способ вообще не показывать страницу Trace Error? Майк, скопируй свой комментарий в ответ, и я награжу его как таковой, поскольку он решает мою насущную проблему.   -  person Deverill    schedule 03.02.2014

Ответы (2)


arrow_upward
2
arrow_downward

Во-первых, убедитесь, что CustomErrors включен, используя:

<customErrors mode="On"

или даже

<customErrors mode="RemoteOnly"

Что касается trace.axd, ваш web.config верен, и наличие trace enabled="false" должно препятствовать навигации по этому URL-адресу. Я полагаю, что эта информация об ошибке показывалась только потому, что ваши пользовательские страницы ошибок не использовались.

person MikeSmithDev    schedule 03.02.2014
comment
Спасибо! Иногда я так глубоко погружаюсь в проблему, что едва понимаю, что очевидный ответ ускользает от меня. Я ценю вашу помощь! - person Deverill; 03.02.2014

arrow_upward
13
arrow_downward

Ни одно из этих решений не сработало для нас, потому что обработчик зарегистрирован и обходит конвейер MVC. Наше решение состояло в том, чтобы удалить обработчик до регистрации обработчиков mvc.

<system.webServer>
    <handlers>    
        <remove name="TraceHandler-Integrated" />
        <remove name="TraceHandler-Integrated-4.0" />

Работал как шарм и вернул 404 по запросу.

person Nick Barnes    schedule 22.09.2014
comment
Возможно для вашей ситуации, но для моей не нужно было делать шаги Ника Барнса. MikeSmithDev быстро ответил работоспособным решением, так что это должен быть его ответ, а не ответ 7 месяцев спустя, хотя другим может быть полезно это увидеть. Я рад, что он также опубликовал свое решение, но сказать, что это должен быть ответ, несправедливо. - person Deverill; 20.07.2015