IDOR: предсказание UUID v1 по таймстампу

# IDOR: предсказуемые идентификаторы заказов ## Сценарий Экспресс-магазин **SwiftCart** обещает доставку «за сутки» и гордится аккуратной историей заказов: каждая позиция в профиле покупателя открывается по ссылке с длинным UUID. Владелец магазина считает такие ссылки «непросматриваемыми» — идентификатор выглядит случайным. Служба поддержки получила жалобу от клиента, увидевшего в приложении чужой заказ. Разберитесь, настолько ли непредсказуемы идентификаторы заказов и кто может читать чужие покупки, — среди заказов администрации есть конфиденциальный. ## Цель 1. Войдите покупателем и откройте в профиле детали своих заказов; соберите несколько идентификаторов из ссылок. 2. Сравните свои идентификаторы между собой: какие части совпадают, какие меняются, и что это говорит о способе генерации. 3. Восстановите идентификатор чужого заказа и откройте его страницу. 4. Найдите чужой заказ с товаром «CTF Flag» и получите флаг. ## Теория UUID бывает разным: одни версии строятся из случайных битов, другие — из метки времени и параметров машины. Если идентификаторы генерируются по времени, то соседние объекты, созданные одним процессом подряд, отличаются лишь полем времени, а остальные части у них общие. Зная один свой идентификатор, атакующий восстанавливает соседние перебором узкого диапазона. **Уязвимый паттерн:** ```js const order = db.prepare( 'SELECT id, uuid, user_id, product_name FROM orders WHERE uuid=?' ).get(req.params.uuid); ``` Запрос ищет заказ только по идентификатору из адреса и не сверяет владельца с текущей сессией: предсказуемость идентификаторов и отсутствие проверки доступа усиливают друг друга. ## Точка входа атаки `GET /order/<uuid>` — страница деталей заказа; свои заказы перечислены в профиле (`GET /profile`). * **Пользователь:** `demo` / `demo`