99% того, что я делаю — использование ошибок, которых можно избежать. Сегодня я расскажу про IDOR — одну из самых распространенных и простых в использовании веб-уязвимостей. С ее помощью можно посмотреть чужие фотографии в социальной сети или получить скидку в интернет-магазине, а можно заработать тысячи долларов баг-баунти.
На примерах из практики я покажу, как хакеры находят и эксплуатируют ошибки бизнес-логики в приложениях и дам практические советы по их устранению на этапе разработки.
IDOR — что это такое и с чем его едят
Начну с основ. Веб-приложение манипулирует некими сущностями. Например, на сайте интернет-магазина — это товары, пользователи, корзины, промокоды и т. д. Каждый экземпляр такой сущности рассматривается как отдельный объект, которому присваивается собственный идентификатор. ID 483202, pid 6260 — каждое приложение заполнено такими значениями.
Предполагается, что пользователь манипулирует объектами через интерфейс, в рамках логики работы приложения. При этом приложение показывает только те объекты, с которыми разрешено взаимодействовать пользователю. Однако внимательный пользователь заметит идентификаторы этих объектов, например, в адресной строке. А хакер обязательно попробует их изменить. Так можно получить доступ к другим объектам напрямую, минуя логику приложения и вопреки запретам.
Эта уязвимость и называется IDOR (Insecure direct object references) — небезопасная прямая ссылка на объект. Она возникает при одновременном соблюдении трех условий:
пользователь может найти прямую ссылку на внутренний объект или операцию;
пользователь может менять параметры в этой ссылке;
приложение предоставляет доступ к внутреннему объекту или операции без проверки прав пользователя.
Возьмем, в качестве примера ссылку на эту статью: https://habr.com/ru/company/bastion/blog/686464/. В нее включен идентификатор 686464, и его можно заменить на другое число. Выполняется два условия из трех.
Перебирая цифры рано или поздно вы угадаете ссылку на чужой черновик, например, этот: https://habr.com/ru/company/bastion/blog/686516/. Если такая ссылка откроется — поздравляю, вы нашли IDOR. На Хабре этого не происходит, так как не выполняется третье условие, необходимое для появления IDOR. На Хабре работает корректный механизм авторизации.
Изменение URL — классический пример IDOR, но уязвимые идентификаторы попадаются не только в адресной строке. Если взять статистику по отчетам об ошибках на HackerOne, окажется, что чаще всего IDOR встречаются в REST API, GET-параметрах и теле POST-запросов.
Риски и последствия IDOR
Опасность уязвимостей этого типа сильно зависит от того, какие данные и какие операции с ними доступны злоумышленнику. Условно IDOR разделяют на четыре вида (на практике они часто пересекаются):
1. Получение несанкционированного доступа к данным
Иногда прямые ссылки на объекты дают доступ к содержимому баз данных: отдельным полям или внутренним идентификаторам, которые позволяют подготовить SQL-инъекции.
Недавно я встретил подобную ошибку на портале одной новой социальной сети. При переходе к эндпоинту GET /feed/gallery/uuid, сервер возвращал персональные данные пользователей: номер телефона и адрес электронной почты.
2. Выполнение несанкционированных операций
Изменяя идентификатор пользователя или ключи API, можно получить доступ к платным функциям приложений и даже выполнять команды от имени администратора.
В этом примере без авторизации доступен метод DELETE /accounts/{uuid}, позволяющий удалить произвольный аккаунт пользователя при указании валидного UUID. Как правило, у этого идентификатора высокая энтропия и подобрать его перебором непросто, но если такой IDOR сочетается с другими уязвимостями, он очень опасен.
В данном случае на исследуемом ресурсе был возможен неавторизованный доступ к ряду эндпоинтов, содержащих параметр page_size. Он отвечает за вывод страниц пользователей. Правильная модификация запроса позволяла массово и без авторизации выгружать информацию о пользователя, в том числе UUID, необходимый для эксплуатации IDOR.
3. Управление объектами приложения
Некоторые IDOR дают возможность редактировать данные внутри приложения. В результате этой уязвимости злоумышленник может изменить переменные сеанса, например, повысить привилегии или получить доступ к ограниченным функциям.
Это скриншот с пентеста одного из сервисов доставки. Оказалось, что из приложения доступен API, предназначенный только для сотрудников компании. IDOR давал клиенту полную функциональность сотрудника, например, просмотр состояния транспортных средств и возможность создания новых аккаунтов.
4. Прямой доступ к файлам
Этот тип IDOR позволяет манипулировать ресурсами файловой системы: загружать и редактировать файлы, бесплатно скачивать платный контент.
Однажды такой неавторизованный доступ нашелся на сайте онлайн-школы — там он позволял добраться до учебных планов и уроков. Чтобы скачать контент, достаточно было обратиться по маршрутам: /api/0/curriculum/lessons/ и /api/0/files/<id>/content.
Собери их всех! Или как охотятся на IDOR
Чтобы найти IDOR хакеры перехватывают запросы к API и подставляют в них новые идентификаторы при помощи веб-прокси, например, BURP Suite. Иногда они полагаются на везение и подбирают идентификаторы перебором, но существуют и более изящные методики, например, обмен метками сеансов.
Чтобы найти IDOR:
Необходимо создать двух пользователей и сохранить их метки сеансов.
Это может быть токен или идентификатор сеанса — любая строка в API, которую приложение использует для идентификации пользователя, вошедшего в систему.
Следующий шаг — войти как первый пользователь, выполнить ряд действий в приложении и записать их при помощи прокси.
Теперь следует просмотреть трафик и найти вызов API, в котором идентификатор объекта передается на сервер.
Нужно повторить вызов, перехватить, отредактировать и отправить на сервер с меткой сессии второго пользователя.
Если в результате сервер ответил ошибкой авторизации, скорее всего, IDOR отсутствует. Но если бэкенд возвращает данные об объекте, необходимо сравнить ответы на обычный и на искаженный запрос. Если они одинаковы — приложение уязвимо.
В BURP Suite такие проверки частично автоматизируются при помощи плагинов: AuthMatrix или Autorize. Они избавляют от рутины и позволяют фильтровать результаты (например, в Autorize при помощи флага Scope items only и регулярных выражений). Однако, эти плагины — лишь удобный инструмент, главное в таком баг-хантинге опыт и понимание того, как работает приложение.
Необходимо выяснить, какие роли и группы предусмотрены в приложении и то, как они взаимодействуют.
Чем отличаются менеджер, водитель и администратор и какие функции доступны каждому из них?
Желательно выстроить карту взаимосвязей между ресурсами.
Как взаимосвязаны заказы, чеки и товары? Может ли один пользователь делать заказы на чужое имя?
Стоит изучить особенности REST API.
Этот набор правил вынуждает разработчиков действовать шаблонно, и это можно использовать против них. Допустим, вы нашли эндпойт, который предоставляет ресурс REST.
GET /api/chats/<chat_id>/message/<message_id>
Попробуйте заменить GET другим HTTP-методом. Если это ничего не даст, добавьте HTTP-заголовок Content-length или измените тип контента.
Почему IDOR так много
В последние несколько лет IDOR встречаются повсюду, по несколько штук в одном, даже небольшом приложении. Мне кажется, для этого есть объективные причины:
От клиентов отправляется больше идентификаторов.
Раньше сервер мог напрямую отслеживать действия пользователя, но в современных приложениях клиенты передают все больше данных по запросу через API.
Старые приемы защиты от IDOR больше не используются.
Разработчики часто заменяли реальные ID объектов на временные, актуальные только для этого пользователя и одного сеанса. Для этого на бэкенде создавалась отдельная таблица, где каждому объекту соответствовал временный идентификатор. Эта практика потеряла актуальность, потому что плохо согласуется с принципами REST API. К тому же этот интерфейс больше не предусматривает запись состояния клиента (Stateless).
Ролевые модели становятся сложнее.
Даже если в приложение встроен надежный механизм проверки прав пользователя, он нуждается в правильной настройке. Разработчику может быть сложно понять, доступен ли пользователю X файл Y. Особенно если пользователь — региональный менеджер, который принадлежит к одному из десятка подтипов внутри ролевой модели. Еще настройку механизма авторизации усложняет недопонимание между разработчиками и конечными пользователями системы. В результате пользователям часто оставляют избыточные возможности просто чтобы случайно не отобрать нужные функции.
Защититься и устранить IDOR — не одно и то же
В сети много рекомендаций по борьбе с IDOR, но многие из них вызывают путаницу. Авторы таких советов часто перечисляют методы снижения риска от уязвимости и выдают их за способы ее устранения. Я имею в виду такие рекомендации, как:
Использование случайных идентификаторов.
В большинстве языков программирования предусмотрены криптографические функции, которые генерируют новое значение с высокой энтропией. Если использовать их для создания идентификаторов объектов, злоумышленникам будет сложнее подобрать новый ID для эксплуатации IDOR.
Использование хэшей.
Еще один способ затруднить подмену идентификаторов. Он приводится, например, в памятке OWASP. Тем не менее хэши можно подобрать. Кстати, Base64, который иногда используют в таком качестве, хотя это не хэш-функция, декодируется совсем без проблем.
Использование JWT JSON Web Tokens.
Такие токены защищают от некоторых манипуляций с идентификаторами пользователей, но не решают проблемы с идентификаторами объектов.
Фильтрация вводимых пользователем данных до того, как они будут обработаны приложением, проверка диапазонов, длин и форматов.
Пожалуй, самая полезная из перечисленных рекомендаций, главное — правильно настроить фильтр.
Тем не менее ни один из этих методов не решает проблему управления доступом, не устраняет IDOR. Они лишь снижают остроту проблемы. Кстати, от этого типа уязвимостей не спасают и внешние защитные системы, вроде брандмауэров веб-приложений.
Дело в том, что IDOR тесно связаны с бизнес-логикой приложения. Единственный способ надежно устранить IDOR — тщательно настроить управление сеансами и проверку доступа пользователей на уровне объектов. Таким образом, даже если злодей найдет и изменит внутреннюю ссылку, он все равно не получит несанкционированный доступ.
Конечно, все приложения разные. Не существует универсального способа реализовать контроль доступа, но, в любом случае, этот механизм должен быть хорошо спроектирован и протестирован по определенным шаблонам.
Стоит проверить сценарий, в котором пользователь с низкими привилегиями пытается выполнить действия, предназначенные только для пользователей с высокими привилегиями. Схема проверки похожа на ту, что используется при взломе.
Авторизоваться в приложении под учетной записью с наивысшими привилегиями.
Выполнить ряд действий в приложении и записать запросы к API при помощи прокси.
Аутентифицироваться в приложении под учеткой с более низким уровнем привилегий, чтобы сгенерировать токен для заголовка авторизации.
Воспроизвести записанные API-запросы с измененным заголовком, используя токен пользователя с низкими привилегиями.
Следующий шаг — разработка и проведение модульных тестов для покрытия пограничных случаев — ситуаций, когда:
Пользователь не аутентифицирован, например, заголовок авторизации отсутствует или недействителен.
Пользователь аутентифицирован, но не авторизован на ресурсе.
Наконец, необходимо полное интеграционное тестирование с учетом пограничных случаев. При проверке API желательно протестировать каждый метод для каждого эндпойта. К сожалению, серебряной пули от IDOR не существует — только тестирование, тестирование и еще раз тестирование.
