Обычный IDOR срабатывает сразу: ты меняешь условный
user_id=1 на user_id=2 в запросе — и сервер мгновенно отдаёт данные второго юзера. Second-order IDOR работает иначе — с «задержкой». Как это выглядит ⤵️
Ты подсовываешь тот же айдишник жертвы в одном месте,
а доступ к данным происходит позже — через другой эндпоинт или фоновую джобу.
➡️ В момент инъекции всё выглядит легитимно
➡️ Эксплуатация происходит совсем в другом контексте
Атака — это всегда два шага:
1⃣ Seed (сохранение): инжектишь ID жертвы в безобидное поле: профиль, настройки, связанный ресурс. Сервер проверяет сессию и спокойно сохраняет данные.
2⃣ Trigger (исполнение): позже происходит асинхронное действие. Система берёт сохранённый ID из базы, слепо ему доверяет и выполняет операцию.
Почему такие баги часто дают высокий импакт:
⚫️ Сканеры почти не находят такие баги — здесь нужно понимать состояние приложения, бизнес-логику и отложенное выполнение
⚫️ Разработчики часто защищают только публичные API
⚫️ Внутренние джобы (генерация PDF, отправка писем и т.д.) считаются «безопасными»
⚫️ Проверки прав доступа на втором этапе просто отсутствуют
Где искать ⏳
Ищи функционал приложения с асинхронной обработкой:
⚫️ Экспорты и отчёты: меняй ID аккаунта → запрашивай CSV/PDF → через время получай данные жертвы
⚫️ Webhooks и интеграции: подменяй ID workspace → при синхронизации (Slack, Jira) получай чужие данные
⚫️ Автоматические саппорт-боты: вставляй ID заказа жертвы → бот подтягивает детали из базы и показывает чужие данные
Что нужно ❓
1⃣ Две учетки: атакующий (User A) и жертва (User B)
2⃣ Терпение: ввел данные → подождал выполнение задачи → проверил результат (почта, webhook и т.д.) → повторил