• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Распространенные уязвимости OAuth

Отслеживать
ATT

ATT

HDD-drive
Пользователь
Регистрация
23.05.2025
Сообщения
21
Реакции
33
Переведено для xss.pro
Оригинал: https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html
30 Jan 2025 - Posted by Jose Catalan, Szymon Drosdzol

Популярность протокола OAuth 2.0 делает его главной мишенью для злоумышленников. Несмотря на то, что OAuth упрощает процесс входа для пользователей, его сложность часто приводит к ошибкам в конфигурации, которые создают уязвимости в безопасности. Некоторые из наиболее сложных уязвимостей постоянно возникают вновь, поскольку внутренние механизмы протокола не всегда до конца понятны. Чтобы исправить эту ситуацию, мы решили создать всеобъемлющее руководство по известным атакам на реализации OAuth. Кроме того, мы разработали подробный чеклист, который будет полезен как тестировщикам, так и разработчикам для быстрой оценки уровня защищенности их реализации протокола.
Загрузить шпаргалку по безопасности OAuth! Doyensec_OAuth_CheatSheet.pdf.

Введение в OAuth​

Терминология OAuth​

  • OAuth — это сложный протокол, включающий множество компонентов и динамичных элементов. Прежде чем мы углубимся в его внутреннюю работу, давайте рассмотрим его терминологию.
  • Владелец ресурса: обычно это конечный пользователь, который может предоставить доступ к защищенному ресурсу.
  • Клиент: приложение, запрашивающее доступ к защищенному ресурсу от имени владельца ресурса.
  • Сервер ресурсов: сервер, на котором размещены защищенные ресурсы. Это API, к которому вы хотите получить доступ.
  • Сервер авторизации: сервер, который проверяет подлинность владельца ресурса и выдает токены доступа после получения соответствующей авторизации. Например, Auth0.
  • Пользовательский агент: агент, который владелец ресурса использует для взаимодействия с клиентом (например, веб-браузер или нативное приложение).

Ссылки​


Основные потоки OAuth​

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

Неявный поток (Implicit Flow)
Неявный поток изначально был разработан для нативных или одностраничных приложений, которые не могут надежно хранить учетные данные клиента. Однако сейчас он не рекомендуется к использованию, и не включен в спецификацию OAuth 2.1. Несмотря на это, он по-прежнему является эффективным решением аутентификации в Open ID Connect (OIDC) для извлечения id_tokens.

В этом процессе пользовательский агент перенаправляется на сервер авторизации. После успешной аутентификации и получения согласия сервер авторизации напрямую выдает токен доступа, который становится доступным для владельца ресурса. Однако, при таком подходе токен доступа может быть скомпрометирован через уязвимости, такие как XSS или недостаточная проверка redirect_uri, так как он доступен для пользовательского агента. Если response_mode не установлен в значение form_post, токен доступа передается как часть URL в потоке неявного кода.

1751024478039.png


Ссылки​


Поток кода авторизации (Authorization Code Flow)​

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

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

1751024518906.png


Ссылки​


Поток кода авторизации с ключ подтверждения для обмена кодами (Authorization Code Flow with PKCE)​

OAuth 2.0 предоставляет версию потока авторизационного кода, в которой используется ключ подтверждения для обмена кодами (PKCE). Этот поток OAuth изначально был разработан для приложений, которые не могут хранить секрет клиента, например, нативных или одностраничных приложений, но он стал основной рекомендацией спецификации OAuth 2.1.

В стандартный поток авторизационного кода добавлены два новых параметра: случайно сгенерированное значение, называемое code_verifier, и его преобразованная версия, code_challenge.
  • Клиент генерирует code_verifier (секретный код) и его преобразованную версию t(code_verifier), известную как code_challenge. Затем code_challenge вместе с методом преобразования t_m отправляется в запросе на авторизацию.
  • Клиент отправляет код авторизации в запросе на токен доступа, включая секретный code_verifier.
  • Сервер авторизации преобразует полученный code_verifier и сравнивает его с t(code_verifier) для проверки подлинности.
Доступны следующие методы преобразования (t_m):
  • Прямое преобразование code_challenge = code_verifier
  • Метод S256 code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
Обратите внимание, что использование потока кода авторизации по умолчанию с пользовательской схемой redirect_uri, например example.app:// потенциально может позволить вредоносному приложению зарегистрироваться в качестве обработчика этой пользовательской схемы наряду с легитимным приложением OAuth 2.0. В таком случае вредоносное приложение сможет перехватить код авторизации и обменять его на токен доступа. Более подробную информацию см. в разделе “Перехват схемы перенаправления OAuth”.

При использовании PKCE перехват ответа авторизации не позволит реализовать предыдущий сценарий атаки, поскольку злоумышленники смогут получить доступ только к коду авторизации authorization_code, но не смогут получить значение code_verifier, требуемое в запросе токена доступа.

На диаграмме ниже показан поток кода авторизации с использованием PKCE:

1751024772495.png


Ссылки​


Поток учетных данных клиента (Client Credentials Flow)​

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

На диаграмме ниже показан поток клиентских учетных данных:

1751024809979.png


Ссылки​


Поток авторизации устройства (Device Authorization Flow)​

Поток авторизации устройства используется для интернет-устройств с ограниченными возможностями ввода данных (например, без браузера), что делает невозможным применение текстовой аутентификации в процессе авторизации.

Этот поток позволяет OAuth-клиентам на смарт-телевизорах, медиаприставках, цифровых фоторамках и принтерах получать доступ к защищенным ресурсам. Разрешение на доступ предоставляется через пользовательский агент на отдельном устройстве.

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

На следующем изображении показан поток авторизации кода устройства:

1751024862413.png


Ссылки​


Поток с использованием учетных данных владельца ресурса (Resource Owner Password Credentials Flow)​

Для этого потока необходимо, чтобы владелец ресурса полностью доверял клиенту свои учетные данные для сервера авторизации. Он был разработан для случаев, когда невозможно использовать потоки на основе перенаправления. Однако, в недавней спецификации OAuth 2.1 RFC он был удален, и его использование не рекомендуется.

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

На следующем изображении показан поток с использованием учетных данных владельца ресурса:

1751024909331.png


Ссылки​


Атаки​

В этом разделе мы расскажем о распространенных атаках на OAuth и основных стратегиях устранения их последствий.

Межсайтовая подделка запроса (Cross-Site Request Forgery)​

OAuth CSRF – это тип атаки на потоки OAuth, при которой происходит несовпадение между браузером, инициировавшим поток, и браузером, использующим код авторизации. Злоумышленник может использовать эту уязвимость, чтобы заставить жертву использовать свой (злоумышленника) код авторизации. В результате жертва будет подключена к контексту авторизации злоумышленника.

Рассмотрим следующую схему:

01.png


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

Смягчение атаки (Mitigation)​

Спецификация OAuth рекомендует использовать параметр state для предотвращения CSRF атак.

[state is] an opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery (CSRF).

Следующая схема иллюстрирует, как параметр state может предотвратить атаку:

02.png


Ссылки​


Aтаки с перенаправлением (Redirect Attacks)​

Хорошо реализованные серверы авторизации проверяют параметр redirect_uri перед перенаправлением агента пользователя обратно клиенту. Список разрешенных значений redirect_uri должен быть настроен для каждого клиента. Такая схема гарантирует, что агент пользователя может быть перенаправлен только к клиенту, а код авторизации будет раскрыт только данному клиенту. И наоборот, если сервер авторизации пренебрегает этой проверкой или выполняет ее неправильно, злоумышленник может заставить жертву выполнить поток, который раскроет ее код авторизации недоверенной стороне.

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

03.png


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

К распространенным ошибкам относятся:
  • проверка только происхождения/домена
  • разрешение поддоменов
  • разрешение подпутей
  • разрешение на использование подстановочных символов (wildcards)
Если указанный источник содержит URL-адрес с уязвимостью открытого перенаправления или страницу с пользовательским контентом, существует риск кражи кода через заголовок Referer или открытое перенаправление.

С другой стороны, были выявлены следующие упущения:
  • частичное совпадение пути
  • неправильное использование регулярных выражений для сопоставления URI
которые могут привести к различным пробелам в защите путем создания вредоносных URL-адресов, которые перенаправляют на ненадежные источники.

Ссылки​


Атака с использованием изменяемых утверждений (Mutable Claims Attack)​

Согласно спецификации OAuth, поле sub предназначено для уникальной идентификации пользователей, но не имеет стандартизированного формата. Это привело к появлению множества различных форматов, зависящих от сервера авторизации. Некоторые клиентские приложения, стремясь унифицировать идентификацию пользователей на разных серверах авторизации, используют идентификаторы пользователей или адреса электронной почты. Однако такой подход может быть рискованным. Некоторые серверы авторизации не гарантируют неизменность пользовательских свойств, а в худшем случае пользователи могут изменять их произвольно. Это создает уязвимость для захвата учетных записей.

Рассмотрим сценарий, когда функция «Войти с помощью Microsoft» использует поле email для идентификации пользователя. В этом случае злоумышленник может создать собственный домен Active Directory (например, doyensectestorg) в Azure, чтобы инициировать вход через Microsoft. В то время как идентификатор объекта (Object ID), находящийся в поле sub, является постоянным и не может быть подделан, поле email полностью контролируется пользователем и не требует никакой проверки.

04.png


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

Ссылки​


Атака, вызывающая путаницу клиента (Client Confusion Attack)​

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

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

05.png


Если шаги 8-10 не будут выполнены и идентификатор клиента токена не будет подтвержден, это позволит осуществить следующую атаку:

06.png


Устранение последствий атаки (Remediation)​

Даже при использовании более безопасного потока (например, явного) клиент может принимать токены доступа, что фактически делает его уязвимым для перехода на неявный поток. Более того, приложение становится уязвимым, если использует токены доступа в качестве сеансовых cookie-файлов или заголовков авторизации. Чтобы прервать цепочку эксплуатации на ранней стадии, токены доступа никогда не должны приниматься из контролируемых пользователем параметров. Также рекомендуется выполнять проверку токена, как описано в шагах 8–10.

Ссылки​


Атака на повышение области доступа (Scope Upgrade Attack)​

При использовании разрешения типа Authorization Code Grant, данные пользователя запрашиваются и отправляются посредством защищенного соединения сервер-сервер.

Если сервер авторизации принимает и автоматически доверяет параметру scope, переданному в запросе на получение токена доступа (обратите внимание, что этот параметр не указан в RFC для запроса на получение токена доступа в потоке авторизационного кода), вредоносное приложение может попытаться повысить область доступа (scope) кодов авторизации, получаемых из обратных вызовов пользователя, отправив запрос на получение токена доступа более привилегированного уровня.

После того как токен доступа сгенерирован, сервер ресурсов должен проверить токен доступа для каждого запроса. Эта проверка зависит от формата токена доступа. Обычно используются следующие форматы:
  • Токен доступа JWT: при использовании этого типа токена доступа серверу ресурсов необходимо только проверить подпись JWT, а затем извлечь данные, включенные в JWT (client_id, scope, и т. д.).
  • Токен доступа к случайной строке: поскольку этот тип токена не содержит никакой дополнительной информации, серверу ресурсов необходимо получить информацию о токене с сервера авторизации.
07.png


Устранение последствий атаки (Mitigation)​

Согласно рекомендациям RFC, параметр scope не следует передавать в запросе токена доступа при использовании потока кода авторизации. Однако использование допустимо в других потоках, например, в потоке авторизации с использованием пароля владельца ресурса.

Сервер авторизации должен либо проигнорировать параметр scope , либо проверить его соответствие предыдущему параметру scope, указанному в запросе авторизации.

Ссылки​


Перехват схемы перенаправления (Redirect Scheme Hijacking)​

Когда возникает необходимость использовать OAuth на мобильных устройствах, мобильные приложения берут на себя роль OAuth User Agents. Для того чтобы они могли получать перенаправление с кодом авторизации, разработчики часто используют механизм пользовательских схем. Однако множество приложений могут зарегистрировать данную схему на одном устройстве. Это нарушает предположение OAuth о том, что только клиент может контролировать настроенный redirect_uri, и может привести к перехвату кода авторизации в случае установки вредоносного приложения на устройствах жертв.

Android Intent URI имеют следующую структуру:
<scheme>://<host>:<port>[<path>|<pathPrefix>|<pathPattern>|<pathAdvancedPattern>|<pathSuffix>]

Так, например, следующий URI com.example.app://oauth отображает intent с scheme=com.example.app и host=oauth. Чтобы получить эти intent, приложению Android необходимо экспортировать activity, подобный следующему:

Код: 
<intent-filter>
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <category android:name="android.intent.category.BROWSABLE"/>
        <data android:host="oauth" android:scheme="=com.example.app"/>
    </intent-filter>

Система Android проявляет значительную гибкость при определении фильтров намерений. Чем менее детализирован фильтр, тем шире охват и, соответственно, больше URI могут быть перехвачены. Например, указание только scheme, позволяет перехватывать все намерения для этой схемы, независимо от host, path и других параметров.

Если возможно перехватить данное намерение более чем одним приложением, система потребует вмешательства пользователя для выбора приложения для перенаправления. Однако, с помощью описанной выше информации, можно попытаться обойти систему, в зависимости от того, как настроен фильтр легитимного приложения. Парадоксально, но чем точнее разработчики определили параметры, тем проще создать обходной путь и перехватить перенаправление без участия пользователя. Для быстрой оценки этой возможности, Ostorlab разработал следующую блок-схему:

08.png

​

Рекомендации​

В ситуациях, когда явный поток авторизационного кода не допустим, так как клиент не может безопасно хранить клиентский секрет, был создан поток с подтверждением ключа для обмена кодом (PKCE). Мы рекомендуем использовать этот поток для авторизации в мобильных приложениях.

Кроме того, для восстановления доверительной связи между сервером авторизации и целью redirect_uri рекомендуется использовать такие механизмы как подтвержденные ссылки (Verifiable Links) в Android и связанные домены (Associated Domains) в iOS.

По сути, это анонсированное в Android свойство autoVerify для Intent Filters. Разработчики могут создать Intent Filter, который будет выглядеть следующим образом:

Код: 
<intent-filter android:autoVerify="true">
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="http" />
  <data android:scheme="https" />
  <data android:host="www.example.com" />
</intent-filter>

Когда Intent Filter настроен, как описано выше, Android проверяет принадлежность указанного хоста к разработчику приложения. Хост должен разместить файл /.well-known/assetlinks.json в соответствующем домене, ссылающийся на данный APK. Это необходимо для обработки следующих ссылок:

Код: 
[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Благодаря такой схеме, мошеннические приложения не могут зарегистрировать свой собственный Intent Filter для уже заявленного хоста, хотя это сработает только в том случае, если обрабатываемая схема не является пользовательской. Например, если приложение обрабатывает com.example.app:// схему, невозможно присвоить ей дополнительный приоритет. В такой ситуации пользователю придется вручную выбирать одно из приложений, поддерживающих обработчик для этой конкретной схемы.

Ссылки

Заключение​

В этой статье подробно описаны атаки и методы защиты, связанные с протоколом OAuth. В дополнение к статье мы предлагаем полную «шпаргалку», которая будет полезна как разработчикам, так и тестировщикам.

Загрузить памятку по безопасности OAuth Doyensec_OAuth_CheatSheet.pdf.

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

Вложения

  • 02.png
    02.png
    57.9 КБ · Просмотры: 11
  • 08.png
    08.png
    52 КБ · Просмотры: 11
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх