7

私は現在、NInjectを使用してインターフェースを具象型にバインドし、それらをクラスに注入しています。ただし、これはランタイムの問題であることを理解しています。私には、誰かが私のアプリケーションの動作を変更したい場合、それは攻撃のポイントのように思えます。

依存性注入 IoC をコンパイル時に移行できるようにするものはありますか (読み取り: ビルド後の IL ウィービング/置換)。

詳しく説明する

私のコードでは、バインディングをセットアップします

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

付きFoo(Bar dependency)

アプリケーションのルート (起動時) でグラフを解決します

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

サービスロケーターがないと仮定します(とにかくアンチパターンですよね? )。だからもう使い物にならkernelない。

今、私は、カーネルの解決エンジンをインスタンシエーター、または定数/シングルトンへの参照などに置き換える「ビルド後のリリースコンパイル」が必要です。

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

実際、最終ビルド段階で IL を交換すると、次のようになります。

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

また、NInject への参照はもうありません。

この質問に対する私の論理的根拠は、Fodyを使用してすべての PropertyChanged レイザーを IL Weave しているということです。

4

3 に答える 3

8

一般に、セキュリティの観点から、DI コンテナーを使用しても、アプリケーションに余分な脅威が生じることはありません。

サービス (Web サービスや Web サイトなど) アプリケーションを作成する場合、攻撃者は、そのアプリケーションまたはサーバーが既に侵害されている場合にのみ、アプリケーションの DI 構成された動作を変更できます。これが発生した場合、サーバーは失われたと見なされます (そのサーバーを再フォーマットするか、完全に破棄する必要があります)。通常、DI コンテナーでは外部から動作を変更できないため、DI によってこれが悪化することはありません。これを実現するには、非常に奇妙なことをしなければなりません。

一方、ユーザーのマシンで実行されるアプリケーションの場合、攻撃者がコードを逆コンパイルしたり、実行時の動作を変更したりできるため、常にそのアプリケーションが侵害されていると考える必要があります。繰り返しますが、DI はこれを悪化させません。サービス境界での攻撃からのみ保護できます。そのクライアント アプリはサーバーと通信する必要があり、貴重な資産を保存する場所はサービスの境界内にあります。たとえば、アカウントのパスワードをクライアントの DLL 内に保存しないでください。暗号化されているかどうかは関係ありません。

ただし、DI を使用すると、特にすべてを XML で構成する場合に、攻撃者がクライアント アプリケーションの動作を変更しやすくなる可能性があります。ただし、構成ファイルに保存するすべてのものに当てはまります。そして、それがあなたの唯一の防衛線である場合（DIの有無にかかわらず）、とにかくめちゃくちゃです.

誰かが私のアプリケーションの動作を変更したい場合、それは攻撃のポイントのようです

どのアプリケーションも逆コンパイル、変更、および再コンパイルできることに注意してください。管理されている (.NET、Java) かどうか (C++)、または難読化されているかどうかは問題ではありません。繰り返しになりますが、セキュリティの観点からは、実行時 DI を行うかコンパイル時 DI を行うかは問題ではありません。これが問題になる場合は、制御できないマシンにそのコードをデプロイしないでください。

于 2013-03-22T11:18:47.897 に答える
4

説明したように、これを行う理由として挙げられたものは合計されません。ただし、Philip Laureano (Linfu の作成者) は、デプロイ前の DI を行うHiro プロジェクトを以前に行いました。どこかに行ったかどうかはわかりません...

于 2013-03-23T09:54:02.220 に答える