Mass Assignment та Insecure Deserialization: Глибокий технічний розбір, приклади атак та методи захисту

Mass Assignment та Insecure Deserialization — це критичні вразливості у вебзастосунках та API, які часто призводять до повного компромету системи. Обидві проблеми входять до OWASP Top 10 та регулярно зустрічаються в реальних кейсах Bug Bounty (Shopify, Uber, PayPal, GitHub).

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

1. Mass Assignment: що це?

Mass Assignment — це вразливість, при якій бекенд автоматично приймає та записує до бази значення полів, які користувач не повинен мати права змінювати.

Типовий приклад: бекенд автоматично мапить JSON-вхід на модель:

POST /api/user/update
{
    "name": "Alex",
    "role": "admin"
}

Якщо модель User автоматично приймає всі поля з вхідних даних — зловмисник може підвищити собі роль, змінити конфігурації або активувати приховані параметри.

1.1. Де найчастіше зустрічається:

• Laravel (під час неправильного використання fillable/guarded)
• Ruby on Rails (класичне місце появи цієї вразливості)
• Node.js (Mongoose, Sequelize)
• Java Spring (Jackson auto-binding)
• Python Django (ModelForm / serializers)

1.2. Критичні поля, які часто зламують через Mass Assignment:

• role / is_admin / permissions
• email_verified / phone_verified
• balance / credits / premium
• is_active / banned / status
• owner_id / user_id / organization_id

2. Реальні кейси Mass Assignment

2.1. Uber (Bug Bounty)

В одній з мобільних API Uber дослідник міг змінити поле is_staff та is_admin, просто передавши їх у JSON-запиті. Framework автоматично брав усі поля без whitelist.

Наслідок: повне захоплення адмін-панелі.

2.2. Shopify

Через неправильний whitelist у GraphQL API дослідники могли додавати “hidden” поля та активувати приховані функції магазину.

2.3. GitHub Enterprise (старий API)

Адміністративний параметр user[site_admin] був доступний у масовій зміні, що дозволяло підвищувати привілеї.

3. Як виявити Mass Assignment

Під час тестування API:

• списком додавати всі можливі admin-поля у JSON
• спробувати змінювати приховані поля (is_admin=true, role=owner)
• завантажити мобільний застосунок та знайти поля в локальному коді
• спробувати передавати внутрішні поля моделі, навіть якщо в UI їх немає

{
    "premium": true,
    "role": "superadmin",
    "email_verified": true
}

4. Як захиститися від Mass Assignment

• використовувати whitelists (fillable)
• ніколи не довіряти клієнтським полям
• окремі DTO / серіалізатори для читання та запису
• заборонити передавати поля ролей та статусів через API
• обов’язкова серверна перевірка прав на зміну будь-якого поля

5. Insecure Deserialization

Insecure Deserialization — це процес, коли вебзастосунок приймає серіалізовані дані (JSON, PHP object, pickle, Java object, JWT, XML), а потім небезпечно їх десеріалізує. У деяких мовах це може призвести до Remote Code Execution (RCE).

Мови та фреймворки, що найбільше страждають:

• PHP (unserialize, phar:// атаки)
• Java (Apache Commons, WebLogic, Jenkins)
• .NET BinaryFormatter
• Python pickle
• Ruby Marshal

6. Як працює атака?

Атакувальник передає шкідливий серіалізований об’єкт, який при розпаковці викликає код або змінює параметри системи.

O:8:"UserData":2:{s:5:"admin";b:1;s:4:"name";s:4:"Evil";}

Якщо PHP-клас виконує код у __wakeup() або __destruct(), атакувальник може інжектити payload.

7. Реальні кейси Insecure Deserialization

7.1. Jenkins RCE

Одна з найвідоміших вразливостей: Jenkins приймав Java-серіалізовані об’єкти, що дозволяло виконувати довільний код.

7.2. WebLogic (Oracle) RCE

Величезна кількість експлойтів базувалася на вразливій Java-десеріалізації.

7.3. PHP вразливість через phar://

Навіть якщо застосунок не використовує unserialize(), але обробляє архіви або файли — можна викликати десеріалізацію через метадані PHAR.

7.4. Python pickle exploit у ML-системах

Популярні фреймворки для машинного навчання серіалізують моделі через pickle, який дозволяє виконання довільного коду під час завантаження.

8. Як знаходити Insecure Deserialization

Ознаки:

• API приймає serialized формати (php, java, pickle)
• JWT без перевірки підпису
• cookie у форматі Base64, що розкодовуються в об’єкти
• XML із складними структурами (XStream)

Методи тестування:

• fuzzing полів, що містять object-like дані
• спроба передати шкідливий серіалізований об’єкт
• перевірка blacklisted класів у Java
• пошук __wakeup(), __destruct() у PHP-класах

9. Як захиститися

• заборонити десеріалізацію даних від користувача
• використовувати JSON замість об’єктних форматів
• перевіряти підпис у JWT, session tokens
• налаштувати allowlist класів (Java)
• повністю заборонити pickle, unserialize, Marshal у production
• використовувати цифрові підписи для серіалізованих даних

Висновок

Mass Assignment та Insecure Deserialization — два різних класи вразливостей, але обидві проблеми виникають через неправильно реалізовану логіку обробки даних. Mass Assignment дозволяє зловмиснику змінювати приховані параметри моделі, тоді як Insecure Deserialization може призвести до повного RCE та повного компромету системи.

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