Перейти к содержанию

API5:2019 Некорректная Авторизация на Уровне Функций

Источники угроз/Векторы атак Недостатки безопасности Последствия
Зависит от API : Сложность эксплуатации 3 Распространенность 2 : Сложность обнаружения 1 Технические последствия 2 : Зависит от бизнеса
Эксплуатация уязвимости предполагает, что злоумышленник может успешно отправить запросы в точки входа API, к которым у него не должно быть доступа. Эти точки входа могут быть доступны любому неаутентифицированному пользователю или аутентифицированному пользователю, не имеющему достаточных привилегий. Подобную ошибку легче обнаружить в API (по сравнению с традиционными приложениями), поскольку API более структурированы, а порядок доступа к определенным функциям более предсказуем (например, изменив метод HTTP запроса с GET на PUT, или изменив строку “users” в URL запроса на "admins"). Проверки авторизации к функции или ресурсу обычно определяются на уровне конфигурации, иногда на уровне кода. Проведение проверок надлежащим образом - непростая и неоднозначная задача, поскольку современные приложения могут использовать много типов ролей и групп, а также иметь сложную иерархию пользователей (например, под-пользователей или пользователей с несколькими ролями). Подобные ошибки позволяют злоумышленнику получить доступ к функционалу, минуя авторизацию. Административный функционал - ключевая цель атак этого типа.

Как определить, является ли API уязвимым?

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

  • Может ли обычный пользователь получить доступ к административным точкам входа?
  • Может ли пользователь совершить критичные действия (например, создать, изменить или удалить объект), к которым у него не должно быть доступа, просто изменив метод HTTP запроса (например, с GET на DELETE)?
  • Может ли пользователь из группы Х получить доступ к точке входа, доступной только пользователям из группы Y, просто угадав URL и параметры этой точки входа (например, /api/v1/users/export_all)?

Неверно предполагать, что точка входа API является обычной или административной только на основании пути URL.

Зачастую разработчики открывают доступ к административным точкам входа по определенному относительному пути, например, api/admins. Однако очень часто административные точки входа находятся по другим относительным путям вместе с обычными точками входа, например, api/users.

Примеры сценариев атаки

Сценарий #1

В ходе процесса регистрации в приложении, которое позволяет регистрироваться только приглашенным пользователям, мобильное приложение отправляет следующий запрос к API GET /api/invites/{invite_guid}. Ответ содержит JSON с деталями приглашения, включая роль пользователя и его электронную почту.

Злоумышленник может дублировать запрос, изменив HTTP метод и точку входа на POST /api/invites/new. Только администраторы должны иметь доступ к этой точке входа через интерфейс администрирования, однако он не проводит проверки авторизации на уровне функций.

Проэксплуатировав уязвимость, злоумышленник может отправить себе приглашение с ролью администратора:

POST /api/invites/new

{“email”:”[email protected]”,”role”:”admin”}

Сценарий #2

API содержит точку входа, которая должна быть доступна только администраторам GET /api/admin/v1/users/all. Эта точка входа возвращает данные всех пользователей и не проводит проверки авторизации на уровне функции. Злоумышленник, изучив структуру API, подбирает URL и получает доступ к точке входа, которая возвращает критичные данные пользователей приложения.

Как предотвратить

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

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

Ссылки

OWASP

Внешние