// シス担のミカタ
Webアプリケーション攻撃

デシリアライゼーション攻撃 でしりありぜーしょんこうげき

シリアライズデシリアライズインジェクションリモートコード実行オブジェクト改ざんJava deserialization
デシリアライゼーション攻撃って何？

簡単に言うとこんな感じ！

アプリがデータを「荷ほどき」するときに、毒入りの荷物をこっそり混ぜ込む攻撃だよ！　正規のデータに見せかけた悪意あるコードを送りつけて、サーバーに勝手に実行させちゃうんだ。気づきにくくて被害が大きいから要注意なんだ！

デシリアライゼーション攻撃とは

Webアプリケーションやサービスは、データをネットワーク越しに送受信するとき「バイト列（文字や数字の羅列）」に変換して扱います。この「オブジェクト（プログラム内のデータのかたまり）→バイト列」への変換をシリアライズ（直列化）、逆の「バイト列→オブジェクト」への復元をデシリアライズ（逆直列化）と呼びます。デシリアライゼーション攻撃とは、この「復元」の処理を悪用し、細工されたデータを送りつけてサーバー上で任意のコードを実行させたり、アプリの挙動を狂わせたりする攻撃です。

特に Java、PHP、Python、Ruby などのオブジェクト指向言語で書かれたアプリは、シリアライズ機能を多用するため影響を受けやすいとされています。OWASP Top 10（Webアプリの重大脆弱性トップ10）でも長年取り上げられており、2017年版では「A8: Insecure Deserialization（安全でないデシリアライゼーション）」として世界的に警戒が呼びかけられました。

発注者・管理者の立場から見ると、「外部からデータを受け取って処理する仕組みがある」すべてのシステムが対象になり得ます。セッション情報・API通信・ファイルアップロードなど、一見地味な機能がこの攻撃の入口になることを覚えておくと発注時のチェックに役立ちます。

シリアライズ／デシリアライズの仕組みと攻撃ポイント

プログラムの中で扱う「オブジェクト（複雑なデータ）」をそのままネットワークに流すことはできません。一度「文字列やバイト列」に”梱包”して送り、受け取り側が”開梱”して元のオブジェクトに戻すのが基本の流れです。

【送信側】                        【受信側】
オブジェクト  →  シリアライズ  →  バイト列  →  デシリアライズ  →  オブジェクト
（複雑なデータ）   （梱包）      （荷物）       （開梱）          （復元）
                                    ↑
                          ここに毒入りデータを混入！

攻撃者はこの「バイト列（荷物）」を改ざんして送りつけます。アプリが検証なしに開梱（デシリアライズ）すると、悪意あるオブジェクトが復元され、意図しない処理が走ります。

段階正常な動作攻撃時の動作
データ送信正規のオブジェクトをバイト列に変換攻撃者が改ざんしたバイト列を送信
デシリアライズバイト列を元のオブジェクトに復元細工されたオブジェクトが生成される
処理実行想定内の処理が走る任意コード実行・権限昇格・データ改ざん が発生

覚え方：「開梱チェックなし＝毒が入り放題」

シリアライゼーション攻撃は「届いた荷物を中身確認なしに開ける」状態が問題です。「荷物を受け取ったらX線検査（入力バリデーション）してから開ける」というイメージで覚えると、対策の本質も掴めます。

攻撃で引き起こされる被害の分類

被害種別内容実例
RCE（リモートコード実行）サーバー上で任意のコマンドを実行マルウェア設置・バックドア作成
権限昇格一般ユーザーが管理者権限を取得管理画面の不正操作
DoS（サービス妨害）無限ループや大量メモリ消費を引き起こすシステムのクラッシュ・停止
データ改ざんオブジェクトの内容を書き換えて不正操作価格・ポイントの改ざん
SSRFへの連鎖内部ネットワークへの不正アクセス内部APIの悪用

歴史と背景

  • 2000年代〜：JavaやPHPでシリアライズ機能が広く使われ始める。当初はセキュリティリスクとしてほぼ認識されていなかった
  • 2015年：セキュリティ研究者が「Apache Commons Collections」ライブラリを利用したJavaデシリアライズ攻撃を実証公開。多数の有名製品（WebLogic・JBoss・Jenkinsなど）に影響が判明し業界に衝撃が走る
  • 2016年：米国サンフランシスコの交通機関（SFMTA）がランサムウェアに感染。デシリアライズ脆弱性が踏み台に使われたとされる
  • 2017年：OWASPが「A8: Insecure Deserialization」としてTop 10に追加。業界全体での対策啓発が本格化
  • 2019年〜：PHP・Python（Pickle）・Ruby（Marshal）など多言語での脆弱性が次々と報告され、言語を問わない普遍的な問題として定着
  • 現在：クラウドネイティブ環境・マイクロサービス間通信でもシリアライズは多用されており、引き続き警戒が必要な攻撃ベクターとして位置づけられている

主な攻撃手法と対策の比較

デシリアライゼーション攻撃にはいくつかのパターンがあり、対策も複数を組み合わせる必要があります。

デシリアライゼーション攻撃：攻撃フローと対策ポイント 攻撃者 細工したデータを送信 通信経路 HTTPリクエスト/Cookie/API デシリアライズ処理 検証なしに復元実行 被害発生 RCE / 権限昇格 / DoS 対策ポイント ① 入力バリデーション 受信データの型・サイズ・ 署名を検証する （HMACによる改ざん検知） ② 安全な形式の採用 JSONやXMLなど コードを含まない形式に 切り替える ③ サンドボックス化 デシリアライズ処理を 権限の低い環境で実行し 被害を最小化する ④ ライブラリの更新 既知の脆弱なライブラリ （Commons Collections等） を最新版に保つ ⑤ WAFの活用 Webアプリファイアウォールで 既知の攻撃パターンを 検知・ブロックする ⑥ ログ監視 異常なデシリアライズ処理を リアルタイム検知する SIEMとの連携が有効

言語別の主な危険なデシリアライズ機能

言語危険な機能安全な代替
JavaObjectInputStreamJackson (JSONバインディング)
PHPunserialize()json_decode()
Pythonpickle.loads()json.loads()
RubyMarshal.load()JSON / MessagePack
.NETBinaryFormatterSystem.Text.Json

発注・選定時のチェックポイント

ベンダーへの発注や製品選定の場面では、以下を確認しましょう。

  • 「デシリアライズ処理に入力バリデーションを実装しているか？」
  • 「使用しているシリアライズライブラリのバージョン管理・定期更新の仕組みはあるか？」
  • 「ペネトレーションテストやOWASP Top 10に基づいたセキュリティ診断を実施しているか？」

関連する規格・RFC

規格・文書内容
OWASP Top 10 A8:2017Insecure Deserializationとして危険度を格付け。対策ガイドラインを提供
OWASP Top 10 A08:2021「Software and Data Integrity Failures（ソフトウェアとデータの整合性の失敗）」に再分類・統合
CWE-502信頼できないデータのデシリアライズに関する共通脆弱性タイプ定義
CVE-2015-4852Oracle WebLogic Serverのデシリアライズ脆弱性（最初期の有名CVE）
NIST SP 800-53SI-10（情報入力バリデーション）でデシリアライズ処理の検証を推奨

関連用語