安全でないデシリアライゼーションとは？
安全でないデシリアライゼーションとは、プログラムがデータを復元（デシリアライズ）する際に、悪意あるコードを含むデータを検証せずに処理してしまう脆弱性です。Webサイト・APIの弱点の中でも最も危険な部類に入る脅威で、Java、Python、PHP、.NETなど多くのプログラミング言語で発生します。シリアライズ（データをバイト列に変換）されたオブジェクトを元に戻す際に、攻撃者が仕込んだ悪意あるコードが実行され、サーバーの完全な乗っ取りが可能になります。
安全でないデシリアライゼーションを簡単に言うと？
宅配便の荷物に例えると、普通は「本」と書かれた箱には本が入っているはずですが、悪い人が「本」と書いた箱に爆弾を入れて送ってきたようなものです。受け取った側は、箱の中身を確認せずに「本と書いてあるから本だろう」と信じて開けると、爆弾が爆発してしまいます。デシリアライゼーションも同じで、プログラムが「これはただのデータです」という形で送られてきたものを、中身を検証せずに開いて処理すると、実は中に「サーバーを乗っ取るプログラム」が入っていて、それが動き出してしまいます。箱（データ）の中身を信用しすぎることで、とんでもない被害を受けてしまうのです。
安全でないデシリアライゼーションで発生する被害は？
安全でないデシリアライゼーションにより、リモートコード実行、システムの完全掌握、データの改ざん・削除などの致命的な被害が発生します。Webサイト・APIの弱点を突かれることで、攻撃者はサーバー上で任意のコマンドを実行でき、まるで管理者としてログインしたかのように自由に操作できます。特に、認証やセッション管理でシリアライゼーションを使用している場合、全ユーザーのなりすましが可能になる深刻な事態となります。
安全でないデシリアライゼーションで発生する直接的被害
- サーバーの完全乗っ取り
攻撃者が送り込んだコードがサーバー上で実行され、管理者権限を奪取して、システム全体を自由に操作できるようになる
- 機密データの大量窃取
デシリアライゼーションを通じてデータベースへの直接アクセスが可能になり、顧客情報、クレジットカード情報、企業秘密が根こそぎ盗まれる
- ランサムウェアの展開
リモートコード実行により、サーバー内の全ファイルを暗号化するランサムウェアが実行され、業務が完全停止する
安全でないデシリアライゼーションで発生する間接的被害
- バックドアの永続的設置
攻撃者がシステムに裏口を仕込み、パッチを適用しても繰り返し侵入されて、長期間にわたって監視や情報窃取が続く
- サプライチェーン攻撃の起点
乗っ取られたシステムから取引先や顧客のシステムへ攻撃が波及し、信頼関係が崩壊して巨額の損害賠償責任を負う
- 認証システムの崩壊
セッション管理の脆弱性を突かれて、任意のユーザーになりすましが可能になり、サービス全体の信頼性が失われる
安全でないデシリアライゼーションの対策方法
安全でないデシリアライゼーションへの対策は、信頼できないソースからのシリアライズデータの拒否、入力検証の徹底、代替手段の採用が基本となります。Webサイト・APIの弱点を補強するために、JSONなどのデータのみを扱う形式への移行、デシリアライゼーション処理の隔離実行、整合性チェック（デジタル署名）の実装が重要です。また、最小権限での実行、ログ監視の強化により、攻撃を早期に検知し被害を最小限に抑えることができます。
安全でないデシリアライゼーションの対策を簡単に言うと？
空港の手荷物検査に例えると、まず「危険物は持ち込み禁止」というルールを作り（シリアライズデータの拒否）、全ての荷物をX線検査機で中身を確認します（入力検証）。怪しい荷物は開けて詳しく調べ、本当に安全なものだけを通します。可能であれば、複雑な荷物（オブジェクト）ではなく、単純な書類（JSON）だけを受け付けるようにします。さらに、荷物には必ず送り主の証明（デジタル署名）をつけてもらい、信頼できる相手からのものだけを受け取ります。万が一危険物が紛れ込んでも被害を最小限にするため、荷物を扱う場所を隔離し（サンドボックス）、監視カメラで常に見張ります（ログ監視）。「便利だから」という理由で検査を省略せず、安全を最優先にすることが大切です。
安全でないデシリアライゼーションに関連した攻撃手法
Webサイト・APIの弱点において、安全でないデシリアライゼーションと密接に関連する3つの攻撃手法を解説します。
- XXE（XML External Entity）
安全でないデシリアライゼーションとXXEは、どちらも外部から受け取ったデータを無検証で処理することで発生します。XMLもオブジェクトも、複雑な構造を持つデータを扱う点で共通しており、両方の脆弱性が同じシステムに存在すると、攻撃の選択肢が増えて防御が困難になります。
- OSコマンドインジェクション
安全でないデシリアライゼーションの結果として、OSコマンドインジェクションが可能になることが多いです。デシリアライゼーション時に任意のコードが実行できれば、そこからシステムコマンドを呼び出すことができ、両者が組み合わさると完全なシステム制御が可能になります。
- SQLインジェクション
デシリアライゼーションされたオブジェクトがデータベースクエリに使用される場合、SQLインジェクションのリスクも発生します。安全でないデシリアライゼーションで改ざんされたオブジェクトが、そのままSQL文に組み込まれることで、データベース全体が危険にさらされます。
安全でないデシリアライゼーションのよくある質問
Java、Python（pickle）、PHP、Ruby、.NETなど、オブジェクトのシリアライゼーション機能を持つ言語は全て危険です。特にJavaのObjectInputStreamやPythonのpickleは、過去に多くの被害事例があります。
JSONは基本的にデータのみを扱うため、安全でないデシリアライゼーションのリスクは大幅に低減されます。ただし、JSONデータを元にオブジェクトを生成する処理には注意が必要です。
はい、特にシリアライズされたオブジェクトをCookieやセッションに保存している場合は危険です。攻撃者がCookieを改ざんして悪意あるオブジェクトを送り込む可能性があります。
暗号化だけでは不十分です。暗号化は機密性を保護しますが、復号後にデシリアライゼーションすれば同じ脆弱性が存在します。暗号化に加えて、デジタル署名による改ざん検知が必要です。
デシリアライゼーション処理を隔離環境（コンテナやVM）で実行する、WAFで悪意あるペイロードをブロックする、処理前に厳格なホワイトリスト検証を行うなどの代替策を検討してください。
OWASP ZAP、Burp Suite、専用ツールのysoserial（Java）などがあります。定期的な脆弱性診断と、コードレビューでのシリアライゼーション処理の確認が重要です。
更新履歴
- 初稿公開
