Как защитить DLL-функции от использования вне моего приложения?

Question

Я хочу запретить другим приложениям использовать написанные мной функции dll.

Например.Если у меня есть база данных.dll с двумя функциями.

public void InsertInToDatabse();
public void ClearDatabase();

Теперь Если мое приложение вызвало InsertInToDatabse () и выполняет какую-то другую работу, до этого времени, если какое-то другое приложение вызывает ClearDatabase (), ссылаясь на базу данных.dll, база данных была бы клернее. Так как я могу ограничить вызовы этих функций из стороннего приложения?

Answer 1

если ваша dll является библиотекой классов, то фактическим файлом конфигурации будет файл клиентского приложения (web.config или app.exe.config), и там только авторизованные приложения будут иметь правильную строку подключения с именем пользователя, паролем, дБ имя сервера и базы данных.

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

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

если этот подход все еще не удовлетворяет вас, тогда вы должны использовать проверку безопасности, например CAS, которая позволяет вам указать, какой класс или сборка могут вызывать определенный метод, поэтому даже если на вашу dll ссылается другое приложение, она не будет Работа. Помните, что в .NET 4 (вы пометили его в вопросе) весь уровень безопасности был изменен и работает не так, как в старых версиях .NET Framework, обратитесь к этой статье для получения более подробной информации: http://msdn.microsoft.com/en-us/library/dd233103.aspx

Answer 2

Как отметил Маркус, вы можете использовать ключевое слово internal.И затем примените InternalsVisibleToAttribute к вашей библиотеке классов с именем сборки вашей прикладной сборки и вашим открытым ключом, если вы используете надежные имена сборок.

MSDN-ссылка

Answer 3

Если я правильно помню, ключевое слово internal предназначено именно для таких типов ситуаций.

Редактировать: Как сказано в комментариях, если class A в assembly B, то class C in assembly D не будет иметь доступа к A.

Кроме того, как указано в других ответах, вы можете (и, вероятно, должны) иметь некоторую форму аутентификации в ClearDatabase().

Редактировать 2: Меня только что осенило, что такого рода разрешения должны быть на уровне базы данных, что означает, что если следующий пользователь (с такими привилегиями):

A: Insert, Update, Create

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

Это не означает, что вы не должны устанавливать ClearDatabase() в качестве internal, но если пользователь (который использует стороннее устройство) имеет разрешения на Drop Table, то он / она сможет независимо.

Редактировать 3:

The problem is not how to secure your code, the problem is how to secure your database.

– Huusom

Answer 4

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

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

РЕДАКТИРОВАТЬ: Я, возможно, неправильно понял вопрос. Если вы НИКОГДА не хотите, чтобы сторонний код вызывал ваши функции, используйте внутренний (и / или InternalsVisibleTo), как предлагает Маркус.

Answer 5

Если вы спрашиваете о безопасности: Другой способ - заставить клиента передать параметр, например, пароль или зашифрованную строку подключения.

Если вы спрашиваете об ограничении путем кэширования (например, разрешите вызывать этот метод только раз в минуту) - тогда посмотрите либо [AspNetCacheProfile] для служб, либо Cache.Insert для кода приложения.

Answer 6

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

Вот описание из статьи MSDN's Friend Assemblies ...

Только сборки, которые вы явно указали в качестве друзей, могут обращаться к дружественным (Visual Basic) или внутренним (C #) типам и членам.Например, если сборка B является другом сборки A, а сборка C ссылается на сборку B, C не имеет доступа к дружественным (Visual Basic) или внутренним (C #) типам в A.