Проблеми бінарної серіалізації: безпека, сумісність

1. Безпека бінарної серіалізації

Серіалізація в Java — це не просто збереження полів об’єкта. Це можливість «відновити» будь-який об’єкт із будь-яким вмістом, якщо лише він реалізує інтерфейс Serializable. Здавалося б, зручно! Але якщо ваш застосунок десеріалізує дані, отримані з недовіреного джерела (наприклад, із мережі або з файла, який міг підмінити зловмисник), він ризикує стати жертвою атак.

Як це працює?

Під час десеріалізації Java створює об’єкти на основі байтового потоку, не викликаючи конструктори класів. Якщо в класі реалізовано спеціальні методи на кшталт readObject, їх буде викликано автоматично. Зловмисник може «сконструювати» потік байтів так, щоб під час десеріалізації виконати вразливий код.

Приклад: атака «gadget chain»

Уявіть, що у вас є клас, який під час десеріалізації запускає зовнішню команду (читає файл або викликає shell). Якщо зловмисник знає, що застосунок десеріалізує об’єкти певних типів, він може підкласти спеціальний потік байтів, який призведе до виконання шкідливого коду. Такі атаки будуються як «ланцюжок гаджетів» — послідовність викликів, що завершується небезпечною операцією.

Чому це так критично?

Десеріалізація — це процес, у якому з потоку даних відновлюються реальні об’єкти, і в цей момент може виконатися довільний код. Якщо дані надходять із недовіреного джерела, це відчиняє двері для віддаленого виконання команд (RCE). Великі компанії публікували рекомендації щодо відмови від небезпечної десеріалізації; у сучасних корпоративних проєктах бінарна серіалізація часто заборонена політиками безпеки.

Як захиститися?

• Ніколи не десеріалізуйте об’єкти з недовірених джерел.
• Використовуйте whitelisting — явний список дозволених типів для десеріалізації.
• Надавайте перевагу текстовим форматам для зовнішніх інтеграцій: JSON, XML.
• Якщо серіалізація неминуча, використовуйте бібліотеки з налаштуваннями безпечної десеріалізації (наприклад, Jackson з обмеженням типів).
• Обмежте використання нестандартних методів серіалізації (readObject, readResolve тощо), якщо не впевнені в їхній безпеці.

2. Сумісність версій класів

Бінарна серіалізація в Java жорстко прив’язана до структури класу. Серіалізували об’єкт у версії 1.0, потім оновили клас (додали/видалили поле) — спроба десеріалізувати «старий» об’єкт у нову версію може призвести до помилки або втрати даних.

Як Java визначає сумісність?

Для цього використовується спеціальне поле — serialVersionUID. Це ідентифікатор версії класу. Якщо в серіалізованого об’єкта один serialVersionUID, а в поточного класу інший — буде кинуто InvalidClassException, і десеріалізація не відбудеться.

import java.io.Serializable;

public class User implements Serializable {
    private static final long serialVersionUID = 1L; // явно вказали версію

    private String name;
    private int age;
}

Якщо ви зміните структуру класу (наприклад, додасте поле email) і не зміните serialVersionUID, Java вважатиме клас сумісним і спробує десеріалізувати старий об’єкт. Якщо ж ви не вказали serialVersionUID явно, JVM згенерує його автоматично на основі структури, і будь-яка зміна призведе до несумісності.

Що відбувається у разі невідповідності або відповідності версій?

Якщо ідентифікатори не збігаються — десеріалізація не відбудеться: InvalidClassException. Якщо збігаються — поля зіставляються за іменем і типом: нові поля отримають значення за замовчуванням (null, 0), видалені — ігноруються. Під час зміни типу або імені поля можливі помилки та некоректна інтерпретація даних.

Практична порада. У серіалізованих класах завжди задавайте явний serialVersionUID. Змінюйте його лише у разі несумісних змін (видалення або зміни типу важливого поля). Під час додавання нових полів ідентифікатор можна залишити попереднім — JVM коректно обробить старі об’єкти.

Таблиця: що буде під час зміни класу

3. Обмеження стандартної серіалізації

Не всі об’єкти можна серіалізувати

Поля з модифікаторами transient і static не серіалізуються. static — тому що належить класу, а не об’єкту; transient — тому що ви явно заборонили серіалізацію поля.

Деякі об’єкти за визначенням не підлягають серіалізації: Thread, з’єднання з БД, сокети, Scanner тощо. Якщо у вашому класі є поле такого типу і воно не transient, отримаєте NotSerializableException.

import java.io.Serializable;
import java.util.Scanner;

public class Session implements Serializable {
    private transient Scanner scanner; // не серіалізується!
    private String login;
}

Проблеми з продуктивністю та розширюваністю

Серіалізація великих графів об’єктів може бути повільною та вимогливою до пам’яті.

Бінарний формат погано підходить для інтеграцій з іншими платформами та мовами — його «розуміє» лише Java.

Складно контролювати, що саме серіалізується, особливо за глибоких ієрархій і циклічних посилань.

Проблеми з підтримкою старих даних

Довготривале зберігання бінарних зліпків — ризик. Через рік-два структура класів змінюється, і старі файли перестають завантажуватися.

Реальна історія: «Ми зберегли серіалізований кеш користувачів три роки тому, оновили застосунок, а тепер не можемо його завантажити. Привіт, втрачені дані!»

4. Найкращі практики: як не потрапити в пастки

• Використовуйте бінарну серіалізацію лише для внутрішніх задач, де ви контролюєте обидві сторони процесу.
• Не використовуйте бінарну серіалізацію для зовнішніх інтеграцій і довготривалого зберігання важливих даних.
• Завжди явно вказуйте serialVersionUID у серіалізованих класах.
• Позначайте поля, які не повинні серіалізуватися, модифікатором transient.
• Для обміну із зовнішніми системами — текстові формати та сучасні бібліотеки: JSON, XML, Jackson, Gson, JAXB.
• Для сумісності використовуйте версіонування: зберігайте версію об’єкта в самому класі та адаптуйте обробку під час десеріалізації.
• Якщо серіалізація потрібна лише для кешу — не підтримуйте сумісність будь-якою ціною: кеш простіше перерахувати.
• Не зберігайте в серіалізованих об’єктах чутливі дані (паролі, ключі) — серіалізація не шифрує дані.

5. Типові помилки під час роботи з бінарною серіалізацією

Помилка № 1: Десеріалізація даних із недовіреного джерела. Найнебезпечніша помилка — приймати й десеріалізувати об’єкти, що прийшли «з вулиці» (із мережі, від користувача, із підміненого файла). Це прямий шлях до вразливостей аж до RCE.

Помилка № 2: Неявна зміна структури класу без оновлення serialVersionUID. Якщо не вказати ідентифікатор явно, JVM згенерує його автоматично. Будь-яка зміна структури (навіть порядок полів) призведе до несумісності та неможливості завантажити старі об’єкти.

Помилка № 3: Спроба серіалізувати об’єкти з полями, що не серіалізуються. Якщо в класі є поле, яке не реалізує Serializable, і воно не transient, серіалізація завершиться винятком.

Помилка № 4: Збереження в серіалізованих об’єктах тимчасових або чутливих даних. Токени, паролі, тимчасові дескриптори ресурсів — усе це може випадково опинитися у файлі.

Помилка № 5: Використання бінарної серіалізації для довготривалого зберігання й обміну між версіями. Після першого оновлення класів високий ризик «битих» даних і проблем із сумісністю.

Помилка № 6: Очікування, що поля static і transient «відновляться» після десеріалізації. Ці поля не серіалізуються; після завантаження вони матимуть значення за замовчуванням.