IDOR: Перебор заказов по последовательным ID

# IDOR: предсказуемые идентификаторы заказов ## Сценарий Вы зарегистрированы в интернет-магазине как пользователь **demo**. В магазине есть личный кабинет с историей заказов и эндпоинт просмотра деталей конкретного заказа по идентификатору в URL. Команда уверена, что эндпоинт защищён аутентификацией и пользователь видит только свои заказы. По данным внутреннего расследования, в системе есть служебный заказ с конфиденциальной меткой, размещённый администратором — её требуется извлечь в рамках аудита. ## Цель 1. Залогиньтесь как `demo` и изучите URL-схему доступа к собственным заказам через профиль. 2. Используя свойства идентификаторов заказов, обратитесь к ресурсу, не принадлежащему текущему пользователю. 3. Найдите флаг в данных служебного заказа. ## Теория IDOR (Insecure Direct Object Reference) усиливается, когда приложение использует **предсказуемые идентификаторы** ресурсов — последовательные целые числа, монотонные счётчики, инкрементируемые номера. Даже без знания внутренней схемы атакующий может перебрать диапазон возможных значений и найти ресурсы других пользователей. В отличие от непредсказуемых идентификаторов (UUIDv4, криптографически случайные токены), последовательные ID создают атаку с пространством перебора `O(N)` — линейного, тривиального для автоматизации. **Уязвимый паттерн:** ```go // Запрос фильтрует только по ID ресурса, без проверки принадлежности row := db.QueryRow("SELECT ... FROM orders WHERE id=?", id) ``` Защита аутентификацией (наличие сессии) не решает проблему: атакующий может зарегистрировать собственный аккаунт, получить валидную сессию и затем перебирать чужие ресурсы. Дополнительный фактор — служебные/первые записи в системе обычно имеют самые ранние идентификаторы (1, 2, ...), что делает их «низковисящими плодами» для атаки. ## Точка входа атаки | Параметр | Значение | |----------|----------| | Учётные данные | `demo` / `demo` | | Просмотр заказа | `GET /order/{id}` | | Профиль | `GET /profile` |