匿名メソッド（Action <>、Func <>）をパラメータとして受け入れることに対するセキュリティの影響は何ですか？

Question

C＃の匿名メソッド（Action<>、Func<>）を使用したり渡したりするときに考慮する必要のあるセキュリティ上の意味は何ですか？

Action<>/Func<>を受け入れる方法は、外部コードをプログラムに注入する可能性があるようです。記録のために、私は、注入されたメソッドや関数は、任意のメモリアクセスの意味で本質的に安全でないことを行うことができないことを理解していますが、私はそれが呼び出しコードを呼び出すことができると思います。任意の.Netフレームワーク機能、データの破損、またはアプリケーションの誤動作の原因となることがあります。

この仮説は間違っていますか？

そうでない場合は、これらをロックするために何を行う必要がありますか？さらに、メソッドまたは関数に渡され、期待される形式であることを確認したり、特定の型および名前空間へのアクセスを制限したりするために、 /Func<>を検証する方法はありますか？

また、適切な用語を使用していないと、私はまだ学んでいます。

Answer 1

>/FUNC <アクション<を受け入れる方法>完全に間違っているプログラム

に注入される外国人のコードの潜在的な方法であると思われます。関数を呼び出してデリゲートを渡す人は、定義上、プログラム内ですでにコードを実行しています。
デリゲートを渡しているコードは、必要なものを何でも実行できます。同じAppDomain内にセキュリティ境界を設定することはできません。 （.Netの以前のバージョンでは、これを実行しようとしたコードアクセスセキュリティがありましたが、良い考えではありませんでした）

しかし、予期しない再入可能性があり、スレッドセーフなコードで問題を引き起こす可能性があります。

Answer 2

がシナリオ戻る

CASポリシーがまだ使用されていた（例えばメディアの信頼ASP.NET）安全、信頼できないコードを呼び出すことができませんでしたコードの信頼された部分がある場合は、私が本当に求めていますスタックアサートが存在するとき。たとえば、

new SecurityPermission(Unrestricted).Assert() 

の場合、セキュリティチェックスタックウォークはこの時点で停止します。これにより、信頼できないコードが検出されなくなる可能性があります。 See the docs for Assert.

シナリオは難しいので、私はここでやや漠然としています。それは時代遅れです。

---

同じプロセス内に信頼境界がない場合、呼び出し側はコードをどこかに注入しなくてもすべての権限を既に持っています。その必要はありません。