Kompilierzeit/Post-Build Dependency Injection IoC?

Question

Ich verwende derzeit NInject, um Schnittstellen an konkrete Typen zu binden und diese in meine Klassen einzufügen. Ich gehe jedoch davon aus, dass dies eine Laufzeit-Angelegenheit ist. Für mich scheint es ein Angriffspunkt zu sein, wenn jemand das Verhalten meiner Anwendung ändern wollte.

Gibt es irgendetwas, was es mir erlauben würde, meine Dependency-Injection-IoC zur Kompilierzeit zu migrieren (Lesen: Post-Build IL Weaving/Replacement)?

---

Um

In meinem Code ich ein Setup-Bindung

Bind<IFoo>().To<Foo>() 
Bind<Bar>().ToSelf().InSingletonScope(); 

mit Ctor Foo(Bar dependency)

An der Wurzel meiner Anwendung Elaborate (bei Inbetriebnahme) I Auflösen des Graphen

var foo = kernel.Get<IFoo>(); 

Angenommen ich keine Service-Locators (anti-pattern anyway right?) haben. Also habe ich keine Verwendung mehr für kernel.

Jetzt möchte ich eine "post-build release-compile" haben, die die Auflösungsengine des Kernels durch Instanciator oder Verweise auf constant/singleton usw. ersetzt. So, dass mein Code so aussieht;

var foo = kernel.Get<IFoo>(); 

In Wirklichkeit nach IL Ersatz in meinem letzten Build-Bühne, sieht es wie folgt aus:

var bar = new Bar(); 
var foo = new Foo(bar); 

Und es gibt keinen Hinweis auf ninject mehr.

Meine rationale für diese Frage ist, dass ich Fody IL Weave alle meine PropertyChanged Raiser verwenden und ich frage mich, ob es möglich wäre, etwas Ähnliches für Dependency Injection zu tun.

Answer 1

Wie bereits erwähnt, addieren sich Ihre angeführten Gründe dafür nicht. Philip Laureano (Linfu Autor) hat jedoch eine Hiro project einige Zeit zurück, die vor der Bereitstellung DI tut. Keine Ahnung, ob es irgendwohin ging ...

Answer 2

Aus Sicht der Sicherheit im Allgemeinen die Verwendung eines DI-Container keine zusätzliche Gefahren für Ihre Anwendung nicht darstellen.

Wenn Sie eine Dienstanwendung (z. B. Webdienst oder Website) schreiben, kann der Angreifer nur das konfigurierte DI-Verhalten der Anwendung ändern, wenn diese Anwendung oder dieser Server bereits kompromittiert wurde. Wenn dies passiert, sollte der Server als verloren betrachtet werden (Sie müssen diesen Server neu formatieren oder wegwerfen). DI macht das nicht schlechter, da ein DI-Container typischerweise nicht erlaubt, das Verhalten von außen zu verändern. Sie müssen etwas sehr Seltsames tun, um dies zu erreichen.

Für eine Anwendung, die auf dem Computer des Benutzers ausgeführt wird, sollten Sie diese Anwendung jedoch immer als kompromittiert betrachten, da ein Angreifer Ihren Code dekompilieren, das Verhalten zur Laufzeit ändern kann. DI wiederum nicht Dies ist umso schlimmer, da Sie sich nur vor Angriffen auf die Dienstgrenze schützen können. Diese Client-App muss mit dem Server kommunizieren und der Speicherort für Ihre wertvollen Ressourcen liegt innerhalb der Dienstgrenzen. Zum Beispiel sollten Sie niemals ein Konto-Passwort in einer DLL auf dem Client speichern. Egal ob es verschlüsselt ist oder nicht.

Die Verwendung von DI kann es einem Angreifer jedoch leichter machen, das Verhalten einer Clientanwendung zu ändern, insbesondere wenn Sie alles in XML konfigurieren. Aber das gilt für alles, was Sie in der Konfigurationsdatei speichern. Und wenn das deine einzige Verteidigungslinie ist (entweder mit oder ohne DI), bist du sowieso verschraubt.

es scheint wie ein Angriffspunkt, wenn jemand kann das Verhalten meiner Anwendung

Bitte beachten Sie, dass jede Anwendung werden dekompilierten, verändert und neu kompiliert ändern wollte. Es spielt keine Rolle, ob es verwaltet (.NET, Java) oder nicht (C++), oder verschleiert oder nicht. Auch aus Sicherheitsgründen spielt es keine Rolle, ob Sie Laufzeit-DI oder Kompilierungszeit-DI ausführen. Wenn dies ein Problem ist, stellen Sie diesen Code nicht auf Computern bereit, für die Sie keine Kontrolle haben.