聞いたことないけど、実は危ないかもしれない「安全でないデシリアライゼーション」について、やさしく解説します。
はじめに
インターネットを使っていると、色々な情報がやり取りされていますね。実は、その情報のやり取りの中に、「安全でないデシリアライゼーション」という種類のセキュリティ上の弱点（脆弱性）が潜んでいることがあります。名前は難しそうですが、仕組みは意外と身近なことに例えられます。このブログでは、技術的な話をできるだけ少なくして、この脆弱性がどんなもので、なぜ危険なのか、そしてどうすれば防げるのかを見ていきましょう！
シリアライズとデシリアライズって何？
まず、この脆弱性を理解するために、「シリアライズ」と「デシリアライズ」という言葉を知っておきましょう。難しく考えなくて大丈夫です！
- シリアライズ (Serialization): プログラムの中で使われているデータ（オブジェクトと言います）を、ファイルに保存したり、ネットワークで送ったりできる形に変換することです。ちょうど、家具を運ぶために一度分解して箱詰めするようなイメージです。
- デシリアライズ (Deserialization): シリアライズされたデータ（箱詰めされた家具）を、元のプログラムで使える形（組み立てられた家具）に戻すことです。
データを送ったり保存したりするときに便利な仕組みですが、この「元に戻す」デシリアライズの時に問題が起きることがあります。
友達に組み立て式の家具を送るとします。
シリアライズ： あなたが家具を部品に分けて、説明書と一緒に箱に入れる作業です。
デシリアライズ： 友達が箱を開けて、説明書通りに家具を組み立てる作業です。
「安全でない」デシリアライゼーションとは？
では、「安全でない」とはどういうことでしょうか？
これは、デシリアライズするデータが、信頼できないところから来たもの、あるいは途中で悪い人に書き換えられたものかもしれないのに、それをチェックせずにそのまま元に戻してしまう状況を指します。
先ほどの家具の例えで言うと、友達に送った箱が途中で悪い人に開けられて、中の「組み立て説明書」が「家にある貴重品を盗む指示書」に入れ替えられてしまったようなものです。友達が悪意のある指示書だと気づかずにそのまま実行してしまうと、大変なことになりますよね？
つまり、悪意のあるデータ（偽の説明書）をデシリアライズ（組み立て）してしまうことで、コンピュータ（友達）が意図しない危険な動作をしてしまう可能性があるのです。
なぜ危険なの？どんな被害がある？
安全でないデシリアライゼーションが悪用されると、以下のような深刻な被害が発生する可能性があります。
- リモートコード実行 (Remote Code Execution – RCE): 攻撃者が、あなたのコンピュータやサービスを提供しているサーバー上で、勝手にプログラムを実行できてしまう状態です。これは、システムを乗っ取られたり、情報を盗まれたりする最も危険な被害の一つです。まさに、偽の説明書に「家の鍵を渡せ」と書かれているようなものです。
- サービス妨害 (Denial of Service – DoS): 攻撃者が大量の処理をさせたり、システムを停止させたりして、サービスを使えなくしてしまうことです。「家具を延々と組み立て続けろ」という指示で疲れ果ててしまうイメージです。
- 情報漏洩: システム内の重要な情報（個人情報、パスワードなど）が盗み取られてしまう可能性があります。「金庫の番号を教えろ」という指示です。
- 権限昇格: 攻撃者が、一般ユーザーから管理者など、より高い権限を手に入れてしまうことです。これにより、さらに大きな被害を引き起こす可能性があります。
この脆弱性は、見つけにくい場合もありますが、一度悪用されると被害が非常に大きくなる可能性があります。
実際にあった事例は？
安全でないデシリアライゼーションは、残念ながら実際の攻撃で悪用された事例があります。
- Apache Struts2 (2017年など): Webアプリケーションを開発するための有名なフレームワークであるApache Struts2では、過去に複数回、安全でないデシリアライゼーションの脆弱性が発見され、多くのウェブサイトが攻撃を受けました。これにより、企業の機密情報が漏洩したり、Webサイトが改ざんされたりする被害が発生しました。
- Javaを利用したシステム: Javaというプログラミング言語は、標準でシリアライズ/デシリアライズの機能を持っているため、この機能を安全でない方法で使用している場合に攻撃の標的となることがあります。様々なWebアプリケーションサーバーやソフトウェアで、この脆弱性が原因となる問題が報告されています。
- Checkbox Survey (2021年): Checkbox社が提供するアンケートツールに、安全でないデシリアライゼーションの脆弱性 (CVE-2021-27852) が存在し、遠隔の攻撃者がサーバー上で任意のコードを実行できる可能性がありました。
- Laravel (PHPフレームワーク): PHPのフレームワークであるLaravelでも、過去のバージョン (5.6.30以前) でCookieの処理に安全でないデシリアライゼーションの脆弱性が存在しました（ただし、攻撃には暗号化キーが必要でした）。
これらは一部の例ですが、様々なソフトウェアでこの問題が発生しうることを示しています。
どうすれば防げるの？ (開発者向けヒント)
この脆弱性を防ぐためには、開発者がプログラムを作る際に注意する必要があります。非エンジニアの方も、このような対策が行われているか、少し気にかけてみると良いかもしれません。
主な対策は以下の通りです。
- 信頼できないデータはデシリアライズしない: これが最も重要です！ユーザーからの入力データや、インターネット経由で受け取ったデータなど、どこから来たかわからない、あるいは改ざんされている可能性のあるデータは、原則としてデシリアライズ処理をしないようにします。家具の例えなら、「知らない人から送られてきた箱は開けない」ということです。
- より安全なデータ形式を使う: オブジェクト全体をそのままシリアライズするのではなく、JSONやXMLのような、単純なデータをやり取りするための、より安全な形式を使うことを検討します。これらは通常、デシリアライズ時に勝手にプログラムが実行されるような仕組みを持っていません。
- データの完全性を検証する: どうしてもデシリアライズが必要な場合は、データが送られてくる途中で改ざんされていないかを確認するために、デジタル署名などの技術を使ってチェックします。「箱に封印がしてあって、それが破られていないか確認する」イメージです。
- デシリアライズするクラスを制限する: デシリアライズしても安全だとわかっているクラス（データの種類）だけを許可し、それ以外のものは拒否するようにします（ホワイトリスト方式）。
- ライブラリやフレームワークを最新に保つ: 使用しているソフトウェア（ライブラリやフレームワーク）に安全でないデシリアライゼーションの脆弱性が発見されることがあります。常に最新のバージョンにアップデートしておくことで、既知の脆弱性からシステムを守ることができます。
- デシリアライズ処理を監視する: デシリアライズ処理中にエラーが頻発したり、システムのリソース（CPUやメモリ）が異常に消費されたりしていないか監視することも有効です。
まとめ
「安全でないデシリアライゼーション」は、少し難しい名前ですが、「信頼できないデータを不用意に元に戻す処理」が危険である、ということを理解していただけたでしょうか？
便利な機能も、使い方を間違えると大きなリスクになります。開発者は安全な設計を心がけ、利用者もセキュリティ意識を持つことが大切です。この記事が、少しでもその助けになれば幸いです。