更新: この質問は、2010 年 1 月の私のブログの主題でした。素晴らしい質問をありがとう! 見る：
https://blogs.msdn.microsoft.com/ericlippert/2010/01/14/why-cant-i-access-a-protected-member-from-a-derived-class-part-six/
MyDerived がタイプ YourDerived または Base の変数を介して Base の保護されたメンバーにアクセスできるようにすることによって引き起こされる問題の例はありますが、タイプ MyDerived または MySuperDerived の変数を介してそれらにアクセスする場合にはまだ存在しませんか?
私はあなたの質問にかなり混乱していますが、喜んで試してみます。
私の理解が正しければ、あなたの質問は 2 つの部分に分かれています。まず、派生型の少ない型を介して保護されたメソッドを呼び出すことの制限を正当化する攻撃の軽減策は何ですか? 第二に、なぜ同じ正当化が、同等に派生した、またはより派生した型での保護されたメソッドの呼び出しを防止する動機にならないのでしょうか?
最初の部分は簡単です:
// Good.dll:
public abstract class BankAccount
{
abstract protected void DoTransfer(BankAccount destinationAccount, User authorizedUser, decimal amount);
}
public abstract class SecureBankAccount : BankAccount
{
protected readonly int accountNumber;
public SecureBankAccount(int accountNumber)
{
this.accountNumber = accountNumber;
}
public void Transfer(BankAccount destinationAccount, User user, decimal amount)
{
if (!Authorized(user, accountNumber)) throw something;
this.DoTransfer(destinationAccount, user, amount);
}
}
public sealed class SwissBankAccount : SecureBankAccount
{
public SwissBankAccount(int accountNumber) : base(accountNumber) {}
override protected void DoTransfer(BankAccount destinationAccount, User authorizedUser, decimal amount)
{
// Code to transfer money from a Swiss bank account here.
// This code can assume that authorizedUser is authorized.
// We are guaranteed this because SwissBankAccount is sealed, and
// all callers must go through public version of Transfer from base
// class SecureBankAccount.
}
}
// Evil.exe:
class HostileBankAccount : BankAccount
{
override protected void Transfer(BankAccount destinationAccount, User authorizedUser, decimal amount) { }
public static void Main()
{
User drEvil = new User("Dr. Evil");
BankAccount yours = new SwissBankAccount(1234567);
BankAccount mine = new SwissBankAccount(66666666);
yours.DoTransfer(mine, drEvil, 1000000.00m); // compilation error
// You don't have the right to access the protected member of
// SwissBankAccount just because you are in a
// type derived from BankAccount.
}
}
Dr. Evil があなたのスイスの銀行口座から 1... 100 万... ドル... を盗もうとする試みは、C# コンパイラによって阻止されました。
明らかにこれはばかげた例であり、明らかに、完全に信頼されたコードは、型に対して必要なことを何でも実行できます。完全に信頼されたコードは、デバッガーを起動し、実行中にコードを変更できます。完全な信頼とは、完全な信頼を意味します。この方法で実際のセキュリティ システムを実際に設計しないでください。
しかし、私が言いたいのは、ここで失敗した「攻撃」は、誰かが SecureBankAccount によって設定された不変条件を迂回して、SwissBankAccount のコードに直接アクセスしようとしているということです。
これで最初の質問に答えられると思います。不明な場合はお知らせください。
2 番目の質問は、「SecureBankAccount にもこの制限がないのはなぜですか?」です。私の例では、SecureBankAccount は次のように述べています。
this.DoTransfer(destinationAccount, user, amount);
明らかに「これ」は、SecureBankAccount 型またはそれ以上の派生型です。これは、新しい SwissBankAccount を含む、より派生した型の任意の値である可能性があります。SecureBankAccount は、SwissBankAccount の不変条件をめぐってエンドランを行っているのではないでしょうか?
そのとおり！そのため、SwissBankAccount の作成者は、基本クラスが行うすべてのことを理解する必要があります。あるクラスから意のままに派生して、最高のものを期待することはできません! 基本クラスの実装は、基本クラスによって公開された保護されたメソッドのセットを呼び出すことができます。それから派生させたい場合は、そのクラスのドキュメントまたはコードを読み、保護されたメソッドが呼び出される状況を理解し、それに応じてコードを記述する必要があります。派生は、実装の詳細を共有する方法です。派生元の実装の詳細を理解していない場合は、派生しないでください。
さらに、基本クラスは常に派生クラスの前に記述されます。基本クラスは稼働しておらず、変更も加えられていません。おそらく、クラスの作成者が、将来のバージョンでこっそり壊れようとしないことを信頼していると思われます。(もちろん、基底クラスへの変更は常に問題を引き起こす可能性があります。これは脆弱な基底クラスの問題の別のバージョンです。)
2 つのケースの違いは、基本クラスから派生する場合、選択した1 つのクラスの動作を理解して信頼できることです。それは扱いやすい作業量です。SwissBankAccount の作成者は、保護されたメソッドが呼び出される前に、SecureBankAccount が不変であることを保証するものを正確に理解する必要があります。しかし、考えられるすべてのいとこクラスのすべての可能な動作を理解し、信頼する必要はありません。それはたまたま同じ基本クラスから派生したものです。それらの人は誰でも実装でき、何でもできます。呼び出し前の不変条件を理解する能力はまったくないため、機能する保護されたメソッドを正常に作成することはできません。したがって、私たちはあなたを悩ませず、そのシナリオを許可しません.
さらに、潜在的により派生したクラスのレシーバーで保護されたメソッドを呼び出せるようにする必要があります。私たちがそれを許しておらず、ばかげたことを推測したとしましょう。より派生する可能性のあるクラスのレシーバーで保護されたメソッドを呼び出すことを禁止した場合、どのような状況で保護されたメソッドが呼び出される可能性がありますか? その世界で保護されたメソッドを呼び出すことができるのは、シールされたクラスから独自の保護されたメソッドを呼び出す場合だけです! 事実上、保護されたメソッドはほとんど呼び出され、呼び出された実装は常に最も派生したものになります。その場合の「保護」のポイントは何ですか？あなたの「保護された」は、「プライベートであり、封印されたクラスからのみ呼び出すことができる」と同じことを意味します。それはそれらをかなり役に立たなくするでしょう。
したがって、両方の質問に対する簡単な答えは、「そうしなければ、保護されたメソッドを使用することはまったく不可能になるからです」です。低派生型による呼び出しを制限します。そうしないと、不変条件に依存する保護されたメソッドを安全に実装することが不可能になるからです。潜在的なサブタイプを介した呼び出しを許可します。これを許可しない場合、呼び出しはほとんど許可されないためです。
それはあなたの質問に答えていますか？