Обеспечивают ли сборки со строгими именами в .NET защиту кода?

Я пытаюсь понять смысл сборок со строгими именами в .NET. Погуглив об этом, я заметил, что везде говорится, что он гарантирует, что код исходит от меня и не был подделан. Итак, я проверил это. Я создал простую DLL, подписал ее вновь созданным ключом PFX и сослался на нее в своем приложении WPF. И ладно, все работает. Когда я компилирую DLL с другим файлом PFX, я получаю сообщение об ошибке, так что все в порядке.

НО, когда я декомпилирую DLL с помощью ildasm, изменяю ее и перекомпилирую с помощью ilasm, приложение WPF по-прежнему работает без ошибок. Поэтому я подделал DLL со строгим именем и вручную заменил ее на старую, и приложение по-прежнему работает с поддельной DLL. Токен PublicKeyToken такой же. Так в чем же смысл сильного именования? Это не гарантирует, что код не был подделан с тех пор, как я дал ему строгое имя.


.net c# pfx signing strongname
person Michal_Drwal    schedule 02.11.2018    source источник
comment
Можете ли вы указать точные шаги и код, который вы использовали?   -  person Patrick Hofman    schedule 02.11.2018
comment
Вы вмешивались на другой машине, где у вас точно нет доступа к оригинальному PFX?   -  person Damien_The_Unbeliever    schedule 02.11.2018
comment
Может быть, вы отключили проверку строгого имени на своем ПК из соображений производительности? docs.microsoft.com/en-us/dotnet/framework/app-domains/   -  person Access Denied    schedule 02.11.2018

Ответы (1)


arrow_upward
5
arrow_downward

Раньше выполнялась проверка на подделку, но накладные расходы на проверку каждой сборки, подписанной строгим именем, при запуске приложения были слишком высоки, поэтому Microsoft отключила это поведение по умолчанию несколько лет назад (давно, когда был выпущен «.NET Framework версии 3.5 с пакетом обновления 1»).

Это называется обходом сильных имен.

Вы можете отключить эту функцию (т. е. заставить Windows проверять наличие несанкционированного доступа) для определенного приложения, добавив следующее в его файл «.config»:

<configuration>  
  <runtime>  
    <bypassTrustedAppStrongNames enabled="false" />  
  </runtime>  
</configuration>

Вы можете включить проверку строгого имени для ВСЕХ приложений, отредактировав реестр (что явно не является возможным решением!).

Дополнительные сведения см. на следующей странице:

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature

Совет в настоящее время состоит в том, чтобы использовать полный сертификат подписи кода для вашего исполняемого файла и DLL, если вы хотите предотвратить подделку кода.

person Matthew Watson    schedule 02.11.2018
comment
Итак, если вы подписываете сборку сертификатом подписи кода, то отключение проверки не сработает? - person Access Denied; 02.11.2018
comment
@AccessDenied: Нет, поскольку сертификаты подписи кода всегда проверяются самой Windows (вы не можете отключить это, насколько я знаю). Строгие имена были более локализованным и простым решением для .NET-приложений, но полные сертификаты подписи кода можно использовать для любого приложения, и они спроектированы так, чтобы быть очень безопасными. - person Visual Vincent; 02.11.2018
comment
Хорошо, теперь это работает. Итак, сборки со строгими именами бессмысленны с точки зрения проверки на подделку? Или, может быть, как-то можно установить этот флаг в отделенном коде и запутать его, чтобы никакие ключи реестра не могли на него повлиять? - person Michal_Drwal; 02.11.2018
comment
@Michal_Drwal Это просто означает, что вам придется платить за безопасность. Например, купите коммерческий сертификат и наслаждайтесь: comodo.com /e-commerce/code-signing/code-signing-certificate.php - person Access Denied; 02.11.2018
comment
Моя компания купила полный сертификат подписи кода, но я хотел обеспечить дополнительную безопасность. Но как я понял и проверил, проверку этого купленного полного сертификата подписи кода нужно делать самому в коде? Я сослался на подписанную dll, которая была подписана с купленным сертификатом, подделал ее, и она все еще работала. Таким образом, Windows не заметила, что подпись была удалена. - person Michal_Drwal; 02.11.2018
comment
@Michal_Drwal: Итак, сборки со строгими именами бессмысленны с точки зрения проверки на подделку? - Не обязательно. Параметр app.config не переопределяется реестром, поэтому, если вы установите его, ваши сборки будут проверены. Однако, как вы говорите, это не на 100% безопасно. Это предотвращает подделку внешних библиотек и их загрузку вашим приложением, но не мешает кому-либо изменять ваше основное приложение и вмешиваться в него или отключать эту проверку. Это просто средство для проверки библиотек, загруженных вашим приложением. - person Visual Vincent; 02.11.2018
comment
Приложения с полной подписью кода также можно подделать, но тогда они больше не будут соответствовать подписи сертификата и, таким образом, будут отображаться как опасные или ненадежные. Подписание кода никому не мешает изменять двоичный файл, а только изменять его и отображать его как исходящий от вас. - person Visual Vincent; 02.11.2018
comment
@VisualVincent Итак, запутывание пригодится. Я знаю, что это не на 100% пуленепробиваемый, но все же... - person Michal_Drwal; 02.11.2018
comment
@Michal_Drwal: Точно. Вы никогда не сможете запретить кому-либо вмешиваться в сам файл .exe, но вы всегда можете усложнить его и с помощью подписи кода запретить злоумышленникам редактировать его и распространять как исходящий от вас. - person Visual Vincent; 02.11.2018