Access Control: Горизонтальная эскалация через API

# Управление доступом: горизонтальная эскалация в API ## Сценарий Вы — специалист по безопасности компании «ГикВитрина» — небольшого интернет-магазина фирменного мерча для разработчиков, построенного на Flask. Помимо каталога и корзины, у каждого покупателя есть личные заметки: черновики заказов, напоминания, рабочие записи. Перед подключением нового платёжного провайдера руководитель попросил проверить, не может ли один покупатель добраться до данных другого через REST API: у партнёра по маркетплейсу похожая оплошность недавно обернулась утечкой. ## Цель 1. Войдите как обычный покупатель и найдите REST-эндпоинт, через который страница заметок загружает ваши данные. 2. Подтвердите, что сервер не сверяет идентификатор в этом запросе с вашей сессией, и прочитайте заметки другого пользователя. 3. Доберитесь до заметок самого привилегированного аккаунта системы и извлеките флаг из их содержимого. ## Теория Аутентификация отвечает на вопрос «кто вы», а авторизация на объект — «ваш ли это ресурс». В эндпоинте заметок проверяется только первое: сессия обязательна, но идентификатор владельца берётся из параметра пути и без дополнительной проверки уходит в запрос к базе. **Уязвимый паттерн:** ```python rows = db.execute( 'SELECT id, title, content, created_at FROM notes WHERE user_id=?', (user_id,) ).fetchall() ``` Идентификатор в адресе запроса контролируется клиентом, поэтому смена одного числа превращает запрос за своими заметками в запрос за чужими. Фронтенд честно подставляет идентификатор текущего пользователя, но безопасность интерфейса не защищает сервер: любой вошедший может запросить данные произвольного аккаунта. Такой класс уязвимостей называют горизонтальной эскалацией привилегий (BOLA/IDOR). ## Точка входа атаки `GET /api/users/<user_id>/notes` — идентификатор пользователя передаётся сегментом пути URL. Для входа в приложение используйте форму `POST /login` с полями `username` и `password`. * **Обычный покупатель:** `demo` / `demo`