Защитите C # DLL от третьих лиц - PullRequest
4 голосов
/ 10 июля 2009

Дубликат: Как защитить DLL?

Я бы хотел защитить мою C # DLL от использования сторонними приложениями. Я бы хотел, чтобы только МОЯ заявка использовала эту DLL. Как мне этого добиться?

Спасибо.

Ответы [ 5 ]

13 голосов
/ 10 июля 2009

Это просто невозможно.

Вся система безопасности доступа к коду основана на представлении о том, что решения о безопасности принимаются от пользователя, выполняющего код , а не от автора кода . Вы, автор кода, не можете сказать своим пользователям, каковы их решения по безопасности; Вы слуга пользователя, а не хозяин пользователя.

Теперь вы можете усложнить для стороннего кода для использования вашего кода. Вы можете использовать различные атрибуты безопасности для документа , что ваше намерение заключается в том, чтобы сторонний код не использовал ваш код. Это хорошие шаги, но они на самом деле не решают вашу проблему в любом мире, где ваши пользователи враждебны к вам. В модели CAS пользователи всегда побеждают.

Например: у вас могут быть методы в вашем коде, выполняющие требования безопасности, которые запускают обход стека, чтобы проверить, есть ли у каждого в стеке вызовов определенные доказательства, связанные с ними. Например, доказательства того, что «эта DLL была подписана закрытым ключом Гийома со строгим именем, который заперт в ящике в офисе Гийома», были бы хорошим доказательством для проверки. Это почти гарантирует, что каждый, кто вызывает ваш код, также является вашим кодом.

Но это не цель подписания строгого имени; Цель подписи строгого имени - помочь пользователю узнать, что код, который, по его мнению, выполняется, на самом деле был получен от вас. Как мы увидим, использование инструмента безопасности для целей, для которых оно не предназначалось, опасно. Это дает вам совершенно ложное чувство безопасности.

Предположим, ваш пользователь хочет создать приложение, которое не ваше, которое использует вашу DLL. Пользователи могут писать полностью доверенный код, а полностью доверенный код имеет право подделывать доказательства . Вот что означает «полностью доверенный» . Таким образом, пользователь создает приложение, которое не было подписано вами, но поскольку пользователь может полностью доверять этому приложению, приложению, которому полностью доверяют, разрешено подделывать доказательства того, что код исходит от вас.

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

И, черт возьми, пользователь может отключить ВСЮ систему безопасности, если хочет, и в этом случае все может работать.

Вам следует подумать, хотите ли вы вообще отправлять свою DLL клиентам. Если он содержит секреты, которые вы не хотите раскрывать, не делитесь этими секретами с тысячами клиентов, некоторые из которых могут быть враждебны к вам. Если вы храните свою DLL на своих собственных серверах и предоставляете свои услуги через Интернет, то вы никогда не отправите свою DLL клиентам, и поэтому они не смогут использовать ее на своих компьютерах в целях, отличных от ваших.

13 голосов
/ 10 июля 2009

Сделайте все внутренним в DLL, а затем в Properties \ AssemblyInfo.cs установите атрибут InternalsVisibleTo , чтобы он указывал только на строгое имя вашего применение.

3 голосов
/ 10 июля 2009

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

  1. Используйте разрешения безопасности доступа Publisher и / или Identity code, чтобы вы могли проверить исходящий от вас вызывающий код (с помощью теста x509cert и строгого имени). Не забудьте использовать -t при подписании вашей сборки, иначе, когда срок действия вашего x509cert истечет, он потерпит неудачу.

(Сильное имя идентифицирует сборку, издатель определяет, кто опубликовал сборку.)

Вы также хотели бы проверить отключение защиты CAS в .NET, что снова может быть выполнено программно в активе, который вы защищаете.

  1. Запутайте вашу посткомпиляцию DLL (но перед подписанием).

  2. Подумайте о добавлении какой-либо проверки лицензирования к окончательной программной проверке.

НТН

Phil '

1 голос
/ 10 июля 2009

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

Если вы хотите обеспечить безопасность своего кода DLL, настройте где-нибудь веб-службу и настройте приложение для вызова этой службы вместо локальной библиотеки DLL. Тогда у хакеров будет гораздо больше проблем с доступом к вашей библиотеке. К сожалению, это также требует от ваших пользователей постоянного подключения к Интернету.

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

0 голосов
/ 10 июля 2009

Obfusc ваш код является дополнительным решением

...