Уязвимости OAuth и схемы атак

Серверы авторизации OAuth должны строго проверять параметр redirect_uri. Если сервер разрешает сопоставление по префиксу или подстановочным символам (например, принимает любой URL, начинающийся с "https://app.example.com"), злоумышленник создает запрос авторизации с перенаправлением на "https://app.example.com.attacker.com/steal" или на открытое перенаправление в легитимном домене и крадет код авторизации.

Без защиты от CSRF злоумышленник может инициировать поток OAuth и обманом заставить браузер жертвы завершить авторизацию. Жертва непреднамеренно авторизует клиент злоумышленника. Параметр "state" (RFC 6749) предотвращает это: клиент генерирует случайное значение state, включает его в запрос и проверяет совпадение в обратном вызове. При несовпадении поток прерывается.

На мобильных платформах вредоносные приложения могут зарегистрировать ту же пользовательскую схему URI, что и легитимный клиент OAuth, и перехватить коды авторизации, перенаправленные после аутентификации пользователя. PKCE обеспечивает полную защиту: перехваченный код бесполезен без верификатора кода, который только легитимное приложение сгенерировало в начале потока.

Если токен ID или токен доступа включен во фрагмент URL или параметр запроса, последующие переходы с этой страницы содержат URL в заголовке Referer, что может привести к утечке токена сторонним аналитическим скриптам или поставщикам CDN. Всегда используйте поток с кодом авторизации и передачей токена по обратному каналу, чтобы токены не появлялись в URL.

Когда клиент поддерживает несколько поставщиков OAuth, атаки смешения заставляют его отправить код авторизации, полученный у поставщика A, на конечную точку токенов поставщика B. Клиент должен проверять утверждение "iss" в токенах ID и связывать обратный вызов с конкретным поставщиком, который инициировал поток, используя параметр state или JARM (режим защищенного JWT ответа авторизации).

Атаки с подделкой серверных запросов (SSRF) направлены на реализации OAuth, которые выполняют серверные HTTP-запросы к redirect_uri. Если сервер авторизации получает redirect_uri, чтобы проверить его, злоумышленник может указать внутренний IP-адрес (например, http://169.254.169.254/latest/meta-data/), чтобы получить доступ к метаданным облачного экземпляра или внутренним службам. Строгая проверка redirect_uri на основе списка разрешений предотвращает это.

Многие приложения используют утверждение email из токена ID OIDC для связывания учетных записей разных поставщиков. Если злоумышленник контролирует адрес электронной почты, совпадающий с адресом учетной записи жертвы у другого поставщика, он может зарегистрироваться у другого поставщика с этим адресом и получить доступ к учетной записи жертвы. Защита: связывайте учетные записи только по паре (iss, sub), никогда не используйте для этого только адрес электронной почты.

Атаки с путаницей алгоритмов JWT используют уязвимые реализации, которые доверяют заголовку "alg" при выборе алгоритма проверки. Атака заключается в изменении "alg" с "RS256" на "HS256" и подписывании токена открытым ключом сервера в качестве секрета HMAC, поскольку открытый ключ доступен всем. Защита: всегда явно указывайте ожидаемый алгоритм в коде проверки и никогда не доверяйте утверждению alg из заголовка токена.

Злоумышленники регистрируют вредоносных клиентов OAuth с похожими на настоящие названиями и логотипами, а затем отправляют целям фишинговые ссылки. Жертва видит настоящий экран согласия OAuth (размещенный Google, Microsoft и другими компаниями) для вредоносного приложения и предоставляет ему доступ. Защита: проверяйте, что client_id соответствует ожидаемому приложению; Google и Microsoft предоставляют программы проверки клиентов для легитимных приложений.

Повышение области действия происходит, когда клиент получает токены с более широкими разрешениями, чем те, которые авторизовал пользователь. К повышению привилегий через OAuth могут привести недостатки реализации, из-за которых пропускается проверка области действия на конечной точке токенов, токены кэшируются с объединенными областями действия из разных запросов или не проверяется, что область действия в выпущенном токене не превышает авторизованную область действия.

Защищайте реализации OAuth следующим образом: используйте проверку redirect_uri с точным совпадением, требуйте PKCE для всех публичных клиентов, проверяйте параметр state для защиты от CSRF, связывайте токены ID по паре (iss, sub), а не по электронной почте, явно указывайте ожидаемые алгоритмы JWT, запрашивайте минимально необходимые области действия, используйте токены доступа с коротким сроком действия и ротацией токенов обновления, а также проверяйте внешний вид экранов согласия на риск имитации бренда.

Сервер авторизации OAuth принимает любой redirect_uri, начинающийся с "https://app.example.com". Какую атаку это позволяет провести?

Ключевые атаки OAuth: открытое перенаправление из-за недостаточно строгой проверки redirect_uri (используйте точное совпадение), CSRF из-за отсутствия параметра state, перехват кода на мобильных устройствах (устраняется с помощью PKCE), утечка токенов в URL, атаки смешения в конфигурациях с несколькими поставщиками (проверяйте iss), SSRF из-за получения redirect_uri сервером, конфликт утверждений электронной почты (используйте iss+sub), путаница алгоритмов JWT (фиксируйте ожидаемый alg) и фишинг через поддельные экраны согласия.