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

# BOLA: Broken Object Level Authorization в JSON API ## Сценарий Вы аудируете JSON API интернет-магазина **SecureShop**. У приложения есть REST-эндпоинт получения списка заказов конкретного пользователя по идентификатору в URL. Команда уверена, что эндпоинт безопасен — он защищён аутентификацией, и пользователь видит только свои заказы. По данным внутреннего аудита, в системе есть служебный заказ с конфиденциальной меткой, размещённый администратором; её требуется извлечь, имея только обычную учётную запись. ## Цель 1. Изучите URL-схему API получения заказов — какой идентификатор пользователя передаётся и где (в URL, в теле, в заголовке). 2. Найдите способ получить заказы пользователя, не являющегося текущим — без обхода аутентификации, только через изменение параметров запроса. 3. Извлеките флаг из служебного заказа. ## Теория BOLA (Broken Object Level Authorization) — уязвимость, занимающая первое место в OWASP API Security Top 10 — частный случай IDOR применительно к JSON API. Возникает, когда API использует пользовательский ввод (идентификатор объекта в URL, query-параметре, теле запроса) как прямую ссылку на ресурс БД, проверяет факт аутентификации, но **не проверяет авторизацию** — то есть, имеет ли запрашивающий пользователь право доступа к этому конкретному объекту. Особенность API против классического web — структурированный JSON-ответ с предсказуемой схемой, что упрощает автоматизацию: атакующему не нужно парсить HTML, достаточно изменить путь и распарсить JSON. **Уязвимый паттерн:** ```go // SQL-запрос использует ID из URL, а не из аутентифицированной сессии userID := r.PathValue("id") rows, _ := db.Query("SELECT ... FROM orders WHERE user_id=?", userID) ``` Атака не требует знания внутренней схемы — атакующий перебирает идентификаторы (особенно эффективно при последовательных численных ID, см. предыдущие IDOR-лабы) и собирает данные всех пользователей системы. В современных API «чистый» BOLA дополнительно усиливается тем, что service-mesh аутентификация (JWT, mTLS) часто проверяется на edge proxy и считается достаточной — внутренний сервис может вообще не делать ownership-checks, считая, что «к нам приходят только аутентифицированные запросы». ## Точка входа атаки | Параметр | Значение | |----------|----------| | Учётные данные обычного пользователя | `demo` / `demo` | | Учётные данные администратора | `admin` / `LabAdmin2024!` (для понимания структуры данных, не нужны для атаки) | | API-эндпоинт | `GET /api/users/{id}/orders` | | Цель | извлечь конфиденциальную метку из служебного заказа администратора |