данные или код для входа предоставленные по протоколу oauth недействительны

Двухфакторная аутентификация в Фортнайт

Автор: Admin · Опубликовано 11/12/2018 · Обновлено 15/12/2018

С каждым днём открывается всё больше магазинов аккаунтов, а это значит, что всё больше людей лишаются своих учетных записей из-за невнимательности. Мы убедительно рекомендуем Вам настроить двухфакторную аутентификацию Epic Games, чтобы защитить свой аккаунт от различных видов взлома. Кстати, двойная аутентификация нужна и для многих функций клиента Epic Games, например для отправки подарков в фортнайт.

Двухфакторная аутентификация фортнайт — это система защиты, при которой у пользователя запрашивают короткий код для подтверждения личности пользователя. На данный момент существует 2 метода двухфакторной аутентификации: отправка сообщения на электронную почту или на специальное приложение. Метод Вы выбираете сами.

Система запрашивает код в следующих ситуациях:

Чтобы включить двойную аутентификацию нужно:

Далее подробно рассмотрим оба варианта.

Мобильный аутентификатор фортнайт

1. Для начала Вам следует установить на мобильный одну из следующих программ. Их можно найти в AppStore или Play Market Google.

2. Нажимаете на кнопку «Включить аутентификатор»

3. Перед вами появляется окно с QR кодом. Откройте приложение которое Вы выбрали в пункте 1, нажмите в нём на кнопку добавить и подведите камеру к QR коду.

4. В приложение появится новая строчка с постоянно меняющимися цифрами. Введите эти цифры в поле «Код безопасности»

Внимание! Если Вам говорят, что код не верный, проверьте включена ли на телефоне автоматическая синхронизация времени по сети.

5. Если Вы всё сделали верно и увидели данное окно — скорее заходите в игру, там Вас ждёт новая эмоция!

Почтовый аутентификатор фортнайт

1. Выберите пункт «Включить аутентификацию по почте»

2. На почту вашего аккаунта сразу будет отправлен код, который необходимо ввести в это окно.

3. Если вы всё сделали верно, то увидите это окно, а в фортнайте найдёте новую эмоцию!

Итог: Теперь при попытке входа на Ваш аккаунт с другого устройства клиент игры будет запрашивать код из приложения или код который выслан на почту. Украсть такой аккаунт очень сложно, так что вы надёжно защищены.

Важно. Никому не сообщайте код, который Вам присылают.

Источник

Описание ошибок протокола OAuth 2.0

В данном разделе приводится описание ошибок, возникающих при выполнении запросов в рамках протокола OAuth 2.0 и OpenId Connect 1.0.

В случае возникновения ошибок сервер возвращает информацию в двух полях:

Далее будет представлена информация по кодам ошибок.

Ошибки конечной точки /authorize

invalid_request

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

Возможные причины

unauthorized_client

Клиент с указанным в запросе идентификатором не зарегистрирован, отключён, либо клиенту запрещено получения маркера доступа в рамках данного сценария.

Возможные причины

unsupported_response_tpe

Тип ответа не поддерживается.

Указанный в запросе response_type не поддерживается.

Возможные причины

invalid_scope

Неправильная область использования.

Указанный в запросе scope не зарегистрирован на сервере.

Возможные причины

login_required

Запрос не может быть выполнен в интерактивном режиме (с указанием параметра prompt со значением none ).

Возможные причины

Ошибки конечной точки /token

invalid_request

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

Возможные причины

invalid_client

Не удалось осуществить аутентификацию клиента.

Возможные причины

invalid_grant

Разрешение, используемое клиентом, не является действительным.

Возможные причины

unauthorized_client

Клиент с указанным в запросе идентификатором не зарегистрирован, отключён, либо переданы неверные учётные данные клиента.

Возможные причины

usupported_grant_type

Неподдерживаемый тип разрешение.

Разрешение, используемое клиентом, не поддерживается сервером.

Возможные причины

Источник

Тонкости авторизации: обзор технологии OAuth 2.0

Информационная система Dodo IS состоит из 44 различных сервисов, таких как Трекер, Кассы ресторана или Базы знаний и многих других. Чтобы не отвлекаться на несколько аккаунтов, 3 года назад мы написали сервис Auth для реализации сквозной аутентификации, а сейчас пишем уже вторую версию, в основе которого лежит стандарт авторизации OAuth 2.0. Этот стандарт довольно сложный, но если у вас сложная архитектура с множеством сервисов, то OAuth 2.0 вам пригодится при разработке своего сервиса аутентификации. В этой статье я постарался рассказать о стандарте максимально просто и понятно, чтобы вы сэкономили время на его изучение.

Задача Auth

Проблема авторизации в десятках сервисов встречалась ещё несколько лет назад — в начале «эпохи распила монолита». Эту проблему решили новым сервисом, который назвали – Auth. Он помог реализовать бесшовную аутентификацию в различных сервисах и перенести данные о пользователях в отдельные базы данных.

У сервиса Auth есть три основные задачи:

Проблемы

Первая версия Auth — часть монолита. Он использует свой собственный протокол общения с сервисами. Такая «схема» была необходима в тот момент, но за несколько лет работы проявились проблемы.

Auth — часть монолита. Следовательно, сервис привязан к релизному циклу, что лишает возможности независимой разработки и деплоя. Кроме того, придется разворачивать весь монолит, если захотелось развернуть Auth, например, при масштабировании сервиса.

Dodo IS зависит от Auth. В старой реализации внешние сервисы обращаются к Auth при каждом действии пользователя, чтобы валидировать данные о нём. Настолько сильная привязка может привести к остановке работы всей Dodo IS, если Auth «приляжет» по какой-то причине.

Auth зависит от Redis. Притом достаточно сильно — неисправность работы Redis’а приведёт к падению Auth’а. Мы используем Azure Redis, для которого заявленный SLA 99,9%. Это значит, что сервис может быть недоступен до 44 минут в месяц. Такие простои не позволительны.

Текущая реализация Auth использует свой протокол аутентификации, не опираясь на стандарты. В большинстве своих сервисов мы используем C# (если говорим о backend) и у нас нет проблем с поддержкой библиотеки для нашего протокола. Но если вдруг появятся сервисы на Python, Go или Rust, разработка и поддержка библиотек под эти языки потребует дополнительных затрат времени и принесет дополнительные сложности.

Текущий Auth использует схему Roles Based Access Control, которая базируется на ролях. Обычно с ролью выдаётся полный доступ к определённому сервису, вместо привязки к конкретному функционалу. Например, в пиццериях есть заместители управляющего, которые могут вести определенные проекты: составлять графики или учитывать сырьё. Но у нас нет выдачи прав на конкретные компоненты системы. Приходится выдавать полный доступ к сервису, чтобы сотрудники могли получить доступ к составлению графиков или настройкам какого-либо компонента учёта.

Проблемы подтолкнули к тому, чтобы спроектировать и написать новую версию Auth. На старте проекта мы потратили 3 недели только на изучение стандартов авторизации и аутентификации OAuth 2.0 и OpenID Connect 1.0.

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

Что такое ОAuth2.0?

Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации — фреймворк авторизации OAuth2.0.

Стандарт был принят в 2012 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.

Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем.

OAuth 2.0 — это фреймворк авторизации.

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

В OAuth 2.0 определены четыре роли:

Важно: клиент должен быть заранее зарегистрирован в сервисе. Как это сделать?

Регистрация клиента

Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от фантазии конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.

Redirection URI — адрес, на который отправится владелец ресурса после успешной авторизации. Кроме авторизации, адрес используется для подтверждения, что сервис, который обратился за авторизацией, тот, за кого себя выдаёт.

Client type — тип клиента, от которого зависит способ взаимодействия с ним. Тип клиента определяется его возможностью безопасно хранить свои учётные данные для авторизации — токен. Поэтому существует всего 2 типа клиентов:

Токены

Токен в OAuth 2.0 — это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная — её формат не имеет значения для клиента. Токен — это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).

У каждого токена своё время жизни. Но у refresh token оно должно быть больше, т.к. он используется для получения access token. Например, если срок жизни access token около часа, то refresh token можно оставить жить на целую неделю.

Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением. Но это не безопасно. Если access token был скомпрометирован, его можно обнулить, а сервис получит новый Access token с помощью refresh token. В случае, если refresh token нет, то потребуется проходить процесс авторизации заново.

За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.

Права доступа

Права доступа выдаются клиенту в виде scope. Scope – это параметр, который состоит из разделённых пробелами строк — scope-token.

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

Абстрактный OAuth 2.0. Flow c применением Access token

Мы рассмотрели роли, рассмотрели виды токенов, а также как выглядят scope. Посмотрим на flow предоставления доступа к сервису.

Ниже представлена абстрактная схема (или flow) взаимодействия между участниками. Все шаги на данной схеме выполняются строго сверху вниз. Разберём детальнее.

Абстрактный OAuth 2.0. Flow c применением Refresh token

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

Что такое grant?

Grant — это данные, которые представляют из себя успешную авторизацию клиента владельцем ресурса, используемые клиентом для получения access token.

Например, когда мы где-либо аутентифицируемся с помощью Google, перед глазами всплывает уведомление. В нём говорится, что такой-то сервис хочет получить доступ к данным о вас или к вашим ресурсам (выводятся запрашиваемые scope-token). Это уведомление называется «Consent Screen».

В момент, когда нажимаем «ОК», в базу данных попадает тот самый grant: записываются данные о том, что такой-то пользователь дал такие-то доступы такому-то сервису. Клиент получает какой-то идентификатор успешной аутентификации, например строку, которая ассоциируется с данными в базе данных.

Существует 4 + 1 способа получения grant — grant type:

Client credentials grant flow

Имеет самый простой flow, напоминающий обычную авторизацию на любом сервисе. Она выполняется с помощью учётных данных клиента, которые представляют собой client id и client secret — аналог логина и пароля для пользователя. Так как для аутентификации требуется client secret, который должен соответствующе храниться, данный flow могут использовать только confedential клиенты.

Схема проста: клиент аутентифицируется на сервере авторизации передавая client id и client secret. В ответ получает access token, с которым уже может получить доступ к нужному сервису.

Этот flow требуется, когда клиент пытается получить доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации. Например, сервису А нужно время от времени ходить в сервис Б и актуализировать там данные о количестве пиццерий в сети.

Resource owner password credentials flow

По текущим рекомендациям безопасности описанных в данном RFC, данный flow не рекомендуется использовать вовсе из-за явных проблем с безопасностью.

Resource owner передаёт свой логин и пароль клиенту, например, через формы на клиенте. Клиент, в свою очередь, с помощью него получает access token (и, опционально, refresh token).

Здесь есть проблема. Resource owner просто берёт и отдаёт в открытом виде свой логин и пароль клиенту, что не безопасно. Изначально он был сделан только для клиентов, которым вы доверяете или тех, что являются частью операционной системы. Позже он был разрешён только для миграции с аутентификации по логину и паролю на OAuth 2.0. Текущие рекомендации по безопасности запрещают его использование.

Authorization code

Самый распространённый flow на данный момент. В основном используется для confidential клиентов, но с появлением дополнительной проверки с помощью PKCE, может применяться и для public-клиентов.

В данном flow взаимодействие client с resource owner проходит через user-agent (браузер). К user-agent есть одно требование: он должен уметь работать с HTTP-редиректами. Без этого resource owner не сможет попасть к серверу авторизации и вернуться обратно с grant.

Данный flow сложнее, чем предыдущие, поэтому будем разбирать по шагам. Для начала представим, что мы — resource owner и перешли на страницу сервиса онлайн-обучения, который хочет сохранять результаты обучения к нам в облако. Ему требуется получить доступ к нашему ресурсу, например, определённой директории в облаке. Мы нажимаем на «Авторизоваться» и начинается путешествие по Authorization code grant flow:

Следующий flow построен на основе этого.

Implicit grant

Это оптимизация Authorization code grant flow для public-клиентов, которые умеют работать с redirection URI. Например, для браузерных приложений на JavaScript, или мобильных приложений. Требование к user-agent, с помощью которого взаимодействуют клиент и resource owner, сохраняется: он должен уметь работать с HTTP-редиректами.

Между authorization code и implicit есть основное отличие: вместо получения authorization code и access token по нему, мы сразу получаем access token после успешной авторизации resource owner. Кроме того, здесь не используется client secret из соображений безопасности — приложение можно дизассемблировать и получить его. Подлинность проверяется только по redirection URI.

Многие шаги из данной схемы похожи на шаги из authorization code, но предлагаю их разобрать также подробно. Представим, что некое браузерное приложение хочет сохранять свои настройки в нашем Git-репозитории. Мы нажимаете «Войти в GitHub» и на этом этапе начинается работа Implicit flow:

Device authorization (RFC 8628)

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

Есть, как минимум, 3 требования к устройствам, чтобы работа с помощью Device authoraztion grant flow была возможна:

Возможно, схема кажется сложной из-за обилия стрелок. Разберём её также пошагово, как и разбирали сложные flow до него.

Представим, что мы пытаемся авторизоваться на web-сервисе с помощью телевизора. Мы видим кнопку «Авторизоваться как устройство» и нажимаем. В этот момент начинается наш Device flow:

Вместо вывода

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

Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.

Если статья была полезна и захотите подробностей — пишите в комментариях, и в следующих статьях расскажу о PKCE, о протоколе аутентификации OpenID Connect 1.0, о нашей реализации сервера аутентификации и многом другом.

Источник

Как это работает: вход на сайты через соцсети

Всё дело в единой авторизации.

Часто на сайтах вам могут предложить войти с помощью Google, Facebook или ВКонтакте. Если у вас есть аккаунт в одном из этих сервисов, вам не нужно будет регистрироваться с нуля: заполнять имя, почту и ставить свою фотографию — всё это будет сделано автоматически. Разберёмся, как это работает и насколько это безопасно.

Это история о технологии OAuth2.

В Яндекс можно войти через Гугл. Как тебе такое, юзернейм?

Для чего это нужно

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

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

Для этого и придумали OAuth.

OAuth — это как договор между сайтами

Яндекс, Гугл или любой другой сервис, который разрешает пользоваться своим пропуском, должны принять единый протокол обмена данных. Если по-простому, то они должны договориться:

«Мы даём друг другу данные вот в таком формате, мы принимаем их в этом формате, мы друг другу доверяем».

Эти договорённости закрепили в едином стандарте авторизации — OAuth. В нём написано, как выдавать пропуска, как их проверять и что делать в разных случаях.

Как работает единая авторизация

Для пользователя всё выглядит просто: нажал «Войти через Яндекс», подтвердил Яндексу своё желание войти на нужный сайт, и всё — вы уже зарегистрировались на новом сайте и можете им пользоваться. Но что происходит под капотом?

Когда посетитель, например, сайта о программировании, нажимает «Войти через Яндекс», этот сайт отправляет в Яндекс запрос и говорит: «Тут кто-то хочет войти на мой сайт через ваш сервис, можете разобраться?»:

Когда Яндекс получает такой запрос, ему нужно понять, что за посетитель пришёл на сайт и есть ли у него аккаунт Яндекса. Для этого он показывает всплывающее окно, где посетитель может войти в свой Яндекс-аккаунт. Это нужно, чтобы сервис понимал, на чьё имя выдавать пропуск для сайта. Если пользователь уже залогинен в Яндексе, его сразу узнают.

Как только посетитель вводит свой логин и пароль, Яндекс узнаёт его и спрашивает, доверяет ли он этому сайту о программировании и может ли Яндекс поделиться с сайтом данными о его имени и почте:

Дальше Яндекс отдаёт ваши данные сайту, он вас узнаёт, и готово:

Насколько это безопасно

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

Когда вы будете входить через OAuth, сервис вам скажет: «Вот какие данные у меня запрашивают. Давать доступ?». Когда вы разрешите доступ, эти данные перейдут на сайт. Откажетесь — не перейдут.

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

✅ Через OAuth нельзя отправить сообщения от вашего имени или сделать пост в вашей ленте новостей. Но, опять же, если это не OAuth, а отдельное приложение для фейсбука или VK, то возможно и такое. Помните все эти игры, которые постят от имени игроков «Я собрал капусту на своей ферме»? Вот это они.

✅ Через OAuth точно не передаётся ваш пароль от Яндекса, Гугла и других сервисов. Сервисы хранят пароли в зашифрованном виде, поэтому даже при всём желании не смогли бы его передать.

Можно ли этому доверять?

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

⚠️ Во всех важных сервисах включайте двухфакторную авторизацию: чтобы не только вводить пароль, но и получать СМС.

⚠️ Если сервис поддерживает приложение-аутентификатор — используйте его. Например, в Яндексе есть «Ключ», а в Гугле — Authenticator. Это специальные приложения, которые создают дополнительный слой защиты поверх вашего логина и пароля.

⚠️ Если вы только что пользовались сервисами Яндекса или Гугла и тут вас просят вновь ввести логин и пароль — закройте эту страницу. Яндекс и Гугл помнят вас и не попросят пароль лишний раз.

Источник

Уязвимости в OAuth. Глава из книги «Ловушка для багов. Полевое руководство по веб-хакингу»

Содержание статьи

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

На момент написа­ния у OAuth есть две вер­сии, 1.0a и 2.0, которые несов­мести­мы друг с дру­гом. По OAuth написа­ны целые кни­ги, но эта гла­ва фокуси­рует­ся на OAuth 2.0 и базовом рабочем про­цес­се OAuth.

О книге

Пе­ред тобой — 17-я гла­ва из кни­ги «Ловуш­ка для багов. Полевое руководс­тво по веб‑хакин­гу», которую мы пуб­лику­ем с раз­решения изда­тель­ства «Питер».

Эта кни­га поможет в совер­шенс­тво­вании скил­лов работы с вебом и рас­ска­зыва­ет о методо­логии этич­ного веб‑хакин­га. Чита­ется она отлично, слов­но детек­тивный рас­сказ. Каж­дая опи­сыва­емая уяз­вимость име­ет парамет­ры: слож­ность, ата­кован­ный URL, URL стра­ницы, где хакер опи­сал про­веден­ную ата­ку, дата подачи отче­та и сум­ма вып­лачен­ного хакеру воз­награж­дения. Сре­ди про­чего есть опи­сание удач­ного взло­ма PornHub.com.

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

Для самых зеленых хакеров в кни­ге есть гла­ва, в которой целиком опи­сыва­ется опе­рация про­веде­ния взло­ма веб‑ресур­са, разоб­ран каж­дый этап, сре­ди которых: раз­ведка перед ата­кой, сос­тавле­ние спис­ка под­доменов, ска­ниро­вание пор­тов, обна­руже­ние содер­жимого, опре­деле­ние сте­ка тех­нологий и про­чее.

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

Принцип работы OAuth

В про­цес­се аутен­тифика­ции на осно­ве OAuth учас­тву­ют три сто­роны:

В ответ на этот HTTP-зап­рос кли­ент перенап­равля­ет вас к сер­веру ресур­са, исполь­зуя код 302. URL-адрес стра­ницы перенап­равле­ния содер­жит сле­дующие парамет­ры, учас­тву­ющие в про­цес­се аутен­тифика­ции:

URL-адрес, ини­циирующий про­цеду­ру OAuth с помощью Facebook, выг­лядит при­мер­но так:

По­лучив ответ с кодом перенап­равле­ния 302, бра­узер отправ­ляет сер­веру ресур­са GET-зап­рос. Вой­дя на сер­вер ресур­са, вы уви­дите диало­говое окно, с помощью которо­го мож­но одоб­рить области видимос­ти, зап­рашива­емые кли­ентом. На рис. 17.2 показа­но, как веб‑сайт Quora (кли­ент) зап­рашива­ет дос­туп к информа­ции у Facebook (сер­вера ресур­са) от име­ни вла­дель­ца ресур­са.

На­жатие кноп­ки Continue as John (Про­дол­жить как Джон) при­водит к одоб­рению зап­роса сай­та Quora на получе­ние дос­тупа к перечис­ленным областям видимос­ти, вклю­чая про­филь, спи­сок поль­зовате­лей, дату рож­дения, род­ной город вла­дель­ца ресур­са и про­чие све­дения. Ког­да вла­делец наж­мет кноп­ку, Facebook вер­нет HTTP-ответ с кодом 302, который перенап­равит бра­узер обратно к стра­нице с URL-адре­сом, ука­зан­ным в парамет­ре redirect_uri. Этот адрес так­же содер­жит токен и параметр state. Адрес перенап­равле­ния из Facebook в Quora может выг­лядеть так (изме­нено в целях демонс­тра­ции):

Сер­вер Facebook вер­нул токен access_token, с помощью которо­го кли­ент Quora мог сра­зу же получить дос­туп к информа­ции о вла­дель­це ресур­са. На этом учас­тие вла­дель­ца в про­цеду­ре OAuth завер­шено. Теперь кли­ент может нап­рямую обра­щать­ся к Facebook API за нуж­ной ему поль­зователь­ской информа­цией.

Вла­делец смо­жет даль­ше исполь­зовать кли­ент, не зная о его вза­имо­дей­ствии с API-интерфей­сом.

Рис. 17.2. Вход в Quora через Facebook с авто­риза­цией областей видимос­ти

То, нас­коль­ко серь­езной явля­ется уяз­вимость в OAuth, зависит от одоб­ренных областей видимос­ти, свя­зан­ных с токеном. В этом вы сами убе­дитесь на сле­дующих при­мерах.

Похищение OAuth-токенов на сайте Slack

Что­бы этим вос­поль­зовать­ся, зло­умыш­ленни­ку было дос­таточ­но соз­дать под­ходящий под­домен на сво­ем вре­донос­ном сай­те. Если жер­тва откры­вала заражен­ный URL-адрес, сер­вер Slack переда­вал OAuth-токен сай­ту зло­умыш­ленни­ка. Хакер мог ини­цииро­вать зап­рос от име­ни жер­твы, встро­ив во вре­донос­ную веб‑стра­ницу тег img> вро­де такого:

Это поз­волило бы авто­мати­чес­ки сде­лать HTTP-зап­рос типа GET при отоб­ражении стра­ницы.

Выводы

Прохождение аутентификации с паролем по умолчанию

По­иск уяз­вимос­тей в любой реали­зации OAuth под­разуме­вает иссле­дова­ние всей про­цеду­ры аутен­тифика­ции, от начала и до кон­ца. Для это­го в том чис­ле необ­ходимо рас­познать HTTP-зап­росы, которые не явля­ются частью стан­дар­тно­го про­цес­са; их наличие час­то сиг­нализи­рует о том, что раз­работ­чик изме­нил механизм аутен­тифика­ции и, воз­можно, сде­лал его уяз­вимым. Джек Кей­бл стол­кнул­ся с подоб­ной ситу­ацией в работе с прог­раммой Bug Bounty от Yahoo, в которую вхо­дил ана­лити­чес­кий сайт Flurry.com.

Что­бы начать тес­тирова­ние, Кей­бл зарегис­три­ровал учет­ную запись на сай­те Flurry, исполь­зуя свой адрес элек­трон­ной поч­ты @yahoo. com и реали­зацию OAuth от Yahoo. Пос­ле того как Flurry и Yahoo сог­ласова­ли OAuth-токен, зак­лючитель­ный POST-зап­рос к сай­ту Flurry выг­лядел так:

Источник