Common 1

Что проверяем

• Запросы OAuth

  • Привязка code

  • Привязка token к сессии без CSRF (в данном случае это или code или nonce, в зависимости от реализации)

• redirect_uri

  • Настроены ли белые списки для этого параметра (можно ли запросить OAuth ссылку со своим redirect_uri)

  • Как происходит валидация этого параметра

• Обращение к данным без токенов (IDOR); использование скрытых эндпоинтов (private api) без токенов

• Передача ролей и разрешений (permissions) как часть запросов — можем ли на это влиять

Еще что проверяем

Соответствие code и scope

На стороне сервера должна идти перепроверка соответстия code grant и type grant scope (возможно ситуация, при которой пользователь предоставил доступ только к email, а злоумышленник отправляет на сервер, предоставляющий доступ по коду, полученный код от пользователя и доставляет доп scope. Если сервер не может перепроверить соотв кода и скопа — это плохо)

Проверять куда отправляет code c redirect_uri

Прикольную вулну увидел у одного из заказчиков (не я нашел, я не обратил внимания): В веб-приложении присутствует OAuth авторизация через сторонний сервис. Они в redirect_uri проставляют на локальную страницу ссылку (например, /page) для получения кода А на /page присутствует запросы к разного рода аналитике (например, Google Analytics) Так в итоге, когда через OAuth присылается код, то со страницы /page происходят запросы к аналитике, и туда через Referer утекают коды на сторону

Mitigation:

• Использовать в качестве параметра redirect_uri URL, не содержащий ссылок на сторонние ресурсы.

• Ограничить отправку заголовка Referrer на сторонние ресурсы с помощью заголовка Referrer-Policy.

Не допускать повторение идентификационных данных

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