Уязвимость IDOR: почему возникает и как защититься

IDOR (Insecure Direct Object Reference) — уязвимость, которая возникает, когда система позволяет получать неавторизованный доступ к данным через их идентификатор (ID) без проверки прав пользователя.

Представьте, что вы заходите на сайт интернет-магазина или онлайн-банка. После входа в личный кабинет адрес вашей страницы выглядит так:

На первый взгляд, все в порядке: «123» — уникальный идентификатор, который система использует, чтобы показать именно вашу страницу.

Но что произойдет, если в адресной строке вручную изменить «123» на «124»? Если сервер не проверит, есть ли у вас доступ к этому ID, вы попадете в профиль другого пользователя. Именно так работает уязвимость IDOR — она позволяет добираться до данных, которые вам не принадлежат.

IDOR считается одной из самых «простых» уязвимостей для эксплуатации.

Злоумышленнику не нужны сложные инструменты и технические знания — достаточно понять, как работает система, и обнаружить точку, где передается идентификатор. После этого начинается процесс подмены ID до тех пор, пока злоумышленник не получит доступ к чувствительным данным или функциям.

Вот как это обычно происходит:

Шаг 1. Исследование системы

Злоумышленник изучает, как работает веб-приложение, и анализирует запросы, которые оно отправляет. Для этого он использует:

• Инструменты разработчика в браузере DevTools. С их помощью можно инспектировать запросы, которые отправляются на сервер, и искать в них параметры с идентификаторами, например, user_id, order_id, file_id.
• Инструменты перехвата трафика Burp Suite или OWASP ZAP. Эти программы позволяют перехватывать запросы между браузером и сервером, чтобы изучать и подменять данные.

На этом этапе злоумышленник ищет где передаются ID: в URL, в теле запроса или в заголовках. А так же какие данные возвращает сервер: HTML-страницы, JSON с данными, файлы или другие ресурсы.

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

Так, он делает вывод, что «12345» — ID профиля, который система использует для отображения данных.

Шаг 2. Тестирование подмены ID

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

• вернет ли система другие данные при подмене ID;
• возникнет ли ошибка доступа, если использовать чужой ID.

Например, вместо «profile/12 345» он меняет ID на «profile/12 346» и отправляет запрос. Если сервер возвращает чужие данные, значит, система уязвима.

Иногда злоумышленник проверяет ID автоматически с помощью перебора. Например, он может написать скрипт, который перебирает различные значения ID: 12 345, 12 346, 12 347 и так далее, и сохраняет результаты.

Шаг 3. Использование найденной информации

Если сервер уязвим, злоумышленник может:

• Красть информацию. Например, загружать документы других пользователей, просматривать чужие профили или списки заказов.
• Менять личные данные. Обычно пользователь может редактировать только свою информацию, но из-за уязвимости IDOR злоумышленник получает доступ к чужим данным. Например, может изменить адрес доставки в чужом заказе, поменять пароль пользователя или номер его карты.
• Выполнять действия от имени другого пользователя. Например, отменять заказы, удалять файлы или отправлять запросы, используя чужую учетную запись.

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

Если система не защищена от IDOR, злоумышленник может обойти проверки прав доступа и получить доступ к чужим данным. Это приведет к утечке конфиденциальной информации, нарушению законодательства о защите данных и потере доверия пользователей.

На платформе Start EDU разработчики учатся не только находить и исправлять уязвимости, но и предотвращать их появление на этапе написания кода. Запишитесь на бесплатное демо, и наш эксперт покажет, как Start EDU помогает защитить приложение от IDOR и других уязвимостей.

IDOR — одна из самых распространенных уязвимостей в веб-системах. Чтобы защититься от нее, нужно всегда проверять права доступа, безопасно работать с идентификаторами и соблюдать принципы безопасности.

Проверяйте права доступа

Каждый запрос к серверу должен проходить проверку, чтобы убедиться, что доступ к объекту получает только тот пользователь, который имеет на это право. Наличие правильного идентификатора не должно автоматически давать доступ к ресурсу.

Например, если пользователь запрашивает данные заказа с ID «123», нужно удостовериться, что этот заказ действительно принадлежит ему или запрашивается согласно правам доступа. В случае нарушения прав клиенту должен быть возвращен ответ, например, с кодом «403 Forbidden».

Критически важно, чтобы все проверки прав доступа выполнялись на стороне сервера. Опасно полагаться на клиентские проверки, так как злоумышленник может изменить запрос или обойти клиентскую логику, взаимодействуя напрямую с API.

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

Используйте сложные идентификаторы

Одна из причин успешной эксплуатации IDOR — использование легко предсказуемых идентификаторов в URL или запросах.

Простые числовые ID вроде 1, 2, 3 подвержены атакам методом перебора, когда злоумышленники генерируют сотни запросов для получения данных.

Чтобы минимизировать этот риск, лучше применять уникальные и сложные идентификаторы, такие как UUID, например, «550e8400-e29b-41d4-a716−446 655 440 000». Их сложнее подобрать, а значит, снижается вероятность успешной атаки, при этом сам по себе UUID-идентификатор не защищает от IDOR, а лишь усложняет эксплуатацию для хакера.

Кроме этого, рекомендуем ограничивать возможности пользователя в запросах, скрывая избыточные данные. Например, если нет необходимости явно указывать ID в URL, можно создать запросы, которые не используют внешние идентификаторы, например, /orders/current.

Логируйте и анализируйте запросы

Логирование помогает предотвращать атаки, потому что правильно настроенные журналы фиксируют подозрительную активность:

• массовые попытки перебора идентификаторов;
• аномальные запросы, которые могут указывать на доступ к нежелательным для пользователя ресурсам;
• неожиданные изменения или ошибки системы.

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