Существуют ли какие-либо проблемы безопасности, содержащие файлы .NET PDB на реальном сервере?
Я знаю, что отбрасывание исключений может занять немного больше времени, но кто все равно бросает исключения во время нормального выполнения?:-)
Но с точки зрения безопасности? любые вопросы?
Хм - Я бы опирался на это с осторожностью. Я думаю, что у вас должны быть PDB, но не на производственных серверах. Кроме того, вы должны отключить Debug в любой живой системе. Отладка отвратительна, и вы просто не хотите ее, когда она вам не нужна.
Из Скотт Гатри:
Задайте розничную розницу развертывания = true в файле machine.config:
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
Это переопределяет параметры отладки, ошибок и трассировки, которые предотвратят раскрытие любой информации за пределами самого компьютера.
Итак, теперь, когда вы отключили отладку, нет ошибок или трассировки, почему вы планируете развертывать PDB на производственный сервер? Храните их в другом месте, возможно, даже на своем сервере разработки. Продвижение кода script от Dev to Production может специально исключать PDB, но архивируйте их так, чтобы они были доступны, если вам когда-либо понадобилась отладка производства.
Если ваша система не защищена PDB, она, вероятно, не будет защищена без них. Очевидно, это зависит от того, насколько ценны лучшие отчеты об ошибках. Лично я много ценю, поэтому имею тенденцию развертывать PDB.
Единственная проблема, с которой вы можете столкнуться при публикации .PDB файлов на ваш сайт, - это когда возникает исключение, и вы забыли установить свойство CustomErrors в web.config. Трассировка стека будет отображаться с именами файлов и номерами строк, что может быть проблемой безопасности.
Я не думаю, что есть другие риски.
Я считаю, справедливый аргумент заключается в том, что не, оставляя PDB на живых серверах, является риском. В случае сбоя производства и проблем, которые невозможно воспроизвести на dev или UAT, гораздо больше времени (и, возможно, невозможно) диагностировать, где происходит ошибка.
По крайней мере, PDB, которые соответствуют развёрнутым DLL, должны находиться в файле ZIP на рабочем сервере где-то. Они должны быть легко расположены людьми, отличными от вас, если вы не помогаете.
Также см. Файлы PDB: что каждый разработчик должен знать от Джона Роббинса.
Если сервер IIS, нет. Эти файлы не будут доступны публике, если они хранятся в правильных местах (веб-сайт\bin). Иногда я нашел файлы промежуточного (obj-каталога) на веб-серверах - это, по-видимому, является излюбленным способом случайной публикации двоичных файлов. В любых случаях, когда ваши pdbs видны, вы также видите DLL, что хуже.
Как отмечено activa, трассировка стека полезна для хакера с номерами строк или без них. Сохраняйте конфиденциальность.
Я предполагаю, что любая другая программа, которую вы можете запускать на реальном сервере, - службы и т.д. - вообще не является общедоступной.
Если вы представляете неудачные исключения для конечного пользователя (так называемый "Желтый экран смерти" ), тогда это может представлять опасность для злоумышленника получить более полное представление о вашей системе.
Одно из возможных решений - иметь политику обработки исключений, которая:
Примеры блоков обработки исключений с открытым исходным кодом в .NET:
В основном PDB находятся чуть ниже исходного кода, когда речь заходит о том, чтобы выкачать, а ASP.NET/IIS не мешает им загружаться.
Теперь наверняка люди должны угадать имя сборки, и это может быть маловероятным, но зачем рисковать?