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

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