Самый простой способ запретить кому-либо загружать мою управляемую сборку?

Нуб по безопасности .Net здесь ... Каков самый простой способ предотвратить загрузку моей сборки кем-то другим?

Предыстория: хотя я действительно ищу просто «достаточно хорошую» защиту (при наличии достаточного количества времени/денег/сообразительности кто-то может успешно взломать, взломать и атаковать), похоже, что это уже должна быть решенная проблема, и я просто упускаю ее.

Вот что я (думаю) знаю:

  1. Хотя строгие имена могут использоваться в качестве уровня безопасности, они не обязательно предназначены для этого, согласно эту документацию Microsoft (см. Предупреждение. Не полагайтесь на строгие имена в целях безопасности. Они обеспечивают только уникальное удостоверение.)

    На этом ^ примечании я сталкивался с ситуациями, когда я не мог загрузить стороннюю сборку (я думаю, Aspose), потому что они не подписывали свои сборки, однако все мои были. Так что мне пришлось илдасмать их сборку, подписывать ее своим снк, потом иласмить обратно), чтобы пользоваться их библиотекой. Итак, строгое имя не кажется мне хорошим механизмом безопасности. ОДНАКО... как насчет простой проверки в коде, чтобы убедиться, что вызывающая сборка подписан с моим токеном открытого ключа? Достаточно ли это эффективно?

  2. Если для того, чего я пытаюсь достичь, не следует использовать строгое имя, то лучше ли маршрут реализует проверку цифровой подписи Authenticode в dll (кажется, wintrust.dll может помочь с этим)?

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

Итак, вернемся к вопросу: как самый простой способ предотвратить загрузку моей сборки?


person JohnZaj    schedule 08.01.2017    source источник
comment
Было ли голосование, чтобы закрыть это? если да, то почему? Может быть, укажите мне, где на это был дан ответ. Возможно, я уже что-то пропустил. Или также возможно, что на это действительно не ответили эффективно   -  person JohnZaj    schedule 09.01.2017
comment
Что именно вы имеете в виду под предотвращением загрузки? В общем случае это невозможно, потому что ваша сборка такой же непрозрачный файл, как и любой другой. Что возможно, так это предотвратить запуск вашего кода .NET внутри этой сборки или скрыть что-то внутри нее. PS: как вы уже поняли, строгое именование — это просто идентификация. Когда вы отказываетесь от сборки, она больше не поступает от того же издателя. Если эта сборка содержит код, проверяющий своего издателя, код внутри может использовать его для изменения своего курса действий, но сборка все еще может быть загружена.   -  person Simon Mourier    schedule 11.01.2017
comment
Вы хотите, чтобы ваша .Net dll не читалась COM?   -  person TechLiam    schedule 17.01.2017
comment
@TechLiam нет, это не проблема   -  person JohnZaj    schedule 21.01.2017


Ответы (4)


На самом деле вы не можете дать 100% гарантию, что ваша сборка не будет загружена и использована не по назначению. Но некоторые меры могут вам помочь:

  1. Подписание установочного пакета (msi). Для этого вам понадобится SSL-сертификат. Пользователи увидят издателя загруженных файлов в процессе установки. Если ваш установочный пакет изменен - ​​подпись будет нарушена, и пользователь во время установки увидит, что приложение неизвестного издателя или другого издателя, чем вы.
  2. Строгие имена сборок позволяют предотвратить замену библиотеки на другую «плохую» библиотеку. Давайте рассмотрим следующий сценарий: вы развернули свое приложение с библиотекой А на каком-то сервере или пользователь установил ваше приложение на свой компьютер. Без строгого имени библиотека A или любые другие могут быть заменены или изменены каким-либо кодом на другую версию. Эта новая версия, например, может отправлять куда-то пароли всех пользователей или выполнять другие вредоносные действия. Если одна библиотека была изменена .Net во время загрузки, это вызовет исключение проверки строгого имени. Итак, ваше приложение будет сломано. Вредоносный код должен перекомпилировать все библиотеки приложений, чтобы приложение заработало. Это сложнее.
  3. Обфускация — тоже очень важная вещь, позволяющая сделать очень сложное или даже невозможное понимание того, что происходит внутри сборки (переименование кода, шифрование строк и так далее).
  4. Если у вас есть очень важный интеллектуальный код, лучше переписать его в нативный (C/C++) код.
  5. Если ваше приложение является мобильным или настольным, и оно отправляет запрос к серверу, вы можете переместить важный код на серверную часть.
person Vasyl Zv    schedule 17.01.2017
comment
По вашему первому пункту: я всегда поступал так со своими MSI, их загрузчиками и т. д. Вы предполагаете, что цифровая подпись на сборке/файле будет путем к тому, чтобы сделать его недоступным для вызова (незагружаемым, я думаю, является невозможно)? - person JohnZaj; 21.01.2017
comment
Цифровая подпись позволяет идентифицировать только издателя файла. Итак, если вы загружаете msi или exe с сайта Microsoft, при установке вы видите компанию Microsoft как проверенного издателя. Вот и все. - person Vasyl Zv; 21.01.2017
comment
Позвольте мне выразить это так: скажем, я добавил механизм, запрещающий вызывающей стороне выполнять определенные действия с моей сборкой, если вызывающая сборка не имеет какого-либо безопасного уникального идентификатора, лучше ли, чтобы этот уникальный идентификатор был цифровой подписью сборки, выполняющей Вызов? Или ключ строгого имени? Я думаю, что позже. - person JohnZaj; 24.01.2017
comment
Что-то типа. О строгом имени: когда сборка A подписана (имеет строгое имя), другая сборка B перед вызовом некоторого кода из A выполнит проверку цифровой подписи. Для этого у B есть открытый ключ и зашифрованный хэш сборки (цифровая подпись). Сборка B вычисляет хэш сборки A, расшифровывает зашифрованный хэш с помощью открытого ключа и проверяет, совпадают ли эти хэши. Это не так надежно, потому что вы можете изменить подпись как в A, так и в B (перекомпилировав оба). Но это добавляет некоторую защиту безопасности - person Vasyl Zv; 24.01.2017

Очевидно, но, возможно, не очень полезно: самый простой способ — удалить сборку.

person John Meyer    schedule 17.01.2017
comment
Хах хороший ответ. Однако частью безопасности является то, что его все еще нужно использовать. Конечно, лучший способ обезопасить что-то существующее — положить его в запертый ящик на дне океана, выключить. Однако, если его нельзя использовать, он не соответствует требованиям безопасности ... может быть использован :) - person JohnZaj; 21.01.2017

Я думаю, что вы хотите, чтобы люди не реконструировали вашу сборку, верно? Такие инструменты, как JustDecompiler, могут легко получить код сборки. Чтобы запутать свой код, вы всегда можете прибегнуть к какому-либо платному продукту (Eazfuscator) или к какому-либо продукту с открытым исходным кодом. (Obfuscar или ConfuserEx).

person Renato Afonso    schedule 17.01.2017
comment
Уже делаю это. Однако обратите внимание, что de4dotnet имеет довольно хороший послужной список по распутыванию практически любого инструмента запутывания поставщика. Я много тестировал. - person JohnZaj; 21.01.2017

Один из вариантов (который может быть или не быть осуществимым) — не давать им сборку. Если вы можете сделать свое приложение веб-ориентированным (например, программное обеспечение как услуга), то (с помощью должным образом защищенные серверы) ваши клиенты не будут иметь доступа к сборкам.

person TrueWill    schedule 17.01.2017
comment
Правильно, и по большей части это уже так, находясь за должным образом защищенными серверами. Однако, хотя и маловероятно, сборка не исключена и может попасть в руки кому-то, для кого она не предназначена. Пример первый: недовольный сотрудник. - person JohnZaj; 21.01.2017
comment
@JohnZaj Если это часть вашей модели угроз, то вы правы. - person TrueWill; 23.01.2017