Как аутентифицировать приложение Windows против другого приложения / COM-объекта - PullRequest
Новая
       18

Как аутентифицировать приложение Windows против другого приложения / COM-объекта

1 голос
/ 16 августа 2010

В моей системе 3 компонента:

  1. COM-объект - Предоставление услуг приложению, которое имеет func1 (), func2 ()
  2. App1 - Доверенное приложение, которому необходимо использовать функции com-объекта (1 и 2)
  3. App2 - Вредоносное приложение, не разрешенное для использования func1 (), может использовать func2 () , это не опасно.

Как COM-объект может "аутентифицировать" App1 и разрешить ему использовать func1 () и func2 () и запретить доступ к func1 () из App2 ?

Один из способов сделать это - разрешить только пользователям-администраторам доступ к func1 () , но это не очень хорошее решение из-за рекомендаций по безопасности: запускать с наименее привилегированным пользователем. App1 потребуется только администратор для доступа к COM-объекту, любая дыра в безопасности в App1 даст злоумышленнику доступ администратора.

Как это можно решить?

Ответы [ 3 ]

1 голос
/ 19 августа 2010

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

ЕслиВаш COM-объект является сервером in-proc (DLL, которая будет загружена в адресное пространство приложения, которое его использует), тогда вы можете сделать «быстрое и грязное» решение: внутри DllMain вы можете проверить имяEXE-файл, который загрузил вашу DLL.Вы можете сделать это в отношении GetModuleFileName с NULL в качестве первого параметра.Если «неправильный» exe попытается загрузить вашу dll, DllMain может вернуть FALSE.Тот же тест, который вы можете выполнить в любом из ваших методов вместо DllMain.

Лучший общий способ решения вашей проблемы (лучшее, что я вижу из причины), это добавить дополнительный метод в ваш COMОбъект, который вы можете использовать для авторизации звонящего.Например, чтобы использовать любые «секретные» функции, такие как func1(), вы можете потребовать от вызывающего абонента вызова другой функции authorize().Вызывающая сторона предоставляет вашему COM-объекту в качестве входного параметра authorize() некоторую информацию, которую можно использовать для проверки разрешений вызывающей стороны.Если авторизация в порядке, authorize() вернет токен авторизации (cookie), который может быть любым, что вы можете легко проверить позже.Лучшие токены должны быть основаны на криптографических алгоритмах, таких как цифровая подпись.Функция func1() может иметь дополнительный параметр - токен (cookie), полученный от authorize1().Таким образом, вы можете реализовать любой вид авторизации, который захотите.Этот способ будет работать с любыми COM-объектами (не только с in-proc-серверами).

1 голос
/ 22 августа 2010

Я думаю, что @quip имел в виду набор интерфейсов IClassFactory2, который поддерживает лицензирование. Смотрите здесь:

http://msdn.microsoft.com/en-us/library/ms680095(v=VS.85).aspx

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

Дело в том, что App1, который авторизован, должен вызвать CoGetClassObject (), чтобы получить объект, который реализует IClassFactory2, а затем вызвать IClassFactory2 :: CreateInstanceLic (), передав секретный ключ, который позволяет COM-серверу узнать, что он авторизован. Это, в свою очередь, создаст экземпляр вашего COM-объекта с соответствующими флагами, указывающими, что он доступен для полного использования (при условии действительного ключа). Если передан неверный ключ, инициализируйте ваш COM-объект для использования неавторизованным клиентом.

App2, который не авторизован, будет вызывать стандартную функцию CoCreateInstance (), которая под прикрытием вызывает CoGetClassObject () для получения объекта, реализующего IClassFactory, а затем вызывает IClassFactory :: CreateInstance (). Эта реализация должна создавать экземпляр вашего COM-объекта с флагами, установленными для неавторизованного клиента.

0 голосов
/ 19 августа 2010

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

...