← ナレッジベースに戻る← 前の質問次の質問 →
JavaProgrammingJava Developer

Javaのネイティブシリアル化プロトコル内で、攻撃者が主張されるシングルトンの複数のインスタンスをインスタンス化できるメカニズムは何であり、デシリアライズ時にインスタンス制御を保証する防御フックメソッドはどれですか？

Hintsage AIアシスタントで面接を突破

質問の答え

質問の歴史: JavaはJDK 1.1でObjectOutputStreamとObjectInputStream APIを通じてネイティブバイナリシリアル化を導入し、オブジェクトグラフを永続化またはネットワーク転送のためにバイトストリームにフラット化するプロトコルを確立しました。仕様では、再構築中にObjectInputStreamがsun.misc.Unsafeまたは直接リフレクションを使用してターゲットオブジェクトのメモリを確保し、コンストラクタを完全にバイパスすることを義務付けています。この設計選択は、インスタンス化を制限するためにプライベートコンストラクタに依存するシングルトンパターンと根本的に矛盾します。

問題: クラスがSerializableを実装すると、デシリアライズフレームワークはコンストラクタロジックを実行することなく、allocateInstanceを呼び出して新しいインスタンスを作成します。プライベートコンストラクタと静的ファクトリを使用して唯一の存在を強制するように設計されたシングルトンの場合、この侵入によりヒープ内に二つ目の異なるオブジェクトが生成され、アイデンティティ等価保証が破られます。その結果、グローバルであるべき静的状態が複数のインスタンスに分断され、一意の制御ポイントに依存するアプリケーションにおいて一貫性のない動作を引き起こします。

解決策: readResolveメソッドは、Serializable契約で定義されたデシリアライズ後のフックとして機能し、クラスがデシリアライズされたオブジェクトをカノニカルインスタンスに置き換えることを可能にします。protected Object readResolve() throws ObjectStreamExceptionという正確なシグネチャを持つメソッドを宣言することで、開発者は新しく作成された重複を intercept し、静的なINSTANCEフィールドを返すことができます。この置き換えはストリーム解決プロセス内でシームレスに発生し、スプリアスオブジェクトをガベージコレクションに廃棄しながらシングルトンの整合性を保持します。

public class Configuration implements Serializable {
    private static final Configuration INSTANCE = new Configuration();
    private String dbUrl;

    private Configuration() {
        this.dbUrl = System.getenv("DB_URL");
    }

    public static Configuration getInstance() {
        return INSTANCE;
    }

    protected Object readResolve() {
        return INSTANCE;
    }
}

生活の状況

DatabaseConfigシングルトンが接続プールパラメータと認証情報を管理する分散マイクロサービスアーキテクチャを考えてみてください。このサービスは、この構成をRedisのような分散キャッシュにシリアル化して、展開後のコールドスタートを加速します。水平スケーリングイベントが発生すると、新しいサービスインスタンスはこのバイナリブロブを取得してデシリアライズし、意図しない形でデフォルトのデシリアライズプロトコルをトリガーします。

防御策がない場合、ObjectInputStreamはJVMが保持する静的INSTANCEとは異なる別のDatabaseConfigオブジェクトをインスタンス化します。この重複はスプリットブレインシナリオを生み出し、新しいインスタンスは静的構造中に実行された初期化フックを欠いているため、古いデータベースエンドポイントや未初期化の認証プロバイダにポイントする可能性があります。アプリケーションはその後、重複した接続プールが生成され、データベースの接続上限を超え、クラスタ全体でカスケード障害を引き起こすというリソースリークに苦しむことになります。

一つのアプローチは、シングルトンをEnum型に変換し、JVMの仕様によりenumがシングルトンであることを保証し、設計によってシリアル化抵抗力を持つことを活用します。利点: シリアル化メカニズムは、enum定数を名前検索によって自動的に処理し、インスタンス作成を完全に防ぎます。欠点: Enumは抽象クラスを拡張できず、アーキテクチャ上の柔軟性が制限され、遅延初期化のセマンティクスも欠けるため、クラス初期化中に重い構成が早期にロードされる可能性があります。

あるいは、既存のクラス内にreadResolveメソッドを実装することで、デシリアライズが完了した後にカノニカルINSTANCEを返すことができます。利点: これにより、継承階層を保持し、重複作成を明示的に防ぐ複雑な初期化ロジックをサポートします。欠点: 開発者がこのメソッドを見逃すことが多く、シングルトンのインスタンス化が遅延初期化される場合には注意深い同期が必要です。

第三の選択肢は、Externalizableに切り替え、writeExternalやreadExternalを介してシリアル化ストリームを手動で制御して、完全な状態ではなく構成識別子のみを記述することです。利点: これはオブジェクト内部をシリアル化することを拒否するため、インスタンス作成攻撃を防ぎます。欠点: これは大幅なボイラープレートコードを導入し、アプリケーションバージョン間でのストリームフォーマットの後方互換性を維持する必要があり、メンテナンスの負担が増加します。

エンジニアリングチームは、readResolveを実装して静的INSTANCEを返す解決策2を選択しました。これは、DatabaseConfigが共有監査ログ機能のために抽象クラスBaseConfigurationを拡張する必要があったため、enumが不適切であったからです。このアプローチは、シリアライズ中に重複インスタンス脆弱性に対する堅牢な保護を確保するために、デシリアライズ中の同期の懸念を避けるために早期初期化と組み合わせました。これにより、最小限のコード侵入と堅牢な保護をバランスさせることができました。

実装後、負荷テストにより、キャッシュされた構成をデシリアライズすると同じオブジェクト参照が戻され、重複した接続プールが排除されることが確認されました。サービスはデータベース接続の枯渇なく水平スケーリングしました。また、メモリプロファイリングにより、ガベージコレクションサイクル後に追加のDatabaseConfigインスタンスがヒープに残っていないことが検証されました。この解決策は、シングルトン契約をシリアル化攻撃から強化しつつ、アーキテクチャの拡張性を維持しました。

候補者が見落としがちなこと

readObjectとreadResolveの相互作用がデシリアライズされたシングルトンの一時フィールド状態にどのように影響するか？

readObjectはストリームからオブジェクトの全状態を再構築し、一時フィールドのカスタム初期化ロジックを実行した後、JVMがオブジェクトを完全と見なす前に実行されます。次にreadResolveが実行されて、異なるカノニカルインスタンスを返す場合、JVMは完全に再構築された一時オブジェクトを破棄し、readObject中に計算された一時値も含まれます。開発者は、必要に応じて一時状態をカノニカルインスタンスに手動でコピーする必要がありますが、真のシングルトンに対しては、一時フィールドは通常カノニカル状態から再導出されるべきであり、シリアライズされたストリームからは導出されるべきではありません。

Externalizableを実装することがreadResolveによって提供される保護を回避する理由は何ですか？

Externalizableインターフェースは、シリアル化制御をwriteExternalとreadExternalを介してクラスに完全に移行し、readResolveをチェックする標準のObjectInputStreamのdefaultReadObjectメカニズムをバイパスします。readExternalが新しく構築されたインスタンスをポピュレートする際、ストリームはこれを最終オブジェクトとして扱い、readResolveを呼び出すことなく直接返します。したがって、Externalizableを使用する開発者は、通常、InvalidObjectExceptionをスローするか、一時的に状態をシングルトンにマージすることによって、手動でインスタンス制御ロジックをreadExternal内に実装する必要があります。

Java Recordタイプ内でreadResolveが正しく機能しないのは何ですか？

レコードはそのカノニカルコンストラクタとコンポーネントアクセサメソッドを通じてシリアル化およびデシリアライズされるため、伝統的なクラスで使用されるリフレクションベースのフィールドポピュレーションを介してオブジェクトが作成されることはありません。つまり、デシリアライズプロセスは、readResolveが置き換えることができる空のシェルオブジェクトを決して生成しません。JVMは、デシリアライズされたコンポーネント値を使ってレコードをカノニカルコンストラクタを呼び出すことによって再構築し、インスタンスは作成されると同時に完全に構築され、不変になります。レコードでシングルトンのような動作を実現するためには、開発者は**@Serial**でマークされた静的ファクトリメソッドを使用するか、readResolveを介した厳密なインスタンス制御が必要な場合は、標準クラスを好む必要があります。