11

リフレクションを使用してプライベートメンバーと内部メンバーを操作できることを確認しました。また、 「封印された」クラスはそうでないクラスよりも安全であると言われているのを見ました。

「パブリック、プロテクト、内部、プライベート、抽象、封印、読み取り専用」の修飾子は、設計とAPIの使用に関する紳士協定以上のものであり、リフレクションにアクセスできる限り破られる可能性がありますか？また、ハッカーがAPIを呼び出すコードをすでに実行している場合、ゲームはすでに失われていますね。

以下は他のどのクラスよりも安全ですか？

//private class
sealed class User
{
    private string _secret = "shazam";
    public readonly decimal YourSalary;
    public string YourOffice{get;};
    private DoPrivilegedAction()
    {
    }
}
4

5 に答える 5

29

まず、あなたの質問に答えるために：セキュリティシステムは、良いユーザーを悪いコードから保護するように設計されています。良いコードを悪いユーザーから保護するように明示的に設計されていません。アクセス制限は、部分的に信頼された敵対的なコードによるユーザーへの攻撃を軽減します。敵対的なユーザーからのコードへの攻撃を軽減するものではありません。脅威が敵対的なユーザーがあなたのコードを取得することである場合、あなたは大きな問題を抱えています。セキュリティシステムは、その脅威をまったく軽減しません。

次に、前述の回答のいくつかに対処するには、リフレクションとセキュリティの完全な関係を理解するには、細部に注意を払い、CASシステムの細部を十分に理解する必要があります。反省のためにセキュリティとアクセスの間に関係がないと述べている以前に投稿された回答は誤解を招き、間違っています。

はい、リフレクションを使用すると、「可視性」の制限をオーバーライドできます（場合によっては）。これは、アクセスとセキュリティの間に関係がないことを意味するものではありません。接続は、リフレクションを使用してアクセス制限を無効にする権利が、複数の方法でCASシステムに深く関係していることです。

まず、これを任意に行うには、CASシステムによってコードにプライベートリフレクション許可を付与する必要があります。これは通常、完全に信頼できるコードにのみ付与され、結局のところ、すでに何でも実行できます。

次に、新しい.NETセキュリティモデルで、アセンブリAにCASシステムによってアセンブリBの付与セットのスーパーセットが付与されているとします。このシナリオでは、アセンブリAのコードは、リフレクションを使用してBの内部を監視できます。

第三に、動的に生成されたコードをミックスに投入すると、事態は非常に複雑になります。「SkipVisibility」と「RestrictedSkipVisibility」の仕組み、および実行時にコードが吐き出されるシナリオでのリフレクション、アクセス制御、セキュリティシステム間の相互作用の変化についての説明は、私よりも時間とスペースがかかります。利用可能です。詳細が必要な場合は、ShawnFarkasのブログを参照してください。

于 2009-05-21T16:09:01.400 に答える
12

アクセス修飾子はセキュリティではなく、優れた設計です。クラスとメソッドの適切なアクセスレベルは、優れた設計原則を推進/実施します。リフレクションは、理想的には、それを使用することの利便性が、（もしあれば）最良の設計慣行に違反するコストよりも多くの有用性を提供する場合にのみ使用されるべきです。クラスの封印は、開発者がクラスを拡張してその機能を「破壊」するのを防ぐ目的でのみ機能します。封印クラスの有用性についてはさまざまな意見がありますが、私はTDDを行っており、封印されたクラスをモックするのは難しいので、できるだけ避けています。

セキュリティが必要な場合は、侵入が発生した場合でも、悪意のあるユーザーが侵入したり、機密情報を検査から保護したりすることを防ぐコーディング手法に従う必要があります。侵入防止、侵入検知、暗号化、監査などは、アプリケーションを保護するために使用する必要のあるツールの一部です。制限付きアクセス修飾子とシーリングクラスの設定は、アプリケーションのセキュリティであるIMOとはほとんど関係がありません。

于 2009-05-21T01:39:46.870 に答える
6

いいえ。これらはセキュリティとは何の関係もありません。反射はそれらすべてを壊します。

于 2009-05-21T01:33:07.103 に答える
1

リフレクションとセキュリティに関するコメントについて-mscorlib.dllには、ネイティブWindows関数を呼び出す多くの内部型とメンバーがあり、悪意のあるアプリケーションがリフレクションを使用してそれらを呼び出すと、悪意を引き起こす可能性があることを考慮してください。信頼できないアプリケーションは通常、ランタイムによってこれらの権限を付与されないため、これは必ずしも問題ではありません。これ（およびいくつかの宣言型セキュリティチェック）は、mscorlib.dllバイナリがその型をあらゆる種類の信頼できるコードと信頼できないコードに公開する方法ですが、信頼できないコードはパブリックAPIを回避できません。

これは実際には、リフレクションとセキュリティの問題の表面をかじっただけですが、正しい道をたどるのに十分な情報であるといいのですが。

于 2009-05-21T02:18:42.643 に答える
1

私は常に、必要最小限のアクセスに物事を固定しようとします。tvanfossonが述べたように、それは実際にはセキュリティよりも設計に関するものです。

たとえば、インターフェイスをパブリックにし、実装を内部にし、次にパブリックファクトリクラス/メソッドを作成して実装を取得します。これにより、コンシューマーは実装ではなく、常にインターフェースとして入力する必要があります。

そうは言っても、開発者はリフレクションを使用して、実装タイプの新しいインスタンスを実際にインスタンス化できます。彼/彼女を止めるものは何もありません。しかし、私がデザインに違反することを少なくともいくらか困難にしたことを知って、私は休むことができます。

于 2009-05-21T02:22:44.693 に答える