Кратко: IDOR (Insecure Direct Object Reference) — уязвимость, позволяющая получить доступ к чужим данным простым изменением идентификатора в URL или теле запроса. Меняете id=123 на id=124 — и смотрите чужой счёт, документ или переписку.

▫️ Как это работает Вы открываете свой профиль: bank.com/statement?user_id=100500. Бэкенд берёт этот user_id и без проверок отдаёт данные. Меняете 100500 на 100501 — получаете выписку соседа. Приложение доверяет идентификатору, который может подделать пользователь, и не проверяет права доступа.

▫️ Реальные примеры · Онлайн-кинотеатр: /profile?user_id=12345 → меняете на 12346 → видите чужой email и историю платежей. · Файловое хранилище: /download/file_id=67890 → меняете на 67891 → скачиваете чужой контракт. · Чат-бот: dialog/456 → меняете на 457 → читаете чужую переписку.

▫️ Последствия · Утечка паспортов, телефонов, платежей · Сброс чужого пароля · Подмена или удаление чужих файлов · Доступ к коммерческой тайне

▫️ Где искать IDOR Идентификаторы могут быть в GET-параметрах (?id=123), в пути (/user/123), в POST-теле (JSON), в заголовках (X-User-Id), в скрытых полях форм. Базовые техники: · Изменить число на соседнее (12345 → 12346) · Попробовать отрицательные значения (-12345) · Попробовать очень большое число (999999999) · Если GUID — соседний (id=1e0a4d00-… → 1e0a4d01-…) · Если base64 — декодировать, изменить, закодировать обратно

Пример ID в URL: GET /api/v1/invoice/12345 Host: example.com

Пример ID в JSON: POST /api/get_user_data Host: example.com {“user_id”: 12345}

▫️ Как защищаться Проверка прав на бэкенде — единственный надёжный способ. # Плохо (уязвимо) doc = Document.objects.get(id=request.GET[‘id’]) # Хорошо (безопасно) user = get_current_user() doc = Document.objects.get(id=request.GET[‘id’], owner=user)

Дополнительные меры: · Использовать UUID вместо числовых ID · Не показывать системные ID пользователю · Использовать внешние ID, для ссылок — сессии

▫️ Уровни опасности · Level 1: Меняете ID — сразу видите чужие данные. · Level 2 (горизонтальный): Доступ к объекту другого пользователя с тем же уровнем прав. · Level 3 (вертикальный): Доступ к объектам, требующим прав администратора.

▫️ Реальные баги в гигантах · Facebook (2019): В API можно было менять ID страницы и получать чужие данные. · GitHub (2020): GraphQL-запрос с изменённым ID участника менял настройки чужого репозитория.

▫️ Нюанс 2026 года Современные бэкенды используют зашифрованные токены вместо прямых ID, но если приложение само расшифровывает токен и доверяет ему без проверки прав — IDOR остаётся. GraphQL и REST API всё ещё уязвимы.

▫️ Чек-лист для тестирования 1. Найдите в запросе цифру, GUID или строку-идентификатор 2. Измените на соседнюю 3. Если получили чужие данные → IDOR 4. Если нет → попробуйте отрицательные значения, большие числа, другой формат (десятичный → шестнадцатеричный) 5. Создайте два аккаунта и проверяйте ту же атаку от лица другого пользователя Главное правило: IDOR — это не про взлом шифрования, а про забытую программистом проверку: «А имеет ли текущий пользователь право на это?»

#idor #веббезопасность #инфобез #пентест #brokenaccesscontrol #owasp