Кибербезопасность и информационная безопасность

IDOR и BOLA: Проверка разрешений на уровне объектов

6 мин чтенияОпубликовано: 5 августа 2026 г.

Профессиональное визуальное представление темы IDOR BOLA в области Web и API PT

Быстрый ответ

IDOR BOLA тестируется только в лаборатории или в авторизованной системе. Проверяются Request/Response, поведение сервера, роли, состояние и влияние, используя минимальные тесты, не повреждающие данные.

Тестирование безопасности Web и API должно проверять границы доверия, разрешений, ввода, состояния и бизнес-логики. Каждый тест в статье предназначен для лаборатории, CTF или системы, для которой было дано явное разрешение. Данная статья посвящена IDOR BOLA и предназначена для студентов Web/API PT. Цель состоит в том, чтобы предоставить метод работы, который можно применять на практике, на профессиональном собеседовании и в рабочей среде, не ограничиваясь словарным определением.

Основная проблема заключается в том, что данные почти всегда неполные. Матрица ролей, идентификаторы объектов, авторизация на стороне сервера могут указывать направление, но их значение зависит от времени, актива, пользователя и ожидаемой активности. Поэтому мы строим тест вокруг исследовательского вопроса, необходимых доказательств и четкого критерия завершения.

Практический сценарий в статье: сценарий двух учетных записей и одного ресурса в лаборатории. Все примеры — это лабораторные данные или описание процессов. При работе с Penetration Testing, Web или Cloud, необходимо работать только с явным разрешением, определенным Scope и возможностью остановить тестирование.

Что такое IDOR/BOLA

Тема 'Что такое IDOR/BOLA' является центральной частью работы по IDOR BOLA. Рекомендуется разбить ее на три вопроса: что является вводом, какое решение необходимо принять, и какое доказательство достаточно, чтобы его обосновать. Эти вопросы предотвращают автоматическое использование инструмента без понимания цели.

На практике записывайте матрицу ролей, идентификаторы объектов, авторизацию на стороне сервера, горизонтальный/вертикальный доступ, различия в ответах, сравнивайте с ожидаемым поведением и определяйте как минимум один Pivot. Результат должен быть проверяемым другим аналитиком, включая ограничения и дальнейшие шаги.

Сопоставление объектов и владельцев

Тема 'Сопоставление объектов и владельцев' является центральной частью работы по IDOR BOLA. Рекомендуется разбить ее на три вопроса: что является вводом, какое решение необходимо принять, и какое доказательство достаточно, чтобы его обосновать. Эти вопросы предотвращают автоматическое использование инструмента без понимания цели.

Тестирование между пользователями

Профессиональное тестирование IDOR BOLA начинается с условий успеха и условий отказа. Определяются положительный Case, отрицательный Case, граничный Case и аналогичная легитимная активность. Таким образом можно выявить как False Negative, так и False Positive.

В авторизованной среде используются минимальные действия, которые доказывают утверждение, не причиняя вреда. Сохраняются Input, Output, время и версия, а после исправления выполняется Retest по тому же сценарию и проверяется Regression на близлежащих функциях.

Влияние и доказательства

Тема 'Влияние и доказательства' является центральной частью работы по IDOR BOLA. Рекомендуется разбить ее на три вопроса: что является вводом, какое решение необходимо принять, и какое доказательство достаточно, чтобы его обосновать. Эти вопросы предотвращают автоматическое использование инструмента без понимания цели.

Исправление и отрицательные тесты

Уникальные точки тестирования

В этом разделе рекомендуется заранее создать целенаправленную карту доказательств. Основные точки тестирования: матрица ролей, идентификаторы объектов, авторизация на стороне сервера, горизонтальный/вертикальный доступ, различия в ответах, журналы аудита. Список не является автоматическим чек-листом; каждый элемент выбран потому, что он может связывать сущность, действие и время или объяснять легитимное поведение.

Матрица ролей: Определите ожидаемое значение, что будет считаться аномалией, и какой дополнительный источник подтвердит находку.
Идентификаторы объектов: Определите ожидаемое значение, что будет считаться аномалией, и какой дополнительный источник подтвердит находку.
Авторизация на стороне сервера: Определите ожидаемое значение, что будет считаться аномалией, и какой дополнительный источник подтвердит находку.
Горизонтальный/вертикальный доступ: Определите ожидаемое значение, что будет считаться аномалией, и какой дополнительный источник подтвердит находку.
Различия в ответах: Определите ожидаемое значение, что будет считаться аномалией, и какой дополнительный источник подтвердит находку.
Журналы аудита: Определите ожидаемое значение, что будет считаться аномалией, и какой дополнительный источник подтвердит находку.

Если одна из точек недоступна, необходимо задокументировать пробел и выбрать альтернативу. Например, если идентификатор процесса нестабилен, можно использовать время, Host, User и Parent; если Payload зашифрован, используются Metadata, объем, частота и контекст TLS/DNS.

Практический сценарий

Выбранный сценарий – это сценарий двух учетных записей и одного ресурса в лаборатории. Цель упражнения – не доказать способность к атаке, а отработать сбор, сравнение и документирование безопасным способом. Перед началом работы определяются фиктивные данные, временное окно и ожидаемый результат.

По окончании упражнения необходимо представить результат, который может быть проверен другим аналитиком или тестировщиком: скриншот или экспорт доказательства, краткий Timeline, первоначальное предположение, подтверждающее доказательство, ограничение и рекомендация. Если доказательств недостаточно, правильный вывод заключается в том, что сценарий не был доказан.

Этап	Что выполняется	Результат
Подготовка	Определите Scope, время и цель. Запишите, какие поля или доказательства из матрицы ролей, идентификаторов объектов, авторизации на стороне сервера должны появиться.	Краткий план тестирования
Создание данных	Выполните безопасное и фиктивное действие, связанное с IDOR BOLA, без реальной информации или влияния на производственную систему.	Контролируемое событие/запрос/поток
Сбор	Соберите необработанное доказательство и контекст из дополнительного источника. Убедитесь в правильности Time zone, идентификаторов и целостности.	Два связанных доказательства
Анализ	Напишите, что доказывает каждое доказательство, что не доказывает, и какое легитимное объяснение возможно.	Промежуточный вывод
Завершение	Выберите завершение, эскалацию, обнаружение или настройку; добавьте рекомендацию и Retest.	Задокументированный результат

Практический чек-лист

Проверьте и задокументируйте: Роль и сессию.
Проверьте и задокументируйте: Endpoint и метод.
Проверьте и задокументируйте: Request/Response.
Проверьте и задокументируйте: Идентификатор объекта.
Проверьте и задокументируйте: Эффект на стороне сервера.
Проверьте и задокументируйте: Ожидаемый контроль и исправление.
Укажите Time zone, версию инструмента и время сбора.
Сохраните необработанные данные до фильтрации или изменения.
Напишите, что доказывает находка и что еще неизвестно.
Определите владельца и дальнейшее действие с датой.

Распространенные ошибки

Проверка только Status code.
Полагаться на изменение Client-side.
Использование опасного Payload.
Не проверять разные роли.
Игнорировать бизнес-логику.
Сообщать без чистых Request/Response.

Заключение и призыв к действию

IDOR и BOLA: проверка разрешений на уровне объектов — это тема, которая связывает технические знания с рабочей дисциплиной. Начните с вопроса, собирайте только релевантные доказательства, сохраняйте контекст и время, и выбирайте действие, которое можно обосновать и перепроверить.

В курсе Cybersecurity & AI от HPI эти принципы отрабатываются с использованием систем, логов и лабораторий. Естественным продолжением является переход к связанным статьям, выполнение лабораторного упражнения и сохранение результата как части профессионального портфолио.

Вопросы и ответы

Можно ли тестировать IDOR BOLA на публичном сайте?

Нет, без явного разрешения владельца системы. Даже, казалось бы, легкая проверка может изменить данные, запустить механизмы защиты или быть расценена как несанкционированный доступ.

Что делать, если часть данных отсутствует?

Задокументируйте отсутствие, проверьте альтернативный источник и снизьте уровень уверенности. Не следует заполнять поля предположениями или представлять Unknown как нормальное.

Как долго нужно хранить доказательства?

Время зависит от политики, регулирования, стоимости и типа события. Важно заранее определить Retention, Legal hold и возможность экспортировать доказательства в проверяемом формате.

Как практиковаться, не рискуя реальной системой?

Используйте виртуальные машины, фиктивные данные, CTF или выделенную лабораторию. При авторизованном тестировании определите Scope, Stop conditions и резервное копирование перед началом работы.