2010-08-16 7 views
1

J'ai 3 composants dans mon système:Comment authentifier application Windows contre une autre application/COM Object

  1. COM Object - Fournir des services d'application qui a func1(), func2()
  2. App1 - demande de confiance qui ont besoin d'utiliser l'objet com funcs (1 et 2)
  3. App2 - application malveillante, non autorisés à utiliser func1(), peut u se func2() ce n'est pas dangereux.

Comment le COM Object peut "authentifier" App1 et lui permettant d'utiliser func1() et func2() et refuser l'accès à func1() de App2? Une façon de le faire est de permettre uniquement aux utilisateurs Administrators d'accéder à func1() mais ce n'est pas une bonne solution pour des raisons de sécurité: exécutez avec l'utilisateur le moins privilégié. App1 aura seulement besoin d'un administrateur pour accéder à l'objet COM, un trou de sécurité dans App1 donnera l'accès administrateur de l'attaquant.

Comment cela peut-il être résolu?

Répondre

1

En général, vous devez définir plus précisément comment vous souhaitez divider (identifier) ​​une "bonne" application qui est autorisée à utiliser votre objet COM à partir d'autres "mauvaises" applications. Si votre objet COM est un serveur in-proc (une DLL qui sera chargée dans l'espace d'adressage de l'application qui l'utilise), vous pouvez créer une solution "rapide & sale": A l'intérieur du DllMain, vous pouvez tester le nom du fichier exe qui a chargé votre DLL. Vous pouvez le faire en respectant GetModuleFileName avec NULL comme premier paramètre. Si un "mauvais" exe essaie de charger votre dll, le DllMain peut renvoyer FALSE. Le même test que vous pouvez faire dans n'importe laquelle de votre méthode au lieu de DllMain.

La meilleure façon générale de résoudre votre problème (le meilleur que je vois de cause) sera d'ajouter une méthode supplémentaire à votre objet COM que vous pouvez utiliser pour autoriser l'appelant. Par exemple, pour utiliser des fonctions «secrètes» telles que func1(), vous pouvez demander à l'appelant d'appeler une autre fonction authorize() auparavant. L'appelant donne à votre objet COM en tant que préfixe d'entrée de authorize() certaines informations qui peuvent être utilisées pour vérifier les autorisations de l'appelant. Si l'autorisation est OK, authorize() vous rendra un jeton d'autorisation (cookie) qui peut être tout ce que vous pourrez facilement vérifier plus tard. Les meilleurs jetons devraient être basés sur des algorithmes cryptographiques tels que la signature numérique. La fonction func1() peut avoir un paramètre supplémentaire - le jeton (cookie) reçu de authorize1(). De cette façon, vous pouvez mettre en œuvre tout type d'autorisation que vous voulez.De cette façon fonctionnera avec n'importe quel type d'objets COM (pas seulement avec les serveurs in-proc).

0

La sécurité de Windows est basée sur l'utilisateur, donc je ne crois pas que vous serez capable de le faire au niveau de l'application. Si l'utilisateur peut exécuter la fonction, les deux programmes pourront exécuter la fonction.

+0

Avez-vous des suggestions, que pouvons-nous faire d'autre? – Baget

+0

À la place, vous devrez compter sur les autorisations au niveau de l'utilisateur. Peut-être séparer votre code en 2 DLL et définir différentes autorisations au niveau du fichier. Vous pouvez également définir les autorisations de registre pour votre interface afin de restreindre les utilisateurs autorisés à y accéder. – Mike

1

Je pense que @quip faisait référence à l'ensemble d'interfaces IClassFactory2 qui prend en charge la gestion des licences. Voir ici:

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

L'article aborde les licences par machine (ce qui est pas ce que vous voulez) et les clés de licence d'exécution qui ressemble à ce que vous recherchez. Le point est que App1 qui est autorisé, devrait appeler CoGetClassObject() pour obtenir un objet qui implémente IClassFactory2, puis appeler IClassFactory2 :: CreateInstanceLic() en passant une clé secrète qui permet au serveur COM de savoir qu'il est autorisé . Cela instanciera à son tour votre objet COM avec les indicateurs appropriés indiquant qu'il est disponible pour une utilisation complète (en supposant une clé valide). Si une clé non valide est transmise, initialisez votre objet COM pour l'utiliser par un client non autorisé. App2, qui n'est pas autorisée, appellera le standard CoCreateInstance() qui, sous les couvertures, appelle CoGetClassObject() pour obtenir un objet qui implémente IClassFactory, puis appelle IClassFactory :: CreateInstance(). Cette implémentation doit instancier votre objet COM avec des indicateurs définis pour un client non autorisé.

Questions connexes