Безопасность для страницы диагностики ASP.NET

Question

Я подумываю о создании страницы диагностики для приложения ASP.NET, которая в основном предназначалась бы для использования администратором для получения дополнительной информации о приложении для диагностики проблем.

Примеры информации, которую может иметь страница:

• System.Environment.MachineName (может быть полезно в сценариях веб-фермы)
• System.Environment.Version
• Environment.UserName
• имя базы данных
• идентификатор сеанса текущего пользователя

Некоторая информация на этой странице может быть конфиденциальной с точки зрения безопасности. Если вы делали такую ​​страницу раньше, какую безопасность вы предоставили для доступа к этой странице? ,

РЕДАКТИРОВАТЬ:

Я должен добавить - иногда может быть полезно увидеть эту страницу, когда вы вошли в систему как определенный (то есть реальный) конечный пользователь. например скажем, проблема может быть воспроизведена только при входе в систему как конкретный пользователь. Возможность просмотра страницы диагностики для этого пользователя может быть полезной. например знание текущего идентификатора сеанса может быть полезно для отладки.

РЕДАКТИРОВАТЬ 2:

Я начинаю думать, что эта страница диагностики на самом деле должна быть двумя разными страницами. Один для отображения содержимого, которое является одинаковым для всех пользователей (например, имя базы данных, версия CLR), а другое для содержимого, которое может варьироваться в зависимости от сеанса (например, информация браузера, идентификатор сеанса). Тогда вы можете заблокировать безопасность больше для первой страницы.

Answer 1

Да, я добавлял такую ​​страницу раньше (и нашел ее полезной).Безопасность была довольно простой: страница содержала форму пароля.Код на стороне сервера проверил этот пароль на соответствие настроенному значению и, если он верен, отобразил реальное содержимое и установил значение в сеансе пользователя, чтобы сказать, что они были аутентифицированы как разработчик, чтобы они не запрашивались снова.время.

Я полагаю, что также была небольшая безопасность от неизвестности, поскольку URL страницы нигде не публиковался.

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

Answer 2

Есть также несколько других способов сделать это:

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

• Используйте простую проверку типа if (Request.IsLocal) ..., но недостатком этого является то, что вам все равно придется подключаться к серверу и просматривать веб-сайт локально - что не всегда возможно. Однако это по-прежнему дает возможность легко просматривать основные настройки системы.

Лично я использовал комбинацию обоих методов, когда локальный запрос всегда разрешает доступ, а нелокальные запросы требуют пользователя с правами администратора - например. if (!Request.IsLocal && !IsAdminUser()) throw new SecurityException().

Кроме того, я согласен с Евгением - будьте осторожны, чтобы не показывать на этой странице ничего действительно чувствительного (например, строки подключения приложения или пароли).

Answer 3

Похоже, вы хотите надежное решение для вашей страницы ошибок. Я хотел бы взглянуть на проекты с открытым исходным кодом, такие как Elmah (http://code.google.com/p/elmah/), для хорошего примера надежной страницы ошибок, которая включает настраиваемую безопасность. Чтобы дать вам идею, вот post по настройке Elmah, который проведет вас через настройку безопасности. Протестированная мною безопасность позволяет мне использовать учетные данные домена для входа в систему.

Answer 4

используйте аутентификацию по формам и настройте одного или двух пользователей с доступом к этой странице. таким образом, вы можете изменить пароли и отозвать доступ после развертывания сайта.