門を開けてはいけない：安全でないデシリアライゼーションという「パンドラの箱」
現場でインシデント対応をしていると、時折「なぜこんな実装を許したんだ？」と頭を抱えたくなるコードに出くわす。その筆頭が、安全でないデシリアライゼーション（Insecure Deserialization）だ。
開発者は往々にして、データを保存・転送するために「オブジェクトをそのまま文字列化（シリアライズ）」して受け渡しがちだ。しかし、この「便利さ」は、攻撃者にとっての「特等席」になり得る。今日は、この脆弱性がなぜRCE（リモートコード実行）に直結するのか、そしてどうやって防ぐべきか、現場の視点で語ろう。
—
1. なぜ「シリアライズ」は危険なのか
デシリアライズとは、メモリ上のオブジェクトを保存可能な形式（バイト列やJSONなど）から、再び実行可能なオブジェクトに戻す処理だ。
問題は、「戻す過程で、アプリケーションが信頼していないデータを勝手に実行してしまう」という点にある。PHPの `unserialize()` や Pythonの `pickle` は、その最たる例だ。攻撃者は、本来存在しないはずの悪意あるオブジェクトをシリアライズデータに紛れ込ませる。デシリアライズされた瞬間、アプリケーションはそのオブジェクトを「本物」だと信じ込み、魔法（マジックメソッド）を勝手に発動させる。これがRCEのトリガーだ。
攻撃のメカニズム（PoCの概念）
例えばPHPにおいて、`__wakeup()` や `__destruct()` というマジックメソッドが定義されているクラスがあるとしよう。攻撃者は、これらの中に存在する `eval()` や `system()` を悪用するオブジェクトを構築し、Base64エンコードしてCookieやPOSTデータに忍び込ませる。サーバーがそれをデシリアライズした瞬間、攻撃者のコマンドがroot権限で実行されるわけだ。
—
2. 安全な実装のための「鉄則」
デシリアライゼーションの脆弱性を防ぐための唯一にして最大のルールは、「信頼できないソースからのデシリアライズを絶対に行わない」ことだ。これに尽きる。
しかし、どうしてもデータを受け渡す必要がある場合は、以下の防御策を徹底してほしい。
A. データ形式をJSON等の「データオンリー」にする
これが一番の防御策だ。JSONは構造化されたデータであり、クラスやメソッドをシリアライズすることはない。
【Pythonでのセキュアな実装例】
`pickle` は絶対に使うな。あれはリモートコード実行のためのツールだ。代わりに `json` ライブラリを使え。
import json
危険な実装（絶対にやるな）:
import pickle
data = pickle.loads(user_input)
セキュアな実装:
def load_data(raw_data):
try:
# JSONならコード実行の恐れがない
data = json.loads(raw_data)
return data
except json.JSONDecodeError:
# 不正なフォーマットは即座に拒否
raise ValueError(“不正なデータ形式です”)
B. シリアライズされたデータに署名を付与する（HMAC）
もし、どうしても複雑なオブジェクトをやり取りしなければならない場合（かつ、JSONへの移行が困難な場合）、そのデータが「改ざんされていないこと」を証明する必要がある。
【PHPでの署名付きシリアライズ実装例】
データにHMAC（ハッシュベースのメッセージ認証コード）を付与し、受信時に検証する。
—
3. インフラレイヤーでの多層防御（WAF/設定）
アプリケーションコードだけで100%防ぐのは限界がある。インフラ側でも「シリアライズの痕跡」を監視・遮断するのがプロの仕事だ。
WAF（ModSecurity等）でのシリアライズペイロードの遮断
攻撃者は、シリアライズデータの特徴的な文字列（PHPなら `O:8:”stdClass”` など）を送り込んでくる。WAFでこれを検知する。
【Nginx/ModSecurity 簡易的なブロックルール例】
PHPのシリアライズ文字列パターンをブロック
SecRule REQUEST_BODY “O:[0-9]+:\”” \
“id:1001,phase:2,deny,log,msg:’Insecure Deserialization Attempt Detected'”
—
最後に：セキュリティは「疑うこと」から始まる
私がこの業界で学んだのは、「ライブラリや言語のデフォルト設定は、必ずしも安全ではない」という事実だ。開発の利便性を優先した結果、取り返しのつかないインシデントを起こすチームを何度も見てきた。
今回紹介した対策は、決して難しいハックではない。「JSONを使う」「署名を入れる」。たったこれだけのことだが、これを徹底するだけでRCEのリスクを劇的に下げられる。
次のデプロイの前に、一度コードを眺めてみてほしい。`unserialize` や `pickle.loads` が放置されていないか。もし見つけたら、それは爆弾の導火線だ。今すぐ取り除こう。それが君のシステムを守り、そして君自身のエンジニアとしてのキャリアを守ることにつながるはずだ。
コメント