API BOLA: Доступ к чужим заказам

# BOLA: Broken Object Level Authorization в API заказов ## Сценарий Вы — клиент сервиса доставки гаджетов **МерчЛаб** и заодно аудируете его JSON API. У сервиса есть REST-эндпоинт: список заказов конкретного пользователя по идентификатору в пути. Команда уверена в безопасности — эндпоинт закрыт аутентификацией. Внутренний аудит знает больше: в системе заведён служебный заказ администратора с конфиденциальной меткой, и его реально прочитать, имея лишь обычную учётную запись. ## Цель 1. Изучите URL-схему эндпоинта заказов: где передаётся идентификатор пользователя и кто его контролирует. 2. Не обходя аутентификацию, добудьте заказы другого пользователя — только изменением параметров запроса. 3. Найдите среди чужих заказов служебную запись с флагом. ## Теория BOLA (Broken Object Level Authorization, №1 в OWASP API Security Top 10) — IDOR в мире JSON API: эндпоинт проверяет, что запрос аутентифицирован, но не проверяет, что запрашивающий владеет объектом. Идентификатор из URL напрямую попадает в запрос к базе. Ответ API структурирован и предсказуем, поэтому перебор идентификаторов автоматизируется в пару строк. **Уязвимый паттерн:** ```go // идентификатор из URL уходит в SQL без проверки владельца userID := r.PathValue("id") rows, _ := db.Query("SELECT ... FROM orders WHERE user_id=?", userID) ``` Механика атаки: аутентификация подтверждает, кто отправил запрос, но выборка читает заказы того, чей идентификатор стоит в пути. Достаточно подставить чужой последовательный ID — и API отдаст чужие записи. Защита — объектная авторизация: сервер сверяет идентификатор из пути с владельцем сессии до всякого обращения к данным. ## Точка входа атаки `GET /api/users/{id}/orders` — JSON-список заказов пользователя `{id}`; требуется валидная сессия. Свой идентификатор подскажет соседний эндпоинт `GET /api/me`. * Обычный пользователь: `demo` / `demo`