PHPのunserializeはどこが危険？外部データとオブジェクトを分ける

公式の警告は、外部入力を渡さないこと

PHP公式は、allowed_classesの指定にかかわらず、信頼できない入力をunserializeへ渡さないよう警告しています。オブジェクトの生成やオートロードによりコードが読み込まれ実行される可能性があるためです。利用者とデータを受け渡す用途ではJSONなどの標準形式を検討する案内があります。

公式情報：PHP公式：unserializeの警告（確認 2026-10-26）

「内部にあるデータ」も、出所をたどる

SONAEの点検案では、Cookie、取込ファイル、キャッシュ、キュー、DBに保存した値を出所から確認します。DBに置かれた後だから信頼できる、というだけでは十分な説明になりません。誰が書き込め、どの処理を通り、どこで復元されるかを対応させます。古い機能で使われていない呼出しも、削除または到達しない根拠を確認します。

SONAEの点検・運用提案。架空例。

設定一つを、設計の代わりにしない

allowed_classesを制限したことを、外部データを自由に復元してよい理由にしません。安全性の確認を、危険そうなクラス名の一覧だけで終えないようにします。SONAEは、必要なデータが単なる数値や文字列なのか、アプリ内部のオブジェクト構造なのかを整理し、受渡し形式から見直す方法を提案します。

SONAEの点検・運用提案。架空例。

JSONへ変えた後も、検証は必要

形式を変更しただけで、型、長さ、深さ、必須項目、認可が自動で適切になるわけではありません。架空の取込機能では、受付可能な項目と量を決め、不明な項目をどう扱うかを設計します。移行前の保存データを読み直す経路も点検し、新形式の受付だけを直して旧形式の復元が残る状態を避けます。

SONAEの点検・運用提案。架空例。

古い保存データを移す仕事を、別に計画する

SONAEの運用例では、移行元を固定し、書込み権限、停止時間、変換先、照合、戻す条件を管理します。移行のために未知のデータを管理者権限で復元する方法へ安易に進みません。必要な場合は専門の担当者が隔離した環境と方法を判断します。この記事ではオブジェクトの攻撃用データや実行手順を提供していません。

SONAEの点検・運用提案。架空例。

完了は、呼出しと入口の対応で説明する

復元する関数を検索した結果、外部由来の入口、変更した仕様、残る互換処理、受入の結果を一組で残します。単に危険な関数名が見つからないことだけを、依存部品を含むアプリ全体の証明にしません。AIによるコード変更でも、元のデータの出所と移行処理を人が確認し、未確認を消さずに引き継ぎましょう。

SONAEの点検・運用提案。架空例。

移行で残しやすい、互換用の入口を確認する

架空の設定取込では、新形式をJSONに変えても、旧Cookieや古いキューの読み出しが残れば別の経路です。SONAEの受入計画は、呼出し元とデータの書込者を対応させ、新旧の受付をどの時点で止めるかを管理します。失敗時に自動で旧形式を試す仕様があるなら、それも明示して見直します。必要な互換処理は、期間、対象、実施担当を狭くし、終了条件を設けます。変換後の件数や必要な値の照合と、不要な機能の削除を別に記録します。未知の保存データを動かして安全を確かめる試験は、この調査には含めていません。

SONAEの点検・運用提案。架空例。

完了前のチェック

• allowed_classesだけで安全としない
• 保存先からデータの出所へ戻る
• JSON移行後の型と量を検証
• 旧形式の移行経路も確認

一次資料と確認範囲

• PHP公式：unserializeの警告

資料の対象条件と掲載内容を確認して構成した記事です。顧客への接続や攻撃再現はしていません。資料の改訂を自動追従するものではありません。実施直前に公式資料と配布元の最新案内を再確認してください。