安全でないデシリアライゼーション対策｜信頼できないデータをオブジェクトに復元しない設計

安全でないデシリアライゼーション（insecure deserialization・CWE-502）は、受け取ったデータを「オブジェクトに戻す」処理そのものが攻撃の実行になる欠陥です。多くの言語は、メモリ上のオブジェクトをバイト列に変換（シリアライズ）し、後で元のオブジェクトに戻す（デシリアライズ）仕組みを持ちます。この「戻す」処理に信頼できないバイト列を渡すと、戻す最中にクラスの特別なメソッドが呼ばれ、攻撃者が用意した処理の連鎖（ガジェットチェーン）を通じてコード実行まで届きます。

本記事は連載「事故から逆算するWebセキュリティ」の第26回です。セッションやキャッシュ、インポート機能などで「オブジェクトを保存して後で復元する」コードを書く開発者に向けて、何が危険で、どう防ぐかを整理します。セキュリティ全体の地図は「サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説」にまとめています。

関連して、復元したオブジェクトからコマンドを組み立てて実行すればOSコマンドインジェクションに、セッションの格納方式が甘ければセッション管理とCookieの属性の問題に接続します。デシリアライゼーションは、その入口で「データ」を「生きたオブジェクト」に変えてしまうところが起点です。

安全でないデシリアライゼーションはどこで起きるか

影響を受けるのは、「保存したオブジェクトを後で復元する」処理です。言語やフレームワークを問わず、次の経路が候補になります。

・言語ごとの復元API：PHP unserialize()、Python pickle.loads()、Java ObjectInputStream.readObject()、Ruby Marshal.load / YAML.load、.NET BinaryFormatter
・セッション・Cookie：シリアライズしたオブジェクトをセッションやCookieに格納する。署名が無い、または署名鍵が漏れると偽造できる
・キャッシュ・キュー・RPC：Memcached/Redis・メッセージキュー・RPC で、オブジェクトをシリアライズして往復させている経路
・アップロード・インポート：設定や状態の復元、インポート機能が、ユーザー由来のシリアライズ済みデータを読む

セッションの格納は特に注意が要ります。たとえば Rails は、セッションをシリアライズして署名・暗号化した上でCookieに入れますが、その署名鍵（secret_key_base）が漏れると、攻撃者が任意のオブジェクトを詰めたセッションを正当なものとして偽造でき、復元時のコード実行に直結します。直近でも、Active Storage の脆弱性で secret_key_base などが読まれうる事例（Rails Active Storage の緊急脆弱性）が公表されました。鍵の流出が「ただの情報漏えい」で終わらず、デシリアライゼーション経由のRCEに繋がる理由がここにあります。

なぜ復元前の検証や記号のチェックでは防げないのか

いちばんの誤解は、「復元したオブジェクトの中身を検証すれば安全」という考えです。これは順番の問題で破られます。

・復元中に処理が走る：多くの言語は、復元の最中にクラスの特別なメソッド（PHP の __wakeup/__destruct、Java の readObject、Python pickle の __reduce__）を呼ぶ。検証コードに到達した時点で手遅れ
・ガジェットチェーン：攻撃者は、アプリや依存ライブラリに元からあるクラスの組み合わせ（ガジェット）を連鎖させて目的を達する。単一の「危ないクラス」を禁止するだけでは足りない
・型の取り違え：期待した型と違うオブジェクトを渡され、想定外のメソッドが呼ばれる（オブジェクトインジェクション）
・署名が無ければ改ざん自在：シリアライズ済みデータに署名が無ければ、中身を好きに差し替えられる

要は、守るべきは「復元後の中身」ではなく、「信頼できないバイト列を、そもそもオブジェクトに復元する経路」そのものです。攻撃者が送れる入力と、守りが無いときに起こることを整理すると、問題が「データの中身」ではなく「何に復元するか」にあると分かります。

安全でないデシリアライゼーション対策——データ専用形式で受けて詰め替える

効くのは、記号やクラスを禁止することではなく、信頼境界を越えるデータをネイティブのオブジェクト復元に渡さず、コードを実行しないデータ形式で受けてから、自分で詰め替えることです。OWASP の Deserialization Cheat Sheet も、信頼できないデータのネイティブなデシリアライズを避け、どうしても必要なら完全性チェック（署名）とクラスの制限を併用することを勧めています。順序はこうです。

ポイントは、「何を作るか」を入力に決めさせないことです。JSONなどで受け、スキーマで形を検証し、生成するクラスはコード側が固定して、値だけをプレーンな構造体やDTOに詰めます。これなら、復元の最中に任意のクラスが生成される余地がありません。守り方ごとに、何を防ぎ、何を防がないかを並べます。

いちばん固いのは、信頼境界を越えるデータにネイティブのシリアライズを使わない設計です。どうしても必要なときだけ、署名とクラス許可リストを重ねます。

言語ごとの正しい書き方の要点

どの言語も「危険な復元API」と「安全な代替」が分かれています。公式ドキュメントの対応づけは次のとおりです。

注意点が二つあります。一つ目は、「安全ローダ」も万能ではないことです。たとえば YAML の安全ロードは任意オブジェクト生成を止めますが、許可するクラスを自分で広げすぎれば意味がありません。二つ目は、JSONでも自作の「型名→クラス生成」は危険だということです。入力のフィールドを見てクラスを動的に選ぶ実装は、形式をJSONに変えてもデシリアライゼーションの危険を再発させます。生成するクラスはコード側で固定します。

自分のコードを確認する

ここからは読み取りだけの確認コマンドです。いずれも判定ではなく構成の確認で、ヒットの有無だけでは安全とは言えません。該当箇所を目で追う起点として使います。. は自分のリポジトリのルートに読み替えてください。

まず、危険な復元APIを呼んでいそうな箇所を洗い出します。

grep -rnE "(unserialize|pickle\.loads|readObject|Marshal\.load|BinaryFormatter|yaml\.load\(|node-serialize)" . --include="*.php" --include="*.py" --include="*.java" --include="*.rb" --include="*.cs" --include="*.js" --include="*.ts"

次に、その入力が信頼境界を越えて来ていないか（リクエスト・Cookie・アップロード・キュー由来か）を、ヒット箇所ごとに追います。安全ローダや許可リストが後ろにあるかも確認します。

grep -rnE "(safe_load|allowed_classes|permitted_classes|ObjectInputFilter)" . --include="*.php" --include="*.py" --include="*.java" --include="*.rb"

いずれも、小さなダミーのプロジェクトで陽性（信頼できない入力を危険APIに渡す側）と陰性（データ形式＋スキーマに直した側）の両方を走らせ、拾うべきものを拾い、無いときに何も出ないことを確かめてから載せています。ヒットした箇所が本当に危険かは、その入力の出所と、復元前に署名・形式の検証があるかを、コードを読んで確かめます。ガジェットチェーンの具体的な作り方や攻撃ペイロードは、悪用を助けるため本記事では扱いません。

参照ソース

• OWASP Cheat Sheet Series — Deserialization: https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
• MITRE CWE-502 — Deserialization of Untrusted Data: https://cwe.mitre.org/data/definitions/502.html
• Python 公式ドキュメント — pickle（Warning: 信頼できないデータに使わない）: https://docs.python.org/3/library/pickle.html
• PHP 公式ドキュメント — unserialize（allowed_classes）: https://www.php.net/manual/en/function.unserialize.php
• Java 公式ドキュメント — ObjectInputFilter（Serialization Filtering）: https://docs.oracle.com/en/java/javase/21/core/serialization-filtering1.html