【入門編】安全でないデシリアライゼーションの脆弱性と対策 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは。セキュリティの最前線で泥臭いインシデント対応を続けている者です。

今日は、開発現場でつい見過ごされがちだけど、一度突かれるとシステムが「全滅」しかねない恐ろしい罠、「安全でないデシリアライゼーション」についてお話しします。

難しそうな名前ですよね？でも、身近な例えを使えば誰でも理解できます。一歩ずつ、防犯の視点から紐解いていきましょう。

—

プログラミングの世界では、複雑なデータ（オブジェクト）を、ネットワークで送ったりファイルに保存したりするために、バラバラの文字列やバイナリに変換します。これを「シリアライズ（直列化）」と呼びます。

逆に、受け取ったバラバラのデータを、元のプログラムで使える「元の形（オブジェクト）」に戻す作業を「デシリアライゼーション（復元）」と言います。

あなたは「家の鍵」を宅配便で送るために、一度分解して箱に詰めたとします。

ここでの問題は、「箱の中に何が入っているか、開けるまで確認しない」という点です。もし、悪意ある誰かがその箱の中に「鍵」ではなく「爆弾」を仕込んでいたらどうなるでしょうか？

攻撃者は、システムが「デシリアライゼーション」を行う際、「本来あるはずのデータ」の代わりに「悪意のある命令」を仕込んだデータを送りつけます。

システムは「これは信頼できるデータだ！」と信じ込み、その中身を無理やり実行してしまいます。これが「安全でないデシリアライゼーション」です。結果として、攻撃者はあなたのサーバーを遠隔操作（RCE）し、やりたい放題にできてしまうのです。

「外からの怪しい小包は開けない」というのが防犯の鉄則ですが、サーバーはプログラムである以上、中身を賢くチェックしなければなりません。

—

一番の対策は、「信頼できないデータを決してデシリアライズしないこと」です。しかし、どうしてもデータをやり取りする必要がある場合は、以下のルールを守ってください。

Javaのネイティブなシリアライズや、PHPのunserialize()関数などは、非常に強力な機能（オブジェクトをそのまま復元する機能）を持っているため、悪用されやすいです。

代わりに、JSONのように「ただのデータ」として扱える形式を使いましょう。JSONは命令を実行する機能を持たないので、もし攻撃者が細工をしても、単なる「ただの文字列」として処理されるだけで済みます。

どうしても複雑なデータを送らなければならない場合は、そのデータが「本当に信頼できる相手から送られたものか」を確認するための「署名」を付けます。

イメージ：秘密鍵を使ってデータに署名する（Pythonの例）
import hmac
import hashlib

鍵（秘密にしておくもの）
SECRET_KEY = b’super-secret-key-123′

データを送る前：署名を作成
data = b'{“user_id”: 123}’
signature = hmac.new(SECRET_KEY, data, hashlib.sha256).hexdigest()

送信するデータ：データと署名をセットにする
受信側は、届いたデータに同じ鍵で署名を計算し、一致するか確認します

もし攻撃者がデータを少しでも改ざんすれば、署名が一致しなくなるため、プログラムは「このデータは怪しい！」と判断して処理を拒否できます。

—

新しい機能を作る際、もしあなたが「シリアライズ」という言葉を目にしたら、一度立ち止まってこう考えてみてください。

1. 「このデータ、JSONで送ることはできないかな？」
2. 「このデータを受け取る時、中身が正当なものかチェックしているかな？」
3. 「もし改ざんされていたら、システムはどう反応するかな？」

セキュリティは、魔法のようなツールを入れることではなく、こうした「疑う習慣」を身につけることから始まります。

最初は難しく感じるかもしれませんが、まずは「外部からの入力をそのまま信じない」という意識を持つだけで、あなたの書くコードは格段に強固になります。一緒に、安全な開発の楽しさを追求していきましょう！

—
執筆後記：
インシデントの現場では、「まさかこんなデータが送られてくるとは思わなかった」という言葉をよく耳にします。しかし、ハッカーは「まさか」を狙ってきます。皆さんのコードが、攻撃者にとって「開けても損しかない箱」になることを願っています。