Redirect uri что это

Redirect uri что это

Для приложений на iOS, Android, Windows Phone мы рекомендуем использовать упрощенную схему авторизации через SDK.

Необходимо перенаправить браузер пользователя по адресу
https://oauth.vk.com/authorize, передав следующие параметры:

Redirect_uri — это URL, на который будет переадресован браузер пользователя после разрешения им прав доступа.

Если Вы разрабатываете веб-приложение и хотите работать с API из Javascript, в redirect_uri необходимо указать адрес страницы на Вашем сайте. В целях безопасности, этот адрес также должен быть указан в настройках Вашего приложения (поля «Адрес сайта», «Базовый домен» и «Доверенный Redirect URI»).

Обратите внимание, Вы не сможете работать с методами, которые помечены как доступные только для Standalone-приложений.

Во всех остальных случаях (мобильное, десктопное приложение) необходимо использовать redirect_uri по умолчанию: https://oauth.vk.com/blank.html

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

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

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

Обратите внимание, что некоторые права могут быть запрошены только Standalone-приложением (например, право доступа messages). Это автоматически означает необходимость использования redirect_uri по умолчанию (см. redirect_uri).

После успешной авторизации приложения браузер пользователя будет перенаправлен по адресу redirect_uri, указанному при открытии диалога авторизации. При этом ключ доступа к API access_token и другие параметры будут переданы в URL-фрагменте ссылки:

Вместе с ключом access_token также будет указано время его жизни expires_in, заданное в секундах. expires_in содержит 0, если токен бессрочный (при использовании scope = offline). Если срок использования ключа истек, то необходимо повторно провести все описанные выше шаги, но в этом случае пользователю уже не придется дважды разрешать доступ. Запрашивать access_token также необходимо при смене пользователем логина или пароля или удалением приложения в настройках доступа.

Кроме того, среди возвращаемых параметров будет указан user_id — идентификатор авторизовавшегося пользователя.

В случае возникновения ошибки авторизации в качестве GET-параметров в redirect_uri будет передана информация об этой ошибке.

Источник

Безопасность OAuth2

Данная блогозапись на хабр прежде всего обусловлена появлением «Ключницы» — хороший повод связать и перевести накопленное.

У нас в программе: вольный пересказ спек OAuth2, слабые стороны и Threat Model, 0day на хабретрюк с аутенфикацией.

OAuth2 это просто

Длинный, но правильный путь изучить его.
Для ленивых я опишу своими словами Authorization Code Flow как самый распространенный и безопасный, aka Server-Side.

Ключевые понятия — Клиент(website/online game/app), Юзер(you), Провайдер(facebook/vkontakte/google), Код(code) и Токен(access_token).

Клиент посылает Юзера — «авторизуй меня для доступа к твоим ресурсам». Юзер идет по ссылке к провайдеру, смотрит что от него требуют — scope параметр — жмет Разрешить. Далее Провайдер редиректит его назад на указанный redirect_uri на домене Клиента со следующими параметрами:
code — идентификатор Юзера у Провайдера, который нужен Клиенту чтобы получить Токен
state — то же значение что было передано на начальный URL. используется для защиты от CSRF и для удобства.

Код из себя не представляет никакой ценности для Юзера(и User-Agent соответственно) т.к. с его помощью нельзя совершать запросы API и нужен он лишь для одной цели — получения Токена.
Для получения Токена Клиент производит запрос на определенный эндпоинт, передав client_id, client_secret, code, redirect_uri по которому был получен код — таким образом Провайдер уверен что это нужный Клиент и по Коду он отдает Токен того самого Юзера. Как видите ни Юзер, ни User-Agent и клиентские скрипты не увидили настоящий Токен. Его знают только Клиент и Провайдер — в идеале.

Дальше Токен используют для совершения API запросов, впоследствии его можно рефрешить (для этого вместе с Токеном возвращается refresh_token).

Threat Model или Я Знаю О Чем Вы Подумали

1. А что если я подставлю такой redirect_uri который будет вести на свой сайт а потом использую этот Код сам для аутенфикации?

Все redirect_uri должны находится на домене Клиента. Часто разрешен еще домен Провайдера. Ваша ссылка вернет redirect_uri_mismatch.

2. ОК а что если я найду такое место на сайте Клиента, которое сольет мне Код? Может открытый редирект вида site.com?url=http://outsite.com или hot-linked картинку которая сольет реферер?

Каждый Код привязан к тому redirect_uri для которого он был выпущен и для получения Токена Клиент передает «правильный» redirect_uri. Если ваш Код был выпущен для clientsite.com/leak_referer а Клиент при получении Токена отошлет clientsite.com/facebook_callback то Провайдер не отдаст Токен.

3. А можно ли как то слить Код передав правильный redirect_uri?

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

4. Допустим у меня есть Код для моего аккаунта в соц сети выпущенный для правильного redirect_uri. Что будет если я заставлю посетить эту ссылку Васю?

В таком случае сайт Клиента подумает что ваш аккаунт в соц сети принадлежит Васе. И присоеденит его. Чтобы типичного CSRF не происходило Клиент обязан сохранять рандомное значение state в сессии/куке и проверять по возврату на колбэк на соответствие. Хотя, так почти никто не делает (точнее не делали).

Реальность

FB Reply Attack

Hijacking Account

Самая частая уязвимость, присутствует например на хабре — об этом ниже. Нарушается пункт 4.
Если вы видите в запросе state не спешите сдаваться. Что хабр, что digg.com не видели разницы между a12b6467c3fb385e237109502277ab26 и heyman0day123123

VK redirect_uri

Если вы используете Implicit Flow — т.е. получаете access_token от юзера напрямую, то нет никаких гарантий что этот токен принадлежит текущему юзеру. Он мог его просто украсть через вредоносного Клиента, и использовать чтобы попасть в аккаунт какого-то юзера на вашем сайте.
Обязательно проверяйте, был ли выпущен данный токен для вашего client_id.

Так же OAuth2 не дает никаких гарантий что пользователь дал вам те разрешения что вы запросили на этапе авторизации в параметре scope. Он мог просто удалить их — в итоге вы должны на колбэке проверить разрешил ли он что вы запросили.

Если на сайте найдена XSS то есть легкий способ украсть кучу access_token-ов. Возьмите authorize URL который сайт использует для facebook и замените response_type=code на token. Осталось вставить этот URL во фрейм, дождаться возврата токена в ссылке вида callback#access_token=123, срезать токен и слить его. Спамьте на здоровье!

0day на хабре?

Тот же эксплоит работает и для facebook/google только сложнее получить redirect_uri с кодом без использования его — нужен NoRedirect+FF
Поэтому демо на VK. дяденька не бань UPD: уязвимость исправили.

1. У вас не должно быть привязанного VK. Авторизуйтесь oauth.vk.com/authorize?response_type=code&client_id=3110645&redirect_uri=http%3A%2F%2Fhabrahabr.ru&scope=offline&display=page
2. Вас вернуло на habrahabr.ru/?code=CODE
3. Заставьте другого хабраюзера посетить habrahabr.ru/social/callback/vkontakte/?code=CODE&state=whogivesafuckaboutstate можно подкинуть саму ссылку, но лучше спрятать в img или iframe и тд. Если он залогинен на хабре ваш ВК привяжен к его хабрааккаунту.
4. Логинимся через ваш ВК в его хабрааккаунт, меняем его аватар на nayncat.

Мораль

Вконтакте: перестаньте игнорировать письма в Поддержку, либо попросите ваших разработчиков снизойти поговорить с простым смертным. А еще введите bounty program (sarcasm: есть риск разориться на ней).
Хабр: рекомендую выключить Ключницу на время и пофиксить уязвимость путем правильной проверки ‘state’ со значением из cookie/session.

Road to Hell короче. Вы можете присоедениться к разработке принципиально нового стандарта с нескучными токенами — OAuth2.a (Charm — Provider). Печенек, правда, нет.

Egor Homakov (@homakov) & isciurus #RT pls

Источник

Ограничения для URI перенаправления (URL-адресов ответа)

URI перенаправления, или URL-адрес ответа, — это расположение, в которое сервер авторизации будет отправлять пользователя после успешной авторизации приложения и которому был предоставлен код авторизации или маркер доступа. Сервер авторизации отправляет на URI перенаправления код или маркер ответа, поэтому в процессе регистрации приложения важно зарегистрировать правильный адрес.

Модель приложения Azure Active Directory (Azure AD) определяет следующие ограничения для URI перенаправления:

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

Максимальное число URI перенаправления

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

Максимальная длина URI

Длина каждого URI перенаправления, добавляемого для зарегистрированного приложения, должна составлять не более 256 символов.

Перенаправление URI в главных объектах приложений и субъектов-служб

Поддерживаемые схемы

HTTPS: схема HTTPS ( https:// ) поддерживается для всех URI перенаправления на базе протокола HTTP.

HTTP: схема HTTP ( http:// ) поддерживается только для URI перенаправления localhost и используется исключительно на этапах локальной разработки и тестирования приложения.

Исключения для localhost

В соответствии с разделами RFC 8252 8.3 и 7.3, для URI перенаправления с замыканием на себя (localhost) действуют два особых правила:

С точки зрения разработки это означает несколько моментов:

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

IPv6-адрес замыкания на себя ( [::1] ) в настоящее время не поддерживается.

Выбор 127.0.0.1 вместо localhost

При этом текстовое поле URI перенаправления на портал Azure нельзя использовать для добавления URI замыкания на себя со схемой http :

Ограничения на подстановочные знаки в URI перенаправления

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

Чтобы добавить URI перенаправления с подстановочными знаками для зарегистрированных приложений, которые входят в рабочие или учебные учетные записи, используйте редактор манифеста приложения в разделе Регистрация приложений на портале Azure. Хотя с помощью редактора манифеста действительно можно задать URI перенаправления с подстановочными знаками, мы настоятельно рекомендуем придерживаться требований раздела 3.1.2 RFC 6749 и использовать только абсолютные URI.

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

Использование параметра состояния

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

Если вы используете этот подход:

Такой подход позволяет скомпрометированному клиенту изменять дополнительные параметры, отправляемые в параметре состояния, поэтому пользователь перенаправляется на другой URL-адрес, что является угрозой открытого перенаправления, как описано в стандарте RFC 6819. Таким образом, клиент должен защищать эти параметры, шифруя состояние или проверяя его с помощью других средств, таких как проверка доменного имени в URI перенаправления по маркеру.

Источник

Перенаправления в HTTP

URL перенаправление (redirecting), также известное как URL пересылка (forwarding), это метод представления страницы, формы или целого веб-приложения, более чем одним URL адресом. HTTP предоставляет специальный вид ответов, HTTP redirect, для выполнения этой операции, используемой для многих целей: временного перенаправления, пока выполняется обслуживание сайта, постоянное перенаправление, для сохранения работоспособности внешних ссылок, после смены архитектуры сайта, страниц прогресса, пока загружается файл, и так далее.

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

Есть несколько типов перенаправлений и делятся на три категории: постоянные, временные и специальные перенаправления.

Постоянные перенаправления

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

[1] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 308 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.

Временные перенаправления

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

[2] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 307 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.

Специальные перенаправления

В добавок к обычным перенаправлениям, есть 2 специальные. Перенаправление с кодом 304 (Not Modified) перенаправляет страницу к локальной закешированной копии (которая была устаревшей), и перенаправление с кодом 300 (Multiple Choice) это ручное перенаправление: тело, представленное браузером, как веб-страница, перечисляет возможные перенаправления и пользователь выбирает одно из них.

Альтернативные способы указания перенаправлений

HTML перенаправления

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

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

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

JavaScript перенаправления

Перенаправления в JavaScript создаются установкой значения свойства window.location и новая страница загрузиться.

Как и HTML перенаправления, этот тип не будет работать на всех ресурсах, и очевидно, что работает только на стороне клиента, который выполнит JavaScript. С другой стороны, вы можете вызвать перенаправление, только тогда, когда исполнится определённое условие.

Приоритетность

При использовании трёх возможных способов URL перенаправления, некоторые методы могут быть вызваны одновременно, но какой из них будет примёнён первым? Порядок приоритетов следующий:

Случаи использования

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

Связывание доменов

В идеале, есть только одно место, и следовательно один URL адрес, для одного ресурса. Но, есть несколько причин, чтобы иметь альтернативные имена для ресурса (несколько доменов, как с, так и без префикса www или более короткие и лёгкие для запоминания адреса, …). В этих случаях, использовать перенаправление к одному истинному URL адресу, более подходящий вариант, чем дублировать ресурс.

Связывание доменов может быть необходимым по нескольким причинам:

Сохранения ссылок рабочими

Когда вы изменяете структуру веб-сайта, URL адреса ресурсов меняются. Даже, если вы можете обновить внутренние ссылки вашего сайта в соответствии с новой схемой имён, у вас нет контроля на URL адресами используемыми внешними ресурсами. Вы не хотите, чтобы эти ссылки не работали, так как они приносят вам ценных пользователей (и помогают вашей SEO), так что вы устанавливаете перенаправления из старых URL адресов на новые.

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

Временные ответы для небезопасных запросов

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

Временные ответы на долгие запросы

Настройка перенаправлений на распространённых серверах

Apache

У модуля mod_alias есть директивы Redirect и Redirect_Match которые, по умолчанию, устанавливают код ответа 302 :

URL http://example.com/ будет перенаправлен к http://www.example.com/ (но не к http://example.com/other.html )

Redirect_Match делает то же, но использует регулярное выражение, чтобы определить множество URL адресов, которые подпадут под эффект:

Все документы в папке images/ будут перенаправляться к другому домену.

Если вы не хотите устанавливать временное перенаправление, дополнительный параметр (используйте или код статуса HTTP, или ключевое слово permanent) может использоваться чтобы установить другое перенаправление:

Также модуль mod_rewrite может использоваться для создания перенаправлений. Они более гибкие, но сложнее в использовании.

Nginx

В Nginx, вы создаёте особый серверный блок для контента, который вы хотите перенаправлять:

Чтобы применить перенаправления к папке или подмножеству страниц, используйте директиву rewrite :

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

Циклы перенаправлений

Циклы перенаправлений случаются когда за успешным перенаправлением следует другое, которое уже было выполнено. Другими словами, существует такой цикл, который никогда не закончится и в конечном счёте ни одна страница не будет найдена.

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

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

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

Источник

Redirect URI (reply URL) restrictions and limitations

A redirect URI, or reply URL, is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it’s important you register the correct location as part of the app registration process.

The Azure Active Directory (Azure AD) application model specifies these restrictions to redirect URIs:

Redirect URIs that contain a path segment are not appended with a trailing slash in the response.

Maximum number of redirect URIs

This table shows the maximum number of redirect URIs you can add to an app registration in the Microsoft identity platform.

Maximum URI length

You can use a maximum of 256 characters for each redirect URI you add to an app registration.

Redirect URIs in application vs. service principal objects

Supported schemes

HTTPS: The HTTPS scheme ( https:// ) is supported for all HTTP-based redirect URIs.

HTTP: The HTTP scheme ( http:// ) is supported only for localhost URIs and should be used only during active local application development and testing.

Localhost exceptions

Per RFC 8252 sections 8.3 and 7.3, «loopback» or «localhost» redirect URIs come with two special considerations:

From a development standpoint, this means a few things:

This is especially important when you want to use different authentication flows in the same application registration, for example both the authorization code grant and implicit flow. To associate the correct response behavior with each redirect URI, the login server must be able to distinguish between the redirect URIs and cannot do so when only the port differs.

The IPv6 loopback address ( [::1] ) is not currently supported.

Prefer 127.0.0.1 over localhost

You cannot, however, use the Redirect URIs text box in the Azure portal to add a loopback-based redirect URI that uses the http scheme:

To add a redirect URI that uses the http scheme with the 127.0.0.1 loopback address, you must currently modify the replyUrlsWithType attribute in the application manifest.

Restrictions on wildcards in redirect URIs

Wildcard URIs like https://*.contoso.com may seem convenient, but should be avoided due to security implications. According to the OAuth 2.0 specification (section 3.1.2 of RFC 6749), a redirection endpoint URI must be an absolute URI.

Wildcard URIs are currently unsupported in app registrations configured to sign in personal Microsoft accounts and work or school accounts. Wildcard URIs are allowed, however, for apps that are configured to sign in only work or school accounts in an organization’s Azure AD tenant.

To add redirect URIs with wildcards to app registrations that sign in work or school accounts, use the application manifest editor in App registrations in the Azure portal. Though it’s possible to set a redirect URI with a wildcard by using the manifest editor, we strongly recommend you adhere to section 3.1.2 of RFC 6749. and use only absolute URIs.

If your scenario requires more redirect URIs than the maximum limit allowed, consider the following state parameter approach instead of adding a wildcard redirect URI.

Use a state parameter

If you have several subdomains and your scenario requires that, upon successful authentication, you redirect users to the same page from which they started, using a state parameter might be helpful.

This approach allows a compromised client to modify the additional parameters sent in the state parameter, thereby redirecting the user to a different URL, which is the open redirector threat described in RFC 6819. Therefore, the client must protect these parameters by encrypting the state or verifying it by some other means, like validating the domain name in the redirect URI against the token.

Next steps

Learn about the app registration Application manifest.

Источник