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

Ответ 1

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

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

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

Задайте розничную розницу развертывания = true в файле machine.config:

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

• Из Lokad

• Из Microsoft

• Теория

Ответ 7

В основном PDB находятся чуть ниже исходного кода, когда речь заходит о том, чтобы выкачать, а ASP.NET/IIS не мешает им загружаться.

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