У меня есть приложение, которое регистрирует трассировки strack исключений, и я хотел, чтобы эти трассировки стека включали имена файлов и номера строк при развертывании в процессе производства. Я понял, как развернуть символы отладки с сборкой, но в процессе исследования проблемы я столкнулся с этим вопросом, что подразумевает, что это не очень хорошая идея для включения файлов pdb в производственную среду. Комментарий к принятому ответу гласит: "... отладочная информация может передавать конфиденциальные данные и быть вектором атаки. В зависимости от вашего приложения".
Итак, какие уязвимые данные могут быть выставлены? Как использовать символы отладки для компрометации приложения? Мне любопытно узнать технические подробности, но то, что я действительно ищу, - это практический способ оценить риск включения символов отладки для любого конкретного приложения и производственной среды. Или сказать иначе: какое худшее могло случиться?
РЕДАКТИРОВАТЬ: последующий вопрос/разъяснение
Поэтому, основываясь на всех ответах, похоже, этот вопрос может быть немного упрощен для приложений .NET. Этот бит из блог Джона Роббинса, связанный в Майкл Мэддокс отвечает, который выскочил на я:
.NET PDB содержит только два фрагмента информацию, имена исходных файлов и их линии и локальную переменную имена. Вся другая информация уже в метаданных .NET, так что не нужно дублировать то же самое информация в файле PDB.
Для меня это повторяет то, что другие говорили о рефлекторе, подразумевая, что реальной проблемой является доступ к сборкам. Как только это будет определено, единственное решение, принятое в отношении PDB, заключается в том, заботитесь об экспонировании имен файлов, номеров строк и локальных имен переменных (при условии, что для начала не показывайте трассировки стека конечным пользователям). Или я слишком упростил это?
