2017-01-08 14 views
7

.Net security noob здесь ... Каков самый простой способ предотвратить загрузку моей сборки кем-то другим?Простейший способ предотвратить загрузку моей управляемой сборки?

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

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

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

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

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

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

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

+0

Был ли у вас голос, чтобы закрыть это? если да, то почему? Может быть, укажите мне, на что это ответили. Возможно, я пропустил что-то уже там. Или также возможно, что на это действительно не ответил. – JohnZaj

+0

Что вы подразумеваете под «предотвращением загрузки»? В общем случае это невозможно, потому что ваша сборка является непрозрачным файлом, как и любой другой. Возможно, что ваш .NET-код внутри этой сборки не запущен или скрывается внутри. PS: как вы узнали, сильное имя - это просто идентификация. Когда вы уходите в отставку, он больше не приходит от того же издателя. Если эта сборка содержит код, который проверяет его издатель, код внутри может использовать его для изменения его действия, но все еще можно загрузить. –

+0

Вы хотите, чтобы остановить вас .Net dll был COM читабельным? – TechLiam

ответ

2

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

+0

Hah хороший ответ. Однако часть безопасности заключается в том, что ее все еще необходимо использовать. Конечно, лучший способ обеспечить что-то существующее может состоять в том, чтобы поместить его в ящик для блокировки на дне океана, выключенный. Однако, если он не используется, он не отвечает требованиям безопасности ... быть полезным :) – JohnZaj

2

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

+1

Уже делаю это. Однако имейте в виду, что у de4dotnet есть довольно хороший послужной список де-обфускации практически любого инструмента обфускации любого поставщика. Я тестировал это много. – JohnZaj

4

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

  1. Подписывание установочного пакета (msi). Вам понадобится сертификат SSL . Пользователи будут видеть издателя загруженных файлов во время процесса установки. Если ваш установочный пакет изменен - ​​подписание будет нарушено , и пользователь во время установки увидит, что приложение принадлежит Неизвестному издателю или другому издателю, кроме вас.
  2. Именование мощного узла позволяет предотвратить замену библиотеки на другую «плохую» библиотеку. Давайте рассмотрим следующий сценарий: вы развернули свое приложение с библиотекой A на какой-то сервер или пользователь, установив приложение на свой компьютер. Без сильного имени библиотека A или любые другие могут быть заменены или изменены каким-либо кодом на другую версию. Например, эта новая версия может отправлять какие-либо пароли пользователей или совершать другие вредоносные действия. Если одна библиотека была изменена .Net во время загрузки, она выдает сильное исключение проверки имени. Итак, ваше приложение будет разбито. Вредоносный код должен перекомпилировать все библиотеки приложений, чтобы приложение работало. Это тяжелее.
  3. Обфускация также является очень важной вещью, которая позволяет сделать очень трудное или даже невозможное понимание того, что происходит внутри сборки (переименование кода, строковое шифрование и т. Д.).
  4. Если у вас есть очень критический интеллектуальный код, лучше переписать его на собственный (C/C++) код.
  5. Если ваше приложение является мобильным или настольным приложением, и оно делает запрос на бэкэнд, вы можете переместить важный код на сервер.
+0

С вашего первого момента: я всегда делал это с моими MSI и их загрузчиками и т. Д. Вы предлагаете, чтобы подпись цифровой подписи на сборке/файле была маршрутом к тому, чтобы сделать ее не подлежащей вызову (unloadload я думаю невозможно)? – JohnZaj

+0

Цифровая подпись позволяет идентифицировать только издателя. Итак, если вы загружаете msi или exe с сайта Microsoft во время установки, вы видите компанию Microsoft в качестве проверенного издателя. Вот и все. –

+0

Позвольте мне сказать так: скажем, я включил механизм, чтобы запретить вызывающему абоненту делать определенные вещи с моей сборкой, если у вызывающей сборки нет защищенного уникального идентификатора, лучше ли иметь этот уникальный идентификатор цифровую подпись на сборке делать вызов? Или сильный ключ? Я думаю, что позже. – JohnZaj

1

Один вариант (который может быть или не быть осуществимым) заключается в том, чтобы не дать им сборку. Если вы можете сделать свое приложение на базе Интернета (например, Software as a Service), то (с правильно защищенными серверами) ваши клиенты не будут иметь доступа к сборкам.

+1

Исправлено, и это уже по большей части, поскольку они находятся за защищенными серверами. Однако, хотя это маловероятно, сборка не является невозможной для того, чтобы попасть в руки кого-то, для кого она не предназначена. Пример 1: недовольный сотрудник. – JohnZaj

+0

@JohnZaj Если это часть вашей модели угрозы, тогда вы правы. – TrueWill