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

こんにちは、アンペンです！

前回は、テンプレートに混ざる悪意でRCEに至るSSTIを扱いました。

今回は、データを「オブジェクトとして復元する」処理が攻撃に化けるデシリアライズを見ていきます。蘇らせてはいけないデータの罠を、優しく見ていきましょう。

データを保存して、また読み戻すだけでしょ？何が危ないの？

復元のとき、データに紛れ込んだ『指示』でサーバ側のオブジェクトが勝手に組み立てられることがあるんだ。最悪はそのままRCEになる。

『データを保存して、あとで読み戻す』——プログラムでは毎日のように行う、ごく当たり前の処理です。それが、まさかサーバ乗っ取りにつながるなんて。今日のデシリアライズは、シリーズの中でも特に“地味なのに最凶”な部類です。見た目はただのデータの出し入れ。でも、その“読み戻し”の瞬間に罠が発動する。今日は冷凍弁当を電子レンジで温める話にたとえて、その不思議をほどいていきます。

シリアライズ/デシリアライズの基本

シリアライズとは、メモリ上のオブジェクトをファイルや通信で扱える「文字列(またはバイト列)」に変換することです。デシリアライズは逆に、その文字列をもとにオブジェクトを再度組み立て直す処理です。

多くの言語のシリアライズ形式は、ただの値だけでなく「どのクラスを使うか」「どんなメソッドを呼ぶか」も復元時に解釈します。ここに信頼できないデータを通すと、攻撃者が指定したクラス/メソッドが動いてしまうことがあります。

ここがデシリアライズの怖さの正体です。多くの言語の“荷ほどき”は、単に中身を取り出すだけではありません。「この荷物は、◯◯というクラスのオブジェクトとして組み立てて」「組み立てるときに、このメソッドを呼んで」という“指示書”まで、一緒に解釈してしまうんです。だから、信頼できない文字列を荷ほどきすると、攻撃者が書いた指示書どおりに、サーバが勝手に動き出してしまう。データのつもりが、実は“命令書”だった——というわけです。

まず言葉の整理から。『シリアライズ』は、プログラムの中で生きているオブジェクト（データのかたまり）を、保存や送信ができる“ひとつながりの文字列”に変換することです。引っ越しでいう“荷造り”ですね。逆に『デシリアライズ』は、その文字列をもとにオブジェクトを“組み立て直す”こと。つまり“荷ほどき”です。問題は、この荷ほどきの作業が、思った以上にいろいろなことを自動でやってしまう点にあります。

図解：正しい復元と攻撃データの復元

同じデシリアライズ関数でも、正規データと細工データを渡したときの結末は大きく異なります。

『ガジェットチェーン』も、言葉は難しいですが発想はシンプルです。攻撃者は、いきなり“危険なクラス”を呼ぶわけではありません。プログラムにもともと備わっている、一見無害なメソッドたちを——Aを呼ぶとBが動き、Bが動くとCが呼ばれ…——とドミノのようにつなげて、最後にコード実行へたどり着くんです。一つひとつは無害な部品でも、つなぎ方しだいで凶器になる。だから「この部品は安全だから大丈夫」という単体の判断が通用しない、やっかいな攻撃なんです。

言語ごとの危険関数と発生場面

うれしくない話ですが、主要な言語にはたいてい“やってはいけない荷ほどき関数”が一つずつあります。Pythonならpickle、PHPならunserialize、JavaならreadObject……といった具合。名前は違っても、どれも「言語が独自の形式を、指示書ごと復元してしまう」という同じ性質を持っています。まずは自分の使う言語の“その関数”を知っておくことが、第一歩になります。

代表的な危険関数

• Python： pickle.loads / yaml.load(safe_loadではないもの)
• PHP： unserialize
• Java： ObjectInputStream.readObject
• .NET： BinaryFormatter / NetDataContractSerializer
• Ruby： Marshal.load

これらの関数に「外部から届いたデータ」を直接渡している箇所が、デシリアライズ脆弱性の中心となります。発生場面はCookie・キャッシュ・キュー・セッション保存・APIなど多岐にわたります。

ここで見落としがちなのが、『外部から届いたデータ』の範囲です。フォームの入力だけだと思っていませんか？実は、Cookieの中身、キャッシュ、メッセージキュー、セッション保存——こういう“裏方のデータ”も、元をたどれば利用者から来ていることがあります。とくにCookieにオブジェクトをそのまま詰めて保存していると、利用者がそれを書き換えて送り返せてしまう。だから「どこまでが信頼できないデータか」を、いつもより少し広く見積もる必要があるんです。

今日の練習は、攻撃ペイロードを作ることではありません。もっと地味で、もっと実戦的——自分のコードを“grep（文字列検索）”して、危険な荷ほどき関数を探すだけです。見つかったら、「この関数に渡るデータは、どこから来ている？」と一つずつたどってみる。本物のサービスに細工データを送るのは、もちろん厳禁。宝探しの気分で、自分のコードを点検してみましょう。

CTFでやってみよう：復元処理を意識して読む

守りの第一候補は『そもそも危ない荷ほどきをやめて、安全な形式に乗り換える』ことです。

JSONなら安全、ってよく聞くけど、何がそんなに違うの？

いい質問。JSONが扱えるのは、文字・数値・配列・真偽値みたいな“ただのデータ”だけなんだ。さっき言った「どのクラスで、どのメソッドを呼ぶ」という“指示書”を、そもそも持てない。だからJSONをいくら荷ほどきしても、データが出てくるだけで、勝手にプログラムは動かない。pickleやunserializeが危ないのは、まさにこの“指示書を運べてしまう”力があるから。安全な形式とは、つまり“データしか運べない形式”のことなんだよ。

守る側なら、「外部データはデシリアライズしない」を徹底

デシリアライズの守りは、「信頼できないデータを直接デシリアライズしない」「必要なら署名で改ざんを検出する」が基本です。

『復元』っていう、当たり前そうな処理が一番怖い場合があるんだね。

そう。デシリアライズは『見えにくいRCE』。だから関数の利用箇所を一覧化しておくのが、一番効く対策だよ。

ここまでをひと言で言うと、デシリアライズ対策は『信頼できないものは、蘇らせない』。荷ほどきは便利ですが、相手が誰かも分からない荷物を、無防備に開けてはいけません。安全な形式（JSON）に寄せる、どうしても言語固有の形式を使うなら署名で“すり替えられていないか”を確かめる。この2つが、守りの背骨になります。

まとめ：信頼できないデータは「蘇らせない」

今日の持ち帰りは『データだと思っていたものが、命令書かもしれない』です。デシリアライズは“見えにくいRCE”の代表で、コードを読んでも一見ふつうの処理に見えます。だからこそ、危険な関数の使用箇所を一覧にして、「ここに外部データは流れ込まない？」と定期的に点検する。地道ですが、これがいちばん効く守りです。

次回は、サーバが外部コマンドを呼び出す処理で起きるコマンドインジェクションを扱います。OSコマンドに混ざる悪意とRCEの経路を見ていきましょう。

次に読みたい記事

参考資料