2026.05.01 2026.05.14

【デシリアライズ編】信頼できないデータを蘇らせるな｜CTF思考フレームワーク #15

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#15 / 公開中 10記事　→　シリーズ一覧を見る →

デシリアライズ脆弱性は、信頼できないデータをオブジェクトとして復元してしまうことで発生する危険な脆弱性です。Java、PHP、Python、.NETなど、多くの言語やフレームワークで問題になってきました。

シリアライズとは、オブジェクトやデータ構造を保存・送信しやすい形に変換することです。デシリアライズはその逆で、保存されたデータを元のオブジェクトや構造に戻す処理です。このとき、外部から受け取ったデータを無条件に信じて復元すると、想定外のクラスや処理が呼び出される恐れがあります。

注意：この記事で扱う考え方は、必ずCTF・自分の検証環境・許可された診断範囲でのみ使ってください。実在するWebサービスや他人のサーバーに対して試すことは、不正アクセスや業務妨害につながる恐れがあります。

この記事の難易度

難易度：★★★（中級〜上級）　／　所要：10〜12分　／　前提：CTF思考フレームワーク #14

デシリアライズは、外部データをオブジェクトとして復元する処理が危険な入口になることがあるよ⚠️

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：どこに危険な設計がある？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：CTFで見る典型パターン
🛡️ 防御フェーズ：どう守る？
🔑 あわせて見直したい基本対策
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
⚖️ 大事なお約束
📚 次に読みたい
🧪 自分で検証してみる

👀 観察フェーズ：まず何を見る？

まずCookie、フォーム、API、セッション情報に長いエンコード済みデータがないか観察！それがシリアライズ済みデータかもしれないよ🔍

デシリアライズ脆弱性を疑う入口は、「クライアント側に預けたデータを、サーバー側で再び復元しているかどうか」です。Cookie、hiddenフィールド、APIパラメータ、メッセージキュー、キャッシュ、ファイルアップロードなどに、オブジェクト復元処理が隠れていることがあります。

Cookie・セッション・API入力・キャッシュ・キュー・アップロードファイルに、復元処理がないか確認します。読めない長い文字列がある場合は、Base64や独自形式の可能性も疑います👀

見た目はただの文字列でも、サーバー側ではオブジェクトとして復元されていることがあるんだね…😨

🤔 仮説フェーズ：どこに危険な設計がある？

デシリアライズ系の危険ポイントは、言語や形式ごとの復元処理にあるよ。

☕ 仮説①：Java系のオブジェクト復元

Javaのネイティブシリアライズなどで、外部から受け取ったデータをそのまま復元すると、クラスパス上のライブラリや特殊な復元処理が悪用される恐れがあります。特に、古いライブラリや不要な依存関係が残っている環境では注意が必要です。

🐍 仮説②：Python系のpickle利用

Pythonのpickleは、信頼できるデータの保存・復元には便利ですが、外部入力に対して使うべきではありません。復元時に、想定外の処理が実行される可能性があるためです。

🐘 仮説③：PHP系のunserialize利用

PHPのunserializeで外部入力を復元すると、クラスの特殊メソッドや既存オブジェクトの組み合わせにより、想定外の処理につながることがあります。Cookieやフォーム値にシリアライズ済みデータを入れる設計は特に注意が必要です。

💎 仮説④：.NET・Rubyなどの任意型復元

.NETやRubyなどでも、外部入力から任意の型やオブジェクトを復元する設計は危険です。型情報を含むデータを無条件に信用すると、アプリケーションが想定していないクラスや処理に到達することがあります。

デシリアライズ脆弱性の本質は、「外部入力を信頼して、アプリケーション内部のオブジェクトとして復元してしまうこと」です。守る側は、外部から受け取るデータを単なるデータとして扱い、任意のオブジェクトに戻さない設計を優先します。

すべての言語に共通するのは、外部入力をそのままオブジェクトに戻さないってことなんだね💡

🔬 検証フェーズ：どうやって確かめる？

CTFやローカル検証環境では、外部入力がどこで復元されているか、復元時にどの型・クラス・構造が許可されているかを確認します。実サービスに対して試すのではなく、必ず自分の環境や許可されたラボ内で確認してください。

検証では、復元処理の有無・エラー・ログ・許可クラスを見るよ。具体的な攻撃手順より、危険な設計を見抜くのが大事🧪

確認するときは、以下の観点で整理すると分かりやすくなります。

外部入力をオブジェクトとして復元していないか
復元できるクラスや型を制限しているか
署名や改ざん検知があるか
JSONやProtocol Buffersなど、構造を定義しやすい形式へ置き換えられないか
スキーマ検証・型検証を行っているか
復元時の例外やエラーが外部に漏れていないか
依存ライブラリに既知の脆弱性が残っていないか

「どんなペイロードを作るか」より、そもそも復元していいデータなのかを見るのが防御の出発点なんだね🧪

⚔️ 攻撃フェーズ：CTFで見る典型パターン

ここでは実サービスに対して試せる手順ではなく、CTFやローカル検証環境でよく出る「考え方」だけを整理します。具体的な検証は、必ず自分の環境・CTF問題・許可されたラボ内で行ってください。

デシリアライズ脆弱性の代表パターンはこの3つで整理できるよ。

① オブジェクト復元型

信頼できないデータをオブジェクトとして復元することで、想定外のクラスや処理が呼び出されるパターンです。特に、任意の型やクラスを復元できる設計は危険です。

② 状態改ざん型

セッション情報、ユーザー権限、設定値などを含むシリアライズ済みデータが改ざんされ、認可判断や状態管理に影響するパターンです。署名やサーバー側管理がない場合に問題になります。

③ DoS型

複雑すぎるデータ構造や巨大な入力により、復元処理でメモリやCPUを過剰に消費するパターンです。入力サイズやネストの深さにも制限が必要です。

CTF{never_deserialize_untrusted_data}

どの言語でも結論は同じです。信頼できないデータを、任意のオブジェクトとして復元しない。これがデシリアライズ対策の出発点です。

🛡️ 防御フェーズ：どう守る？

デシリアライズの守りは「外部入力をオブジェクトに戻さない」のが最優先！🛡️

🚫 信頼できないデータをデシリアライズしない

最も重要な対策です。Cookie、フォーム、API、アップロードファイルなど、外部から受け取ったデータを任意のオブジェクトとして復元しない設計にします。

📦 JSONなど構造を定義しやすい形式に置き換える

可能であれば、任意のオブジェクトを復元する形式ではなく、JSONやProtocol Buffersのように構造を明確に定義しやすい形式へ置き換えます。あわせてスキーマ検証・型検証を行うことが重要です。

🧱 スキーマ検証・型検証を行う

JSONなどに置き換えた場合でも、想定した型・項目・範囲だけを受け入れるようにします。未知のフィールド、想定外の型、深すぎるネスト、大きすぎる入力は拒否します。

🔍 許可リストで復元対象を制限する

どうしてもデシリアライズが必要な場合は、復元できる型やクラスを許可リストで制限します。許可していない型や予期しないクラスは復元しないようにします。

✍️ 改ざん検知のために署名する

クライアントに渡すデータには、HMACなどで署名を付け、改ざんを検知できるようにします。ただし、署名は危険なデシリアライズ処理そのものを安全にするものではありません。まずは外部入力をオブジェクトとして復元しない設計を優先します。

📦 依存ライブラリを管理する

デシリアライズ脆弱性は、アプリ本体だけでなく依存ライブラリの組み合わせでも問題になります。不要なライブラリを減らし、既知脆弱性のあるバージョンを使い続けないようにします。

「外部入力をオブジェクトに復元しない」。これが一番大事なんだね💪

🔑 あわせて見直したい基本対策

デシリアライズ脆弱性の直接対策ではありませんが、セキュリティ全体を見直す際に、パスワードの使い回しも同時に改善しておくと安心です。パスワード管理ツールを使って、サービスごとに異なるパスワードを管理しましょう。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

Base64で読みにくくしているだけで、安全になったと誤解する。
外部入力に対して、任意のクラスや型を復元できる状態にしている。
外部入力に対して、危険なデシリアライズAPIを便利だからという理由で使っている。
許可リストを設定せず、すべてのクラスを復元可能にしている。
署名・改ざん検知なしで、Cookieやフォームにシリアライズ済みデータを入れている。
JSONなどに置き換えても、スキーマ検証や型検証をしていない。
古い依存ライブラリや不要なライブラリを放置している。

🧰 ツール早見表

デシリアライズ脆弱性は、攻撃ツールよりも「どこで危険な復元処理が行われているか」を見つけることが重要です。補助ツール・資料としては、以下のようなものが役立ちます。

ツール・資料	用途	ひと言
Burp Suite	リクエスト確認	CTF・許可された診断で、入力値の流れを確認する
アプリケーションログ	復元処理の確認	デシリアライズ処理の有無や例外ログを見る
静的解析・コードレビュー	危険なAPIの発見	外部入力に対する復元処理を重点的に確認する
SBOM / 依存関係管理	危険なライブラリ確認	古いライブラリや既知脆弱性を洗い出す
OWASP Deserialization関連資料	防御設計	安全な設計方針を確認する