Compilation / post-construction dependency of IoC?

Question

I am currently using NInject to bind interfaces to specific types and inject them into my classes. However, I understand that this is the case on time. For me, this is like an attack point if someone wants to change the behavior of my application.

Is there anything that would allow me to migrate my IoC dependency injection to compile time (Read: post-build IL weaving / replacement)?

---

To complete

In my code I set the binding

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

with ctor Foo(Bar dependency)

At the root of my application (at startup) I enable the graph

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

Suppose I have no service locators ( anti-pattern anyway? ). Therefore, I no longer use kernel .

Now I want to have a "post-build-compilation assembly" that replaces the kernel resolution mechanism with instanciators or constant / singleton links, etc. That way, although my code looks like this;

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

In fact, after replacing IL at my last build stage, it looks like this:

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

And there is no longer a link to NInject.

My rational for this question is that I am using Fody for IL. Check out all my PropertyChanged contributors, and I wonder if something like this could be done for Injection Dependency.

Answer 1

As already mentioned, your reasons for this do not add up. However, Philip Laurano (author of Linfu) did a Hiro project some time ago, which he did before the DI deployment. I have no idea if this went somewhere ...

Answer 2

From a security perspective, in general, using a DI container does not pose any additional threats to your application.

When you write a service application (for example, a web service or a website), an attacker can only change the configured behavior of a DI application when this application or server is already compromised. When this happens, the server should be considered lost (you will have to reformat this server or completely drop it). DI does not make it worse, because the DI container usually does not allow changing behavior outside. You will need to do something very strange for this to happen.

For an application that runs on the user's computer, on the other hand, you should always consider that this application is at risk, since an attacker can decompile your code, change behavior at runtime, etc. Again, DI does not make this worse, since you can only protect yourself from attacks on the service boundary. This client application must interact with the server, and the place to store your valuable assets is within the service boundaries. For example, you should never store an account password inside a DLL on the client. Regardless of whether it is encrypted or not.

However, using DI can make it a little easier for an attacker to modify the behavior of the client application, especially when you configure everything in XML. But this applies to everything that you store in the configuration file. And if this is your only line of defense (with or without DI), you're screwed anyway.

it looks like an attack point if someone wants to change the behavior of my application

Please note that any application can be decompiled, modified and recompiled. It doesn't matter if it was manageable (.NET, Java) or not (C ++), or confusing or not. So, again, from a security point of view, it doesn't matter if you run DI at runtime or DI at compile time. If this is a problem, do not deploy this code on machines that you do not have control over.