Insecure Deserialization: Pickle RCE

# Небезопасная десериализация: выполнение кода через cookie ## Сценарий Вы проводите аудит **QuantaGoods** — интернет-магазина на Flask. В прошлом квартале стажёр вынес пользовательские настройки интерфейса (тему, язык, уведомления) из базы в cookie: так настройки переживают выход из аккаунта и сразу видны на всех устройствах. Ревью кода тогда прошло мимо этой правки, и теперь внешний аудитор, нанятый после неудачного пентеста, просит проверить всё, что сервер читает из клиентских данных. В кеше браузера настроечный cookie выглядит как цепочка символов кодировки base64. После декодирования остаётся бинарный поток, а выбранный формат сериализации — это по спецификации не «формат данных», а исполняемая среда: во время разбора такого потока интерпретатор выполняет описанные в нём действия. Это превращает безобидные «настройки темы» в канал **Remote Code Execution** на сервере. ## Цель 1. Авторизуйтесь как обычный пользователь и найдите страницу настроек интерфейса; определите, какой cookie она использует и что содержит его значение после декодирования. 2. Найдите в приложении вторую точку, где сервер принимает сериализованные данные того же формата. 3. Сформируйте объект, который во время разбора на сервере выполнит выбранную вами операцию с параметрами. 4. С помощью полученного выполнения кода прочитайте серверный секрет, в котором хранится флаг, — результат вернётся в ответе приложения. ## Теория Формат сериализации в этой лабораторной умеет выражать не только данные, но и вызовы: в поток можно записать пару «функция и её аргументы», и при десериализации интерпретатор эту пару честно выполнит. Сервер, который разбирает присланные клиентом байты в таком формате, исполняет чужую программу с правами серверного процесса. Подпись или кодировка не меняют сути: base64 — это транспорт, а опасен сам формат. **Уязвимый паттерн:** ```python raw = base64.b64decode(pref_cookie) prefs = pickle.loads(raw) ``` Значение cookie декодируется и сразу передаётся десериализатору без каких-либо проверок источника и содержимого. ## Точка входа атаки * `GET /preferences` — чтение настроечного cookie `user_prefs` (значение — base64-обёртка сериализованных данных); `POST /preferences` — легитимная запись настроек. * `POST /api/run-report` — альтернативный канал: сериализованные данные принимаются телом запроса. **Пользователь:** `demo` / `demo`