Laravel Ukraine Слава Україні!
Увійти Реєстрація
Блог Серії
Кар'єра
Вакансії Компанії
Навчання
Документація Співбесіди Тестування Відео
Екосистема
Пакети Ресурси Проєкти Інструменти Події
Інше
Про нас

PHP serialize вьюер

Розібрати serialize()-рядок із сесії, кеша або БД

Дані надсилаються на сервер, але не зберігаються

Цей інструмент не можна виконати у браузері, тому введені дані надсилаються на наш сервер. Ми обробляємо їх у пам'яті та одразу повертаємо результат: нічого не записується в базу, у файли чи в логи, нічого не передається третім сторонам. Та все ж не вставляйте сюди справжні робочі паролі чи ключі - для чутливих даних краще скористатися локальними інструментами.

Поділитись

Що таке serialize()

serialize() перетворює будь-яке значення PHP - масив, об'єкт, число - на рядок, який потім можна покласти в базу, у файл або в кеш. unserialize() робить зворотну операцію.

Формат читається очима, якщо знати позначення:

a:2:{s:4:"name";s:5:"Тарас";i:0;b:1;}
│ │  │        │
│ │  │        └─ значення: рядок довжиною 5
│ │  └────────── ключ: рядок довжиною 4
│ └───────────── кількість елементів
└─────────────── тип: a=array, s=string, i=int, b=bool, d=float, N=null, O=object

Довжина рядків рахується в байтах, не в символах. Тому «Тарас» - це s:10, а не s:5: п'ять кириличних літер займають десять байтів. Це найчастіша причина «пошкодженого» serialize-рядка після необережного str_replace або зміни кодування колонки.

Де ви зустрінете це в Laravel

  • Сесії: драйвери file, database та redis зберігають дані сесії серіалізованими.
  • Кеш: усе, що не є простим рядком, лягає в кеш через serialize().
  • Черги: тіло задачі серіалізується перед відправкою у Redis чи базу.
  • Каст array: у моделях Laravel використовує JSON, а не serialize - і це свідомо краще.
  • Старий код: колонки з serialize($data) замість JSON досі трапляються в legacy-проєктах.

Головна небезпека: object injection

unserialize() створює об'єкти. Якщо дані прийшли ззовні, зловмисник може підсунути рядок, який створить об'єкт довільного класу з довільними властивостями. Далі спрацює магічний метод - __wakeup(), __destruct(), __toString() - і код виконається.

Це не теоретична вразливість: саме так ламали Magento, WordPress-плагіни та десятки Laravel-проєктів, які приймали serialize від клієнта.

// Небезпечно, якщо $input прийшов від користувача
$data = unserialize($input);

// Безпечно: об'єкти не створюються взагалі
$data = unserialize($input, ['allowed_classes' => false]);

// Або дозволити лише конкретні класи
$data = unserialize($input, ['allowed_classes' => [Money::class]]);

Цей інструмент працює саме з allowed_classes: false, тому вставити сюди чужий serialize-рядок безпечно: об'єкт покажеться як дані з ім'ям класу, але нічого не виконається.

serialize чи JSON

Для нових даних - майже завжди JSON.

serialize JSON
Читається людиною ні так
Читається іншою мовою ні так
Зберігає типи PHP точно так ні (об'єкти стають масивами)
Ризик object injection так ні
Запити всередину колонки в БД ні так (-> у MySQL і PostgreSQL)

Останній рядок вирішальний: JSON-колонку можна фільтрувати запитом, serialize - тільки витягнути й розпакувати в PHP.

// JSON-каст: працює як масив, зберігається як JSON, шукається запитом
protected function casts(): array
{
    return ['settings' => 'array'];
}

User::where('settings->theme', 'dark')->get();

serialize виправданий там, де важливо відновити значення точно таким, яким воно було, - наприклад, тіло задачі в черзі, де об'єкт має ожити тим самим класом.