【PHPセキュリティ】unserialize()の脆弱性とオブジェクトインジェクション対策｜安全な代替コード解説

このペイロードが unserialize() に渡されると、スクリプト終了時に __destruct() が自動実行され、/var/www/html/public/backdoor.php にWebシェルが書き込まれてしまいます。その結果、サーバーが完全に遠隔操作される危険に晒されます。

3. 【実務コード付き】安全な対策と代替実装の4ステップ

unserialize() の脆弱性を根絶し、安全なシステムを構築するための4つのステップと実践コード例を解説します。

ステップ①：allowed_classes オプションでオブジェクト生成を遮断する

PHP 7.0以降、unserialize() には第2引数として $options が追加されました。既存のシリアライズ形式のデータを読み込む必要がある場合は、必ず allowed_classes を明示してください。

<?php
// 【最も安全】配列やスカラー値のみを許可し、すべてのオブジェクト生成を禁止する
$data = unserialize($serializedString, ['allowed_classes' => false]);

if ($data === false && $serializedString !== 'b:0;') {
    // デシリアライズ失敗時の適切なエラーハンドリング
    error_log('Failed to unserialize data safely.');
    $data = [];
}

オブジェクトが不要な設定配列やキャッシュデータであれば、allowed_classes => false を指定するだけで、オブジェクトインジェクション攻撃を完全に防御できます。もしオブジェクトの復元が不可欠な場合でも、信頼できるクラスのみをホワイトリスト形式で配列指定します。

// 特定の安全なクラスのみ復元を許可する場合（ホワイトリスト方式）
$data = unserialize($serializedString, [
    'allowed_classes' => [
        \App\DTO\UserProfileData::class,
        \DateTimeImmutable::class,
    ]
]);

※ホワイトリストを指定した場合でも、許可したクラス自体に脆弱なマジックメソッドが含まれていると攻撃を受けるリスクが残ります。そのため、極力 allowed_classes => false を使用し、次に紹介するJSON形式への移行を優先してください。

ステップ②：JSON形式（json_encode / json_decode）へ完全移行する

新規の開発やリファクタリングにおいて、データの保存形式には serialize ではなく json_encode() / json_decode() を採用することがPHP公式およびセキュリティ標準で強く推奨されています。

以下は、実務で安全にJSONシリアライズ・デシリアライズを行うリファクタリング例です。PHP 7.3以降で導入された JSON_THROW_ON_ERROR フラグを活用し、構文エラーを確実に例外処理します。

<?php
class JsonDataHandler {
    /**
     * データを安全にJSON文字列化する
     */
    public static function encode(mixed $data): string {
        try {
            return json_encode($data, JSON_THROW_ON_ERROR | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
        } catch (\JsonException $e) {
            error_log('JSON Encode Error: ' . $e->getMessage());
            throw new \RuntimeException('データのエンコードに失敗しました。', 0, $e);
        }
    }

    /**
     * JSON文字列から連想配列として安全に復元する
     */
    public static function decode(string $json): array {
        try {
            $result = json_decode($json, true, 512, JSON_THROW_ON_ERROR);
            return is_array($result) ? $result : [];
        } catch (\JsonException $e) {
            error_log('JSON Decode Error: ' . $e->getMessage());
            return [];
        }
    }
}

// 使用例
$userData = [
    'user_id' => 1001,
    'username' => 'mozcheck_dev',
    'permissions' => ['read', 'write'],
    'updated_at' => (new \DateTimeImmutable())->format(\DateTimeInterface::ATOM)
];

$savedJson = JsonDataHandler::encode($userData);
$restored = JsonDataHandler::decode($savedJson);

クラスオブジェクトをJSONで扱う場合（JsonSerializableの実装）

クラスオブジェクトの構造を維持して保存・復元したい場合は、JsonSerializable インターフェースとスタティックファクトリメソッドを実装するのが最もセキュアでクリーンな設計です。

<?php
class UserSetting implements \JsonSerializable {
    public function __construct(
        private string $theme,
        private bool $notificationsEnabled,
        private array $dashboardWidgets
    ) {}

    /**
     * json_encode 時に出力する配列を定義
     */
    public function jsonSerialize(): array {
        return [
            'theme' => $this->theme,
            'notifications_enabled' => $this->notificationsEnabled,
            'dashboard_widgets' => $this->dashboardWidgets,
        ];
    }

    /**
     * デコードした配列から安全にインスタンスを再構築
     */
    public static function fromArray(array $data): self {
        return new self(
            (string) ($data['theme'] ?? 'light'),
            (bool) ($data['notifications_enabled'] ?? true),
            (array) ($data['dashboard_widgets'] ?? [])
        );
    }
}

ステップ③：破損したシリアライズ文字列の自動修復関数

データベース移行や文字コード変換によって「Error at offset ...」が発生し、過去のデータが読み込めなくなった場合は、以下の自動修復ヘルパー関数を利用して文字列のバイト長を再計算して安全にデシリアライズできます。

<?php
/**
 * 破損したシリアライズ文字列のバイト数を自動補正して安全に復元する
 *
 * @param string $serializedString 破損したシリアライズ文字列
 * @return mixed 復元されたデータ（復元不可の場合は null）
 */
function repair_and_unserialize_safe(string $serializedString): mixed {
    if (empty($serializedString)) {
        return null;
    }

    // まずは allowed_classes => false で安全にそのまま試行
    $result = @unserialize($serializedString, ['allowed_classes' => false]);
    if ($result !== false || $serializedString === 'b:0;') {
        return $result;
    }

    // 文字列長宣言 s:XX:"..." を実際のバイト数（strlen）で再計算して置換
    $repaired = preg_replace_callback(
        '/s:(\d+):"(.*?)";/s',
        function ($matches) {
            $realByteLength = strlen($matches[2]);
            return 's:' . $realByteLength . ':"' . $matches[2] . '";';
        },
        $serializedString
    );

    $result = @unserialize($repaired, ['allowed_classes' => false]);
    return $result !== false ? $result : null;
}

// テスト実行例
// 本来「セキュリティ」は UTF-8で15バイトだが、Shift_JIS移行で s:10 に破損したデータ
$brokenSerialized = 's:10:"セキュリティ";';
$restoredData = repair_and_unserialize_safe($brokenSerialized);
var_dump($restoredData); // string(15) "セキュリティ" が正常に復元される

ステップ④：改ざん検知（HMAC署名）の導入（必要な場合）

Cookieや外部ストレージなどにやむを得ずシリアライズデータを保存する場合は、秘密鍵を用いた HMAC署名 を付与し、改ざんされていないことを検証してからデシリアライズする仕組みが必須です。

<?php
class SecurePayload {
    private const SECRET_KEY = 'YOUR-VERY-SECURE-SECRET-KEY-CHANGE-ME';

    /**
     * データにHMAC署名を付与してシリアライズ
     */
    public static function sign(mixed $data): string {
        $json = json_encode($data, JSON_THROW_ON_ERROR | JSON_UNESCAPED_UNICODE);
        $signature = hash_hmac('sha256', $json, self::SECRET_KEY);
        return base64_encode($signature . '::' . $json);
    }

    /**
     * 署名を検証して安全にデータを復元
     */
    public static function verifyAndUnpack(string $payload): ?array {
        $decoded = base64_decode($payload, true);
        if ($decoded === false || !str_contains($decoded, '::')) {
            return null;
        }

        [$signature, $json] = explode('::', $decoded, 2);
        $expectedSignature = hash_hmac('sha256', $json, self::SECRET_KEY);

        // タイミング攻撃を防ぐため hash_equals で比較
        if (!hash_equals($expectedSignature, $signature)) {
            error_log('Payload signature verification failed! Possible tampering attempt.');
            return null;
        }

        return json_decode($json, true);
    }
}

4. WordPress環境における注意点と脆弱性事例

WordPressは歴史的経緯から、データベースの wp_options や wp_postmeta テーブル内のデータ保存にシリアライズ形式を多用しています。WordPressの開発・運用においては以下の点に留意が必要です。

WordPressコア関数 maybe_unserialize() の挙動

WordPressには、渡されたデータがシリアライズ文字列であればデシリアライズして返し、そうでなければそのまま返す maybe_unserialize() というヘルパー関数があります。get_post_meta() や get_option() の内部でも自動的に呼び出されます。

WordPressコアでは is_serialized() による事前判定や内部的な対策が進められていますが、プラグインやテーマの独自処理でユーザー入力をそのまま maybe_unserialize() や unserialize() に渡してしまうと、即座にオブジェクトインジェクションの標的となります。

実際に発生したWordPressプラグインの脆弱性事例

過去、著名なWordPressプラグインでも unserialize() の不適切な利用に起因する脆弱性が数多く報告されています。

• CVE-2025-7696（Integration for Contact Form 7 and Pipedrive）: フォーム送信データ等のデシリアライズ処理において、未認証の攻撃者が任意のPHPオブジェクトを注入可能な深刻な脆弱性が発見されました（詳細: [CVE-2025-7696] プラグインにおける未認証PHPオブジェクトインジェクションの危険性と対応策）。
• CVE-2024-10957（UpdraftPlus）: バックアップ処理に関連するデータ解析で unserialize() の直接利用が問題視され、独自ラッパー関数による厳格な型チェックと allowed_classes 制御への移行修正が行われました。

WordPressプラグインやカスタムテーマの開発では、ユーザー入力のサニタイズだけでなく、nonceによるリクエスト正当性の検証や適切な権限チェックを組み合わせることが必須です。

• 関連解説: WordPressのnonceを理解しセキュアな機能開発へステップアップ – [CVE-2025-1463]脆弱性解説
• 関連解説: WordPressプラグインの脆弱性情報を解説: CSRF脆弱性への対策を実例から解説
• 関連解説: 放置していたWordPressは安全？標準機能の自動更新と安全性の仕組み

5. 自社サイトの安全性をチェック！MozCheck無料診断

WebサイトやWordPress環境のセキュリティリスクは、コードレベルの脆弱性だけでなく、古いプラグインの放置、不要なファイルの露出、SSL/ヘッダー設定の不備など多岐にわたります。

WordPress安心診断ツール「MozCheck」なら、サイトのURLを入力するだけで、インストールされているプラグインの既知の脆弱性やセキュリティヘッダー、更新状況を無料で包括的に自動診断できます。

開発中のテスト環境や本番運用の定期チェックに、ぜひご活用ください。

▶ WordPress安心診断 by MozCheck で無料セキュリティ診断を試す

6. まとめ：PHPセキュリティのベストプラクティス

unserialize() に潜む脆弱性とエラー対策の要点をまとめます。

• 新規実装では unserialize() を原則使わない: データ構造の保存には json_encode() / json_decode() を標準採用する。
• 既存データのデシリアライズには allowed_classes を必須指定: 配列・スカラー値の復元なら ['allowed_classes' => false] を必ず付与する。
• ユーザー入力・外部入力を直接デシリアライズしない: 正規表現によるフィルタリングだけではPOPチェーンを防ぎきれないため、入力経路そのものを遮断する。
• 定期的なセキュリティ診断とアップデートを実施: 依存ライブラリやWordPressプラグインの脆弱性情報を常に把握し、安全な運用体制を維持する。

堅牢なコード設計と適切なデータフォーマットの選択を行い、セキュアなPHPアプリケーション開発を推進しましょう。