Правильно ли я считаю, что если я подпишу код исполняющего файла, который ссылается на несколько dll (не с строгим именем), то злонамеренный пользователь может заменить мои библиотеки DLL и распространить приложение так, какесли он подписан мной, но выполняет их код?
Да, если остальные библиотеки DLL только подписаны и не имеют строгого имени, они могут быть заменены без .NET, не вызывая исключения.Внутри exe вы можете убедиться, что DLL подписаны тем же ключом, что и exe.Ни один из этих подходов не мешает кому-либо заменить ваши DLL или EXE.
Предполагая, что это правда, кажется, что вы бы на самом деле не хотели подписывать приложение .NET без строгого присвоения имен всему, иначе вы даете людям возможность выполнять кодпод видом приложения, которое вы написали?
Обычно я полагаю, что это «лучшая практика», но опять же вы ничего не помешали.Если у пользователя есть права на изменение файлов в локальной системе, вы не сможете ничего сделать, чтобы остановить его от злонамеренной активности.
Существует несколько технологий запутывания, позволяющих создавать законченные проекты .NET в одном исполняемом файле.может сделать «самый безопасный» подход, но все же может подделать.
Реальный вопрос в том, что вы пытаетесь помешать им сделать?Я имею в виду, почему кто-то будет заинтересован в замене вашей DLL?Чего они надеются достичь, какова их цель?Если вы пытаетесь помешать кому-либо прочесть конфиденциальную информацию из процесса, который вас ожидает, для долгого трудного пути разочарования.Предположим, что злоумышленник имеет полный доступ к вашему исходному коду и каждой части информации, используемой вашим процессом, потому что они это делают.Предположим, что они могут заменить весь или часть вашего кода по желанию, потому что они могут.
Обновлено
Таким образом, перенаправление привязки будет работать только со сборками.строгое имя с тем же ключом, и, следовательно, защищает ли вас от изменения DLL?
Исправьте, с отмеченным исключением, что внедрение кода все еще может быть выполнено различными способами.
... и вернемся к первоначальному вопросуРазве подписание кода без строгих имен подрывает смысл подписи кода?
Не совсем.Подписание кода (не строгое именование) имеет две разные цели:
- Аутентификация.Проверка, кто является автором программного обеспечения.
- Целостность.Проверка того, что программное обеспечение не было подделано с момента его подписания.
Часто это проверяется только во время установки.Вот почему мы подписываем наш setup.exe, чтобы клиент получал неизмененный установщик от нас.Они получают подсказку «Доверяете ли вы компании XXXX» и тем самым предоставляете авторизацию аутентифицированному / подписанному установщику.Однако после установки ОС практически не использует встроенную подпись кода (за исключением драйверов и некоторых других неясных случаев).
Сильное именование с другой стороны имело совершенно иное назначение.Он полностью сосредоточен на «целостности» приложения.Нет сертификата, нет подписывающего органа (ЦС) для его проверки, нет отображаемой пользователем информации, которую они могут подтвердить, и ничего, что ОС не может проверить относительно исполняемого файла, который она собирается запустить.
.NET Frameworkво многих случаях используются строгие имена, все из которых я свободно классифицирую как целостность приложения:
- Содержимое dll / exe имеет подписанный хеш, поэтому его нельзя подделать.
- Каждая ссылка должна иметь строгое имя и проверяться при загрузке зависимости.
- Сборки могут быть зарегистрированы в GAC и могут использоваться политики издателя.
- Для создания собственных изображений можно создавать собственные изображения.скомпилированный образ сборки ИЛ.
Я уверен, что есть и другие вещи, которые мне здесь не хватает, но я знаю об этих основных видах применения.
Лучшие практики для подписи и строгих имен
- Использование подписанного установщика
- Использование исполняемого файла с кодовой подписью
- Использование исполняемого файла со строгим именем
- Строгое имя всех зависимостей и ссылки на них
- Зависимости подписывания кода, как правило, не требуются *
- Рассмотрим регистрацию сборок GAC во время установки
* Примечание. В некоторых случаях подписывание кода может быть полезно для DLL, посколькуНапример, COM-объекты, помеченные как «безопасные» и встроенные в браузер, должны быть подписаны и иметь строгое имя, как если бы это был исполняемый файл.Подписание кода также может быть полезно при внешней проверке зависимостей без загрузки сборки или отражения ее атрибутов.