IDOR: Доступ к чужому счету

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