Есть ли какие-либо проблемы безопасности, оставляющие файлы отладки PDB на живых серверах? - PullRequest
Новая
       16

Есть ли какие-либо проблемы безопасности, оставляющие файлы отладки PDB на живых серверах?

23 голосов
/ 01 июня 2009

Есть ли какие-либо проблемы безопасности при сохранении файлов .NET PDB на реальном сервере?

Я знаю, что выдача исключений может занять немного больше времени, но кто все равно выбрасывает исключения во время обычного выполнения? :-)

Но с точки зрения безопасности? какие-либо проблемы?

Ответы [ 7 ]

17 голосов
/ 01 июня 2009

Если ваша система не защищена с помощью PDB, возможно, она не защищена без них. Очевидно, это зависит от того, насколько ценны для вас лучшие сообщения об ошибках. Лично я очень ценю это, поэтому склоняюсь к развертыванию PDB.

7 голосов
/ 11 июля 2009

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

Как минимум, PDB, которые соответствуют развернутым DLL , должны находиться в ZIP-файле на производственном сервере. Их могут легко найти другие люди, кроме вас, если вас нет рядом, чтобы помочь.

См. Также Файлы PDB: что должен знать каждый разработчик . Автор - Джон Роббинс.

6 голосов
/ 01 июня 2009

Единственная проблема, с которой вы можете столкнуться при публикации файлов .PDB на вашем веб-сайте, - это возникновение исключения, и вы забыли установить свойство CustomErrors в web.config. Трассировка стека будет отображаться с именами файлов и номерами строк, что может быть проблемой безопасности.

Не думаю, что есть другие риски.

3 голосов
/ 01 июня 2009

Если сервер IIS, нет. Эти файлы не будут открыты для общественности, если хранятся в нужных местах (веб-сайт \ bin). Иногда на веб-серверах я обнаруживаю промежуточные файлы (директория obj) - это, кажется, любимый способ случайной публикации двоичных файлов. Во всех случаях, когда ваши pdbs видны, вы также видите dll, что еще хуже.

Как отмечает activa, трассировка стека очень полезна для хакера с номерами строк или без них. Держите это в тайне.

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

2 голосов
/ 01 июня 2009

Если вы предоставляете конечному пользователю ошибочные исключения (он же «Желтый экран смерти»), то это может привести к тому, что злоумышленник сможет лучше понять вашу систему.

Одно из возможных решений - иметь политику обработки исключений , которая:

  1. Регистрирует все исключения с исходной трассировкой стека, дополнительной информацией и уникальным идентификатором исключения (Guid).
  2. Заменяет сгенерированное исключение оболочкой, которая содержит только идентификатор исключения (для справки и обратной связи) и очищенное сообщение (т. Е. Без строк подключения) с информацией о трассировке стека.

Примеры блоков обработки исключений с открытым исходным кодом в .NET:

0 голосов
/ 01 июня 2009

Хм - я бы на этом опирался на предостережение безопасности. Я думаю, что вы должны иметь PDB, но не на производственных серверах. Кроме того, вы должны отключить Debug на любой работающей системе. Отладка неприятна, и вы просто не хотите ее, когда она вам не нужна.

С Скотт Гатри :

  1. Компиляция страниц ASP.NET занимает больше времени (поскольку некоторые пакетные оптимизации отключены)
  2. Код может выполняться медленнее (поскольку некоторые дополнительные пути отладки включены)
  3. Во время выполнения в приложении используется гораздо больше памяти
  4. Скрипты и изображения, загруженные из обработчика WebResources.axd, не кэшируются

Установить развертывание розничная = истина в вашем компьютере.config: 

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

Это переопределяет параметры отладки, ошибок и трассировки, которые предотвращают раскрытие любых ошибок за пределами самого компьютера.

Итак, теперь, когда у вас отключена отладка, нет ошибок или трассировки, зачем развертывать PDB на рабочем сервере? Храните их где-нибудь еще, возможно, даже на своем сервере разработки. Ваш сценарий продвижения кода от Dev до Production может специально исключать PDB, но архивировать их, чтобы они были доступны, если вам когда-нибудь понадобится выполнить отладку производства.

0 голосов
/ 01 июня 2009

По сути, PDB чуть ниже исходного кода, когда дело доходит до поиска, и ASP.NET/IIS также не мешает их загрузке.

Теперь, конечно, люди должны будут угадать название сборки, и это может быть маловероятным, но зачем рисковать?

...