Уязвимости IDOR (незащищённая прямая ссылка на объект) являются одними из наиболее часто встречающихся уязвимостей безопасности в современных веб-приложениях и API. Неудивительно, что они часто рекомендуются начинающим охотникам за уязвимостями, так как их легко обнаружить и эксплуатировать, и по своей природе они являются уязвимостями высокой степени опасности.
В этой статье рассматривается способ, как выявить уязвимости IDOR и как их можно эксплуатировать. Также будут рассмотрены более сложные случаи. Начнём с определения уязвимостей IDOR.
Что такое уязвимости IDOR?
Уязвимости IDOR (insecure direct object reference) возникают, когда веб-приложение или API используют вводимые пользователем данные для непосредственной ссылки на объект данных. Объект данных может быть чем угодно: от конфиденциальных полей, хранящихся в базе данных, до файлов, находящихся в хранилище.
Уязвимости IDOR обусловлены отсутствием проверки доступа. Иными словами, веб-приложение или API не проверяют, является ли запрашивающий пользователь законным владельцем объекта данных. Из-за этого уязвимый компонент возвращает объект данных, даже если пользователь не имеет на это права.
В зависимости от уязвимого компонента в IDOR, уязвимости могут привести к раскрытию конфиденциальных данных или внесению нежелательных изменений, таких как модификация или удаление полей в базе данных.
Идентификация уязвимостей IDOR
Для того чтобы компонент, веб-приложение или API были уязвимы к атакам IDOR, необходимо найти способ прямой ссылки на объект. Это часто осуществляется с помощью уникального идентификатора. Хотя в качестве лучшей практики разработчикам рекомендуется всегда использовать непредсказуемые идентификаторы, всё ещё встречаются цели, которые не соблюдают эти правила. Вместо этого они используют предсказуемые идентификаторы, например, числовые.
Компонент должен выполнять действие, изменяющее состояние, или извлекать данные, которые в противном случае не были бы доступны публично. Например, возможность просмотра публичных блогов или комментариев не считается уязвимостью IDOR.
Новички-охотники за ошибками часто слышат, что уязвимости IDOR легко обнаружить. Однако, проведя некоторое время в поиске таких уязвимостей, можно обнаружить обратное.
Ключевой момент заключается в улучшении методов обнаружения контента и тестировании функций, которые ещё не были протестированы другими. Например, вместо тестирования функции отправки сообщений, следует протестировать функцию автосохранения или компонент, который помечает сообщение как черновик.
Эксплуатация базовых IDOR-уязвимостей
Основные уязвимости IDOR заключаются в том, что мы можем легко изменить предсказуемый идентификатор, такой как числовое целое значение, на другой числовой идентификатор, как показано в примере ниже:
В этом случае конечная точка API позволила бы изменить адрес электронной почты нашей второй тестовой учетной записи. Иногда это может быть так же просто, как смена идентификаторов, но может быть и сложнее.
Давайте рассмотрим некоторые более сложные случаи…
Эксплуатация уязвимостей IDOR через загрязнение параметров
При тестировании необходимо учитывать все возможные методы эксплуатации. Загрязнение параметров также должно быть протестировано. зависимости от используемой технологии, зможны следующие сценарии:
оба значения параметров будут объединены,
обрабатывается только первое значение,
обрабатывается только последнее значение.
Загрязнение параметров - известный метод, помогающий обойти определенные проверки, такие как проверки авторизации.
Использование IDOR с помощью JSON globbing
Аналогично, как и выше, нам нужно опробовать несколько различных методов, чтобы попытаться обойти любые проверки контроля доступа. Если ваша цель принимает тело JSON, мы можем поиграть с различными полями и посмотреть, как конечная точка обрабатывает наши входные данные.
Опять же, в зависимости от того, как обрабатываются наши входные данные, мы можем добиться нежелательного поведению, заменив наш идентификатор на:
массив идентификаторов: [1234, 1235]
логическое значение: true / false (будьте осторожны при тестировании)
подстановочный знак, такой как звездочка (*) или знак процента (%) (опять же, будьте осторожны при тестировании)
большое целое значение путем добавления нулей перед нашим идентификатором: 00001235
отрицательный идентификатор: -1
десятичное число: 1235.0
строковое значение с добавленным разделителем: “1234,1235”
Эксплуатация IDOR через метод запроса
Иногда при простом изменении метода запроса наш запрос обрабатывается по-другому. Если проверки контроля доступа отсутствуют, это может позволить нам выполнять действия по изменению состояния или извлекать конфиденциальные данные от имени другого пользователя.
Давайте рассмотрим небольшой пример, который поможет нам лучше понять этот тип IDOR:
Как вы можете видеть во фрагменте кода выше, определены 2 конечные точки API. Включая новую, в которой отсутствуют проверки контроля доступа, и доступ к ней возможен только при изменении нашего метода запроса на POST . Это позволило бы нам извлекать конфиденциальные данные любого пользователя без получения на это разрешения.
Чтобы успешно использовать этот случай, мы могли бы просто отправить POST-запрос, как показано ниже:
Эксплуатация IDOR через тип содержимого
Точно так же, как и в предыдущем случае, возможно, что запрос обрабатывается по-другому базовым фреймворком или библиотекой и позволяет снова выполнять действия по изменению состояния или извлекать конфиденциальные данные, просто установив заголовок другого типа содержимого.
Эксплуатация устаревших версий API
Цели, предоставляющие свой общедоступный API, часто используют систему управления версиями. Каждая новая версия часто поставляется с новыми возможностями, а также исправлениями безопасности. Если более старые версии все еще доступны и в них отсутствуют проверки контроля доступа, они по-прежнему могут позволять, например, извлекать конфиденциальные данные из API, даже если последняя версия уже решила эту проблему безопасности.
Эксплуатация IDOR с использованием статических ключевых слов
Иногда разработчики используют ключевые слова вроде "current" или "me" для обозначения текущего пользователя. Можно попробовать заменить такие ключевые слова на числовой идентификатор и снова протестировать уязвимость IDOR.
Эксплуатация IDOR с использованием непредсказуемых идентификаторов
Все больше разработчиков начинают использовать UUID или другие непредсказуемые хэши просто потому, что их нелегко предсказать и они не подвержены атакам с применением грубой силы. Однако все еще остается надежда, поскольку есть несколько способов, которыми мы можем использовать в наших интересах для перечисления этих идентификаторов.
Один из способов - запросить другую конечную точку для возврата любых ссылок с идентификаторами, которые мы ищем.
И есть несколько других способов найти ссылки на IDs, например:
общедоступные профили (например, фотографии профиля)
формы входа / регистрации и сброса пароля
ссылки для совместного использования в приложении
формы отказа от подписки по электронной почте
сообщения в приложении
Wayback Machine
поисковые системы (например, Google и Bing)
Эксплуатация вторичных IDOR-уязвимостей
IDOR второго порядка аналогичны уязвимостям IDOR, но единственное отличие здесь заключается в том, что уязвимый компонент использует входные данные для косвенной ссылки на объект данных. ID сначала сохраняется, а затем извлекается для последующей ссылки на объект.
Уязвимости IDOR второго порядка сложнее и их сложнее обнаружить. Примером может служить функция экспорта данных по расписанию. Сначала создается расписание, по которому идентификатор пользователя сохраняется во внешней службе планирования. После запуска расписания оно позже извлекает ваш идентификатор пользователя из метаданных для создания экспорта. Этот второй шаг часто не проходит никаких дополнительных проверок контроля доступа. Мы можем воспользоваться этим уязвимым поведением и вместо этого попытаться сгенерировать экспорт данных нашей второй тестовой учетной записи.
Существует несколько способов сделать это, как мы упоминали ранее в этой статье. На следующем рисунке вы можете увидеть простой пример уязвимости IDOR второго порядка:
Заключение
Уязвимости IDOR могут быть легко обнаружены при наличии опыта. Они, как правило, имеют высокую степень опасности и часто сопровождаются большими вознаграждениями в системах баг-баунти.
Теперь, когда вы узнали о сложных уязвимостях IDOR, самое время применить свои знания на практике!
