Хакеры атакуют логику: разбираем IDOR-уязвимости на реальном примере API

Представьте, что у каждого пользователя в интернете есть свой персональный сейф — номерной, с важными данными. Вы приходите к своему сейфу №123, вставляете ключ и забираете содержимое. А что, если можно подойти к сейфу №124 и просто дернуть за ручку? Если дверь открывается — вы только что столкнулись с IDOR.

Что такое IDOR?

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

Проще говоря, приложение думает: «Раз пользователь знает ID, значит, так и надо». Это фатальная ошибка логики.

Разберем на реальном примере API

Допустим, у нас есть API интернет-банка. Есть метод для просмотра деталей перевода:

GET /api/v1/transactions/12345

Сервер возвращает JSON с информацией о переводе, если он существует. Но ключевой вопрос: а чей это перевод?

Уязвимый код (упрощенно):

Уязвимый код на Python (Flask). Сервер слепо доверяет переданному transaction_id.

В чем проблема? Сервер не проверяет, принадлежит ли транзакция 12345 авторизованному пользователю. Злоумышленник может просто перебрать ID: 12346, 12347 и т.д., и получить доступ к чужим финансовым операциям. Это классическая IDOR-атака.

Как это выглядит на практике:

1. Пользователь Алексей (ID=101) авторизовался в системе.
2. Он видит в истории свой перевод с ID=12345.
3. Он любопытствует и вручную меняет URL запроса на /api/v1/transactions/12346.
4. Сервер, недолго думая, отдает ему данные перевода пользователя Марии (ID=102).
5. Утечка конфиденциальных данных состоялась.
   

Исправление: добавляем контекст пользователя

Правильный подход — всегда учитывать, кто делает запрос. Сервер должен явно проверять права.
Защищенный код:

Защищенный код. Сервер проверяет, что transaction_id принадлежит current_user.id.

Теперь, даже если Алексей попробует запросить 12346, сервер проверит в базе: «А есть ли транзакция 12346 у пользователя 101?». Нет? Значит, вернется стандартная ошибка 404. Атака предотвращена.

Основные методы защиты:

1. Проверка прав на каждом запросе: Всегда связывайте объект с текущим авторизованным пользователем.
2. Непредсказуемые идентификаторы: Используйте UUID вместо последовательных чисел 1, 2, 3. Это усложняет перебор.
3. Косвенные ссылки: Храните на клиенте не прямой ID объекта, а свой зашифрованный токен или ссылку, которую сервер будет расшифровывать и проверять.

Вывод: Безопасность API — это не только защита от SQL-инъекций. Это, в первую очередь, продуманная логика контроля доступа. Не доверяйте данным от клиента. Всегда проверяйте права. Создавайте код, который по умолчанию подозревает всех и вся.

Опрос для читателей:

Сможете ли вы теперь разобраться в незнакомом API?

• Да, все оказалось логично! ✅
• Нужно больше практики. 🛠️
• Я все равно ничего не понял(а). ❌