7

我目前使用NInject将接口绑定到具体类型并将它们注入到我的类中。但是，据我了解，这是一个运行时事务。对我来说，如果有人想改变我的应用程序的行为，这似乎是一个攻击点。

有什么可以让我将我的依赖注入 IoC 迁移到编译时（阅读：构建后 IL 编织/替换）？

详细说明

在我的代码中，我设置了一个绑定

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

与 ctorFoo(Bar dependency)

在我的应用程序的根目录（在启动时）我解析了图表

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

假设我没有服务定位器（反模式对吗？）。所以我已经没有用kernel了。

现在我想要一个“post-build release-compile”，用实例替换内核的解析引擎，或者引用常量/单例等。这样虽然我的代码看起来像这样；

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

实际上，在我的最终构建阶段更换 IL 后，它看起来像这样：

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

并且不再引用 NInject 了。

我对这个问题的理由是我正在使用Fody来 IL Weave 我所有的 PropertyChanged raisers，我想知道是否可以为依赖注入做类似的事情。

4

3 回答 3

8

一般来说，从安全角度来看，使用 DI 容器不会对您的应用程序构成任何额外威胁。

当您编写服务（例如 Web 服务或网站）应用程序时，攻击者只能在该应用程序或服务器已被破坏时更改应用程序的 DI 配置行为。发生这种情况时，服务器应被视为丢失（您必须重新格式化该服务器或将其完全丢弃）。DI 不会使情况变得更糟，因为 DI 容器通常不允许从外部更改行为。你将不得不做一些非常奇怪的事情来实现这一点。

另一方面，对于在用户机器上运行的应用程序，您应该始终认为该应用程序受到了破坏，因为攻击者可以反编译您的代码，在运行时更改行为等。同样，DI 不会使情况变得更糟，因为您只能保护自己免受对服务边界的攻击。该客户端应用程序必须与服务器通信，并且存储贵重资产的位置在服务边界内。例如，您永远不应该将帐户密码存储在客户端的 DLL 中。不管它是否加密。

然而，使用 DI 可以使攻击者更容易更改客户端应用程序的行为，尤其是当您在 XML 中配置所有内容时。但这适用于您存储在配置文件中的所有内容。如果那是你唯一的防线（无论有没有 DI），你还是完蛋了。

如果有人想改变我的应用程序的行为，这似乎是一个攻击点

请注意，任何应用程序都可以被反编译、更改和重新编译。无论它是托管的（.NET、Java）还是非托管的（C++），或者是否被混淆，都无关紧要。同样，从安全的角度来看，您执行运行时 DI 还是编译时 DI 并不重要。如果这是一个问题，请不要在您无法控制的机器上部署该代码。

于 2013-03-22T11:18:47.897 回答
4

正如所讨论的，您引用的这样做的原因并没有加起来。然而，Philip Laureano（Linfu 的作者）前段时间做了一个Hiro 项目，该项目进行了预部署 DI。不知道有没有去哪里...

于 2013-03-23T09:54:02.220 回答
2

我正在使用源生成器为.Net开发一个编译时IOC容器：

https://github.com/YairHalberstadt/stronginject

https://www.nuget.org/packages/StrongInject/

有了它，您可以执行以下操作：

using StrongInject;

[Registration(typeof(Foo), typeof(IFoo))]
[Registration(typeof(Bar), Scope.SingleInstance)]
public class Container : IContainer<IFoo> {}

public static class Program
{
    public static void Main()
    {
        new Container().Resolve(foo => //use foo here);
    }
}

如果无法解决IFoo并避免使用反射，这将为您提供编译时错误和警告。

于 2020-08-12T11:39:51.107 回答