Доверенный redirect uri vk что это
Доверенный redirect uri vk что это
Для приложений на 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 будет передана информация об этой ошибке.
Вход на сайт через Вконтакте
Многие соцсети позволяют создавать приложения и через API получать данные пользователей, поэтому их использует для быстрой регистрации и авторизации на сайтах. Как проходит аутентификация, рассмотрим на примере VK:
Регистрация приложения
Для начала нужно создать приложение на странице https://vk.com/editapp?act=create
В меню «Платформа» нужно указать – сайт, заполнить поля «адрес сайта» и «основной домен».
В настройках видим ID приложения и защищённый ключ, также нужно убедится что приложение включено и видно всем.
Ссылка для входа
Сформируем и выведем ссылку по которой пользователь даст разрешение на запрошенные действия.
В redirect_uri указываем скрипт-обработчик, туда придет секретный код.
В параметре state можно передать URL текущей страницы, чтобы вернуть пользователя обратно.
При переходе по ссылке откроется страница:
Получение данных
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
Django allauth авторизация через социальную сеть
17 октября 2017 г. 6:04
Django-allauth замечательный пакет для авторизации пользователей на своём сайте, который берёт на себя рутинные операции по регистрации пользователей обычным способом через форму, а также через популярные социальные сети.
Не сложно и самому написать код авторизации для каждой соц. сети, используя их соответствующую документацию. Но мой вам совет, используйте готовую библиотеку для авторизации, например, рассматриваемую в этой статье Django-allauth, и настройте её под свои нужды. Потому что готовые решения, как правило, берут на себя всю рутину по регистрации, входу на сайт и добавление нескольких учётных записей разных социальных приложений в один аккаунт.
На данный момент приложение поддерживает более 60 соц. сетей (провайдеров).
Хорошо, что Django-allauth предоставляет возможность добавлять несколько email-ов пользователей и указывать основной. Бывает, что пользователь вдруг теряет контроль над одной какой-нибудь своей электронной почтой и тут приходят на помощь резервные email-ы, на которые могут прийти пароли или важные письма с вашего сайта.
Список всех преимуществ вы найдёте в официальной документации http://django-allauth.readthedocs.io/en/latest/index.html
Доверенный redirect URI
Во многих соц. сетях при добавлении приложения спрашивают про некий Доверенный redirect URI (или Действительные URL-адреса для перенаправления OAuth ) например в ВК:
Доверенный redirect URI нужен для дополнительной защиты приложения от утечек токенов зарегистрировавшихся пользователей в следствие хакерских атак.
В django-allauth Доверенный redirect URI строится по следующему принципу:
Дополнительная информация по использованию django-allauth для конкретных социальных приложений:
Простейший пример использования django-allauth
Устанавливаем и настраиваем django-allauth согласно документации http://django-allauth.readthedocs.io/en/latest/installation.html. Попробуем добавить авторизацию через ВКонтакте. Для начала нужно зарегистрировать своё приложение в VK.
Для вывода всех подключённых провайдеров, вы можете использовать следующий код:
И наконец, нужно связать полученные при регистрации приложения client_ID и секретный ключ с сайтом. Для этого в админке перейдите в Социальные приложения и добавьте социальное приложение:
Часто используемые настройки django-alluath
На всех сайтах я использую авторизацию через email и пароль, но в то же время без необходимости заполнять логин, поэтому я использую следующие настройки:
Количество попыток входа в систему я оставляю по умолчанию (равное 5), но время таймаута ограничиваю до 60 секунд:
Часто требуются дополнительные поля при регистрации пользователей, поэтому я создаю дополнительную форму:
А затем подключаю её в settings.py:
Теперь при выводе формы в шаблоне, мы увидим не только базовые поля (email и пароль), но и свои дополнительные поля. Получить такую форму в коде можно так:
Не всегда социальные сети дают информацию, которую необходимо сохранить на своём сайте, например, дата рождения или пол. Поэтому после регистрации пользователя через соц. сеть, нужно отправлять его на страницу с формой, содержащей дополнительные поля для сохранения. За это отвечает:
Ошибка resp.json()[‘response’][0] KeyError: ‘response’ для VK провайдера
1-ый вариант решения: обновить allauth до версии 0.36.0
В allauth версии 0.36.0 этот параметр добавили, поэтому обновите allauth до указанной версии и всё должно заработать.
2-ой вариант решения: переопределить VK провайдер
Доверенный redirect uri vk что это
Почему бы просто не указать «/blank.html»? А в зависимости того использую я api.vk.com или api.vkontakte.ru делать редирект?
Проблему решил указанием api.vkontakte.ru в качестве домена в настройках приложения. Почему об этом не написано в документации?
«Если Вы разрабатываете браузерное Javascript-приложение, то можно указывать любую ссылку в рамках домена, указанного в настройках приложения. Во всех остальных случаях в качестве redirect_uri нужно использовать адрес http://api.vkontakte.ru/blank.html. «
Тут не написано, что нужно в настройках приложения указать домен «api.vkontakte.ru».
Поправьте либо документацию, либо реализацию. Спасибо.
И ещё вопрос: почему не используется протокол https для страницы авторизации? Это потенциальная угроза, если я использую незащищённое WiFi соединение.
#123 Без HTTPS авторизация работает
Причем пару дней назад все ОК было.
Но это явно косяк т.к. по документации этого не нужно делать.
Блин, надеялся новое АПИ будет по-проще и по-производительнее предыдущего, а оказалось наоборот + куча косяков в довесок!
1)Не могу пройти повторно авторизацию.В ответ приходит ошибка ни с чем не связанная!
2)Вчера получилось 2 разы авторизироваться, но в обоих случаях возвращаемый параметр expire всегда равный нулю!Как это понимать??
3)Как «сочинять» запрос по, допустим, таким методам как audio.get, что бы получить ответ в xml??Или так и будет method/audio.get.xml??
4)Будет-ли добавлена возможность получать ответ в формате rss и atom??
#122 в старом апи также было. Судя по логике 0 = никогда не истекает. Что конкретно значит то, что сервер сам сбросит сессию когда надо будет
#139 работает довольно стабильно. Хотя у меня выборка маленькая.
ПС: давно хотел предложить перевести на HTTPS апи. А то даже полудохлый жабир и тот с сертификатом. Да и с подписыванием запросов та еще запара.