API Mass Assignment: Повышение привилегий через PUT

# Mass Assignment: повышение привилегий через JSON API профиля ## Сценарий Вы — покупатель сервиса **СмартВитрина** и заодно аудируете его JSON API профиля. Данные читаются GET-запросом и обновляются PUT-запросом: страница профиля меняет отображаемое имя и ссылку на аватар. Роль показана бейджем, но элемента для её изменения в интерфейсе нет. Внутренний аудит установил: после успешного обновления сервер возвращает проверочный маркер в JSON-поле `flag` — но только если роль аккаунта стала административной. ## Цель 1. Откройте GET-эндпоинт профиля и изучите поля JSON-ответа. 2. Найдите поле, которое видно в ответе, но недоступно для редактирования в интерфейсе, и проверьте прямой запрос к JSON API в обход страницы. 3. Повысьте привилегии текущей учётной записи и извлеките маркер из поля `flag` ответа на обновление. ## Теория Mass Assignment возникает, когда граница атрибутов, разрешённых для самообслуживания, не совпадает с границей авторизации: обработчик применяет к базе поля, которые клиенту менять нельзя. Само по себе декодирование JSON не опасно — опасен список ключей, которые обработчик готов записать. **Уязвимый паттерн:** ```go // switch ошибочно разрешает привилегированное поле наравне с обычными for field, value := range updates { switch field { case "fullname", "avatar_url", "role": db.Exec("UPDATE users SET "+field+"=? WHERE id=?", value, user.ID) } } ``` Механика атаки: интерфейс редактирует только часть полей профиля, но API принимает JSON напрямую. Достаточно добавить в тело запроса ключ с привилегированным атрибутом — и сервер применит его к записи пользователя как обычное обновление. Защита — строгий список полей самообслуживания: серверные атрибуты (роль, баланс, флаги) не попадают в него ни при каких условиях. ## Точка входа атаки `GET /api/user` — чтение профиля (JSON); `PUT /api/user` — обновление (JSON body). Оба требуют валидную сессию. * Обычный пользователь: `demo` / `demo`