Зачем существует «дырявая» клиентская oAuth авторизация?
У большинства соц сетей и сервисов есть функция oAuth авторизации. Это такая авторизация, при которой пользователь вашего сайта авторизуется не через ваш сайт, а через свою учетную запись в какой-то социальной сети или в каком-то сервисе.
Чаще всего сервисы предлагают 2 варианта авторизации: серверный и клиентский.
Серверный работает так:
1. Пользователь перенаправляется на сайт соц сети и подтверждает, что хочет авторизоваться на вашем сайте.
2. Его перебрасывает на ваш сайт и в строке адреса передается специальный код.
3. Ваш сайт отправляет этот код вместе с секретным ключом в соц сеть и получает токен, который уже можно использовать для доступа к данным пользователя и тп.
Клиентский работает по-другому:
1. Пользователь перенаправляется на сайт соц сети и подтверждает, что хочет авторизоваться на вашем сайте.
2. Его перебрасывает на ваш сайт и в строке адреса передается готовый токен.
Зачем вообще существует второй вариант? Ведь любой узел (сисадмин, владелец точки wi-fi, провайдер, товарищ майор) может просто взять готовый токен и использовать его.
В сервисах, правда, обычно указывают, что такой способ небезопасен, но он нужен, например, для сайтов, у которых нет серверной части. Это правда, но почему для таких случаев не сделать, например так:
1. Подключаем js-библиотеку соц сети, которая открывает нашем сайте диалоговое окно.
2. Пользователь должен уже быть авторизован в соц сети в соседней вкладке (если проводить авторизацию через это диалоговое окно, то мы как владельцы сайта, можем подделать это окно и перехватывать данные пользователя).
3. Пользователь в диалоговом окне одобряет авторизацию и получает токен. Все это происходит через аякс поверх https и не может быть перехвачено.
Возможно мой вариант не работает, это то что пришло в голову по ходу написания вопроса. Но должен же быть какой-нибудь безопасный способ?
Ведь любой узел (сисадмин, владелец точки wi-fi, провайдер, товарищ майор) может просто взять готовый токен и использовать его.
диссонанс
Все это происходит через аякс поверх https и не может быть перехвачено.
Если ваш сервис не работает чере https то ни о какой защите говорить не приходится, для защиты придется фактически дублировать функционал шифрования https через http, если же есть https то без доступа к локальной базе доверенных сертификатов или злонамеренного локального приложения с администраторскими правами (например антивирусник или браузера от злоумышленника 'майора') то смело передавайте токены авторизации.
rPman, шифрование трафика ведь работает только для данных, которые передаются внутри запроса (заголовки, тело запроса), а на данные, которые передаются в строке браузера это не распространяется. Кроме того, у всех сервисов в требовании есть использование SSL.
Исключение - домен, если у вас используется нешифрованные dns сервера то при первом заходе (на самом деле там с интервалом из настроек домена, остальное время данные кешируются) компьютер делает запрос dns, обычно это сервера провайдеров (некоторые особо гнусные подменяют вызовы публичных типа 8.8.8.8 на свои).
Т.е. ваш провайдер/админ wifi сети знает на какой ip адрес вы зашли, с некоторыми и какой сайт (на одном ip их может быть сколько угодно), и максимум знает сколько байт вы отправили серверу и сколько вам ответили (и то это после упаковки). При очень сильном красноглазии, некоторые запросы можно анализировать статистически (например если вы заходите на определенный сайт то будете загружать определенные файлы в определенном порядке, т.е. можно делать предположение, на какой именно сайт и каких страницах вы ходите, статистически и с малым шансом угадать)
Если кто то 'по середине' пожелает подменить запросы, в браузере выскакивает соответствующее предупреждение о недостоверности сертификата (либо шифрование не будет, например вы зашли на сайт не указав https, многие ставят сразу редирект на шифрование, а злоумышленник может этого не делать и сайт останется в http зоне)
>>Зачем вообще существует второй вариант? Ведь любой узел (сисадмин, владелец точки wi-fi, провайдер, товарищ майор) может просто взять готовый токен и использовать его.
Данные передаётся по HTTPS! Следовательно токен не доступен промежуточным узлам, так как информация зашифрована.
Если рассматривать авторизацию через ВКонтакте токен известен толкьо: 1) ВКонтакте, 2) Сайту на который производится авторизация, 3) самому пользователю осуществляющему авторизацию
Все промежуточные провайдеры знают только что клиент по факту соединяется с некоторым IP адресом при использовании HTTPS протокола, и они не знают на какой url осуществляется запрос.
то мы как владельцы сайта, можем подделать это окно и перехватывать данные пользователя
В случае с серверной авторизацией - мы как владельцы сайта тоже получаем этот токен и можем как угодно использовать его пользователю во вред.
При авторизации нашего приложения в соцсети пользователю выдаётся список информации, к которому наше приложение будет иметь доступ, и пользователь должен быть готов к тому, что нечистые на руку владельцы сайта могут эти данные тайно собирать и использовать в плохих целях.
WebDev, диалоговое окно подделать(применить фишинг атаку) можно вообще не имея скриптов авторизации по oAuth на сайте, достаточно лишь ввести в заблуждение пользователя что таковые у Вас имеются.
HemulGM, двухфакторная аутентификация против этого не поможет, если провернуть примерно такую схему:
1) Сервер злоумышленника показывает поддельное окно логина соцсети.
2) Жертва вводит логин-пароль, сервер злоумышленника притворяется браузером и авторизуется в соцсети под введёнными данными, получает запрос на 2FA
3) Сервер злоумышленника показывает окно ввода кода 2FA (либо TOTP, либо отправленный на SMS), жертва его вводит.
4) Сервер злоумышленника, притворяясь всё тем же браузером и сохраняя те же куки, что он получал на шаге 2, проходит 2FA с введённым кодом, а потом гадит пользователю (шлёт спам от его аккаунта), отвлекая пользователя окошками вроде "сервер перегружен, повторите попытку через 15 минут", дабы тот не сразу сообразил
Простой
