Insecure Deserialization: JSON Class Markers

# Небезопасная десериализация: класс-маркер в JSON ## Сценарий **DevParts** — магазин комплектующих для разработчиков с личным кабинетом и JSON API обновления профиля. Разработчик хотел сделать API «гибким» и реализовал полиморфную десериализацию: специальный служебный ключ в теле запроса выбирает, объект какого класса собрать из присланных данных. Руководитель проекта, перечитывая код после релиза, усомнился в этой гибкости и заказал аудит: не даёт ли механизм клиенту лишней власти. ## Цель 1. Авторизуйтесь как обычный пользователь и изучите API обновления профиля. 2. Определите, как служебный ключ во входном JSON влияет на тип создаваемого сервером объекта. 3. Повысьте роль своего аккаунта до администратора через найденный механизм. 4. Получите CTF-флаг на странице профиля. ## Теория Insecure Deserialization (CWE-502) — ситуация, когда сервер строит объекты из данных, которым не должен доверять. Здесь API принимает JSON с произвольными ключами, а служебный маркер выбирает класс из серверного реестра: объект конструируется из остальных полей запроса, и его атрибуты переносятся в профиль пользователя. Классы реестра различаются ролями — среди них есть привилегированный. **Уязвимый паттерн:** ```python obj = cls(**data) # класс выбрал клиент своим JSON profile_data = obj.to_dict() # атрибуты объекта уезжают в базу ``` Без маркера роль пользователя берётся из базы и не меняется. С маркером роль становится частью данных, которые прислал клиент: достаточно выбрать класс с административной ролью — и эскалация привилегий записана в профиль. Класс проблемы — Insecure Deserialization (OWASP A08:2021 Software and Data Integrity Failures). ## Точка входа атаки `POST /api/profile/update` — JSON API обновления профиля; тело — объект с полями профиля и служебным ключом. Вход: `POST /login`. * **Пользователь:** `demo` / `demo`