【実務・中級編】PHPオブジェクトのシリアライズ・デシリアライズにおけるメモリ確保の最適化とZend VMの役割：`unserialize()`の脆弱性対策 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

Zend VMの深淵：`unserialize()`が孕むメモリの魔界と、安全な状態復元の設計哲学

テックリードの私たちがコードレビューで最も身構える瞬間の一つが、プルリクエストに `unserialize()` が含まれている時だ。
「外部から入力された文字列を、そのままオブジェクトに戻す」——この一見無害に見える処理の裏で、Zend Engineのメモリ空間（Zend VM）がどれほど危険な状態に晒されているか、君たちは正確にイメージできているだろうか。

今回は、PHPのシリアライズ・デシリアライズにおけるメモリ確保のメカニズム、そして `unserialize()` が引き起こす致命的な脆弱性の正体を、Zend VMの低レイヤの挙動から完全に解き明かしていく。

—

1. Zend VMの視点：`unserialize()` 実行時に何が起きているのか

PHPのオブジェクトシリアライズは、データを単なるバイト列（ストリーム）に変換し、それを復元するプロセスだ。しかし、この復元（デシリアライズ）の裏側で、Zend Engineは膨大な動的メモリ割り当てを行っている。

HashTableとメモリの動的確保

デシリアライズされたデータは、Zend VMのメモリ管理機構（ZendMM）を介してヒープ上に展開される。
具体的には以下のステップを踏む。

1. ストリームのパース: バイト列をトークナイズし、型情報（`O`はオブジェクト、`a`は配列など）を判定する。
2. シンボルテーブルのルックアップ: 復元すべきクラス名が存在するか、autoloadのトリガーが必要かを内部のクラスエントリ（`zend_class_entry`）から検索する。
3. プロパティの割り当て: オブジェクト構造体（`zend_object`）をヒープ上にアロケートし、そのプロパティを格納するための `HashTable` を構築する。

ここで問題になるのは、「入力された文字列の構造を信じきってメモリを確保してしまう」というZend VMのプリミティブな挙動だ。悪意ある攻撃者が細工したシリアライズデータを与えると、存在しないクラスのインスタンス化や、意図しないマジックメソッドの連鎖を引き起こし、メモリ空間を混乱に陥れる。

—

2. なぜ `unserialize()` は危険なのか：マジックメソッドの罠

PHPのオブジェクト指向において、`__wakeup()` や `__destruct()` といったマジックメソッドは強力だが、デシリアライズ文脈においては「時限爆弾」になり得る。

攻撃者は、アプリケーションが意図しないクラスのインスタンスを復元させ、オブジェクトが破棄される際の `__destruct()` を利用して任意の処理を実行する（いわゆるオブジェクトインジェクション）。
さらに深刻なのは、Zend VMの参照カウント（Refcount）とGCの隙をつき、循環参照を意図的に作り出すことで、メモリ枯渇（DoS）を引き起こす手口だ。

—

3. 実務のための鉄則：安全な状態復元の設計ルール

外部入力を扱うシステムにおいて、素の `unserialize()` を直接叩くことは「アーキテクチャ上の罪」である。これを防ぐための実務的な設計ルールは以下の3点に集約される。

1. 素の `unserialize()` の全面禁止: 代わりに `json_encode` / `json_decode` を用いる。構造化データであればJSONが最も安全かつ堅牢である。
2. どうしてもシリアライズが必要な場合の型制限: `allowed_classes` オプションを必ず指定し、許可されたホワイトリスト以外のクラスの復元をハードに拒絶する。
3. HMAC等による署名検証: 永続化されたデータが改ざんされていない暗号学的証明を必ず付与する。

—

4. 実装例：安全性を極限まで高めたセキュア・デシリアライザ

では、実務の現場でそのまま採用できる、型安全かつ改ざん検知機能を備えたシリアライズ管理クラスの実装を見ていこう。PHP 8.2以降のモダンな型システムと、Zend VMのオーバーヘッドを最小限に抑える設計を取り入れている。

declare(strict_types=1);

namespace App\Security;

use InvalidArgumentException;
use RuntimeException;

脆弱性を完全に排除し、安全なシリアライズ・デシリアライズを提供するマネージャークラス
@package App\Security

/
final class SecureSerializer
{
/

許可されたクラスのホワイトリスト
@var array

/
private const ALLOWED_CLASSES = [
\App\DTO\UserSessionData::class,
\App\DTO\PreferenceSettings::class,
];

private string $secretKey;

public function __construct(string $secretKey)
{
if (mb_strlen($secretKey) < 32) { throw new InvalidArgumentException('秘密鍵は十分なエントロピー（32文字以上）を持つ必要があります。'); } $this->secretKey = $secretKey;
}

データを暗号学的署名付きでシリアライズする
@param mixed $data
@return string

/
public function serialize(mixed $data): string
{
// プリミティブなベアのserializeを使用するが、必ず署名を付与する
$serialized = serialize($data);

// HMAC-SHA256による改ざん検知署名の生成
$signature = hash_hmac(‘sha256’, $serialized, $this->secretKey, true);

// 署名とペイロードを結合して返す
return base64_encode($signature . $serialized);
}

署名を検証し、厳格なホワイトリスト制御のもとでデシリアライズを実行する
@template T
@param string $payload
@return mixed
@throws RuntimeException 改ざんや不正なクラスが検出された場合

/
public function unserialize(string $payload): mixed
{
$decoded = base64_decode($payload, true);
if ($decoded === false || mb_strlen($decoded) < 32) { throw new RuntimeException('無効なペイロードフォーマットです。'); } // 署名（前半32バイト）とデータ本体（残りのバイト）に分離 $signature = mb_substr($decoded, 0, 32, '8bit'); $serialized = mb_substr($decoded, 32, null, '8bit'); // タイミング攻撃を防ぐ安全なハッシュ比較 $calculatedSignature = hash_hmac('sha256', $serialized, $this->secretKey, true);
if (!hash_equals($signature, $calculatedSignature)) {
// ログにセキュリティインシデントとして記録すべき重大なエラー
throw new RuntimeException(‘データが改ざんされているか、署名が無効です。’);
}

// 【最重要】Zend VMレベルでのオブジェクトインジェクション対策
// allowed_classesに明示されたホワイトリスト以外のクラス復元を一切拒絶する
$data = @unserialize($serialized, [
‘allowed_classes’ => self::ALLOWED_CLASSES,
]);

if ($data === false && $serialized !== serialize(false)) {
throw new RuntimeException(‘デシリアライズ処理に失敗しました。’);
}

return $data;
}
}

コードの解説とアーキテクチャの意図

1. `allowed_classes` の強制:
`unserialize()` の第2引数にホワイトリスト（`self::ALLOWED_CLASSES`）を渡すことで、未知のクラスがZend VM上でインスタンス化されるのを物理的に遮断している。これにより、予期せぬマジックメソッド（`__wakeup`等）の暴走を防ぐ。
2. HMAC-SHA256による完全性保証:
シリアライズされた文字列自体を信頼してはならない。外部からの不正な改ざんを防ぐため、アプリケーション内部の秘密鍵で署名を付与し、`hash_equals` でタイミング攻撃耐性を持たせた検証を行っている。
3. ZendMMへの負荷配慮:
不要なメモリリークや循環参照の生成を避けるため、復元するデータ構造はDTO（Data Transfer Object）などのシンプルな値オブジェクトに限定している。

—

結びにかえて

PHPは手軽に動く言語であるゆえに、フレームワークの内部や便利な関数（`unserialize()` や `serialize()`）の背後で何が起きているかを忘れがちだ。しかし、Webシステムの規模が拡大し、コンテナ環境や高負荷なAPIサーバーとして運用される現代において、Zend VMの挙動やメモリ管理のメカニズムを理解していないコードは、いつか必ずシステム全体を崩壊させる致命傷になる。

コードレビューの場で「なぜこの関数を使うのか」「メモリとセキュリティのトレードオフはどうなっているのか」をロジカルに説明できるエンジニアであれ。その深い知見こそが、プロダクトの命運を握る最大の防壁となるのだ。