Мы привыкли доверять приложениям, которые установили на свои гаджеты. Порой обоснованно, порой не очень. Если посмотреть документацию на API авторизации какого-нибудь крупного российского банка или соцсети, то можно увидеть Oauth 2.0, OIDC, authorization code flow и т.д. К сожалению, в большинстве случаев это либо не соответствует действительности вообще, либо частично. Как будто за всеми этим упускается один важный момент, и сегодня мы поговорим об этом более подробно.
Смотрим примеры
Пару лет назад я начал активно интересоваться вопросами авторизации и аутентификации – кроме изучения соответствующих опенсорсных решений, таких как keycloak, я присоединился к сообществу spring security и начал активно вносить свой вклад в развитие фрэймворка – мои активности можно посмотреть в аккаунте на github, там как мелкие доработки, так и полноценные core-фичи. По мере накопления опыта мой скептицизм в отношении безопасности некоторых приложений, установленных на моем iphone 12, только увеличивался. На самом деле все не совсем так – я пришел к выводу, что подавляющее большинство мобильных приложений в моем телефоне не очень-то и безопасны в плане авторизации. Давайте рассмотрим пару примеров. Вот с чего начинается процесс авторизации и аутентификации в приложении одного крупного банка (не вижу смысла скрывать его название):
После ввода номера телефона приходит смс с кодом, который также надо ввести. Это первый фактор. Второй фактор можно пройти по номеру карты и паролю:
А вот так выглядит первый экран авторизации в одной известной отечественной соцсети:
В общем-то точно такое же начало, как и в предыдущем случаем. Для сравнения давайте посмотрим с чего начинается авторизация во всеми нам известном сервисе от компании Google:
Как минимум у нас появилась кнопка «Войти». Уже лучше, давайте нажмем эту кнопку.
Youtube честно нас предупреждает, что для входа в приложение будет использован google.com. Хорошо, продолжим.
Если присмотреться внимательно, то это ни что иное, как браузерное окно – вверху виден адрес открывшейся страницы.
Посмотрим еще один пример авторизации от Microsoft:
Кнопка есть, как и в предыдущем варианте. Далее:
Уже знакомое нам предупреждение. Продолжаем:
Я думаю, что дальше нет смысла продолжать.
Разбор
Видно, что первые два варианта авторизации сильно отличаются от youtube и github по своей природе. Скорее всего большинство пользователей (и опытные it-инженеры, в том числе специалисты по безопасности) не увидят тут какого-либо подвоха и спокойно будут вводить свои авторизационные данные что в приложение вк, что в youtube. Проблема в том, что у первых двух приложений есть один важный момент, связанный с упомянутым выше Ouath 2.0 – они фундаментально небезопасны, т.к. их авторизация противоречит основной идее Oauth 2.0. А точнее – не отдавать клиентскому приложению свои учетные данные (логин, пароль). Мы видим, что youtube так не делает, вы не вводите в нативных формах приложения логин, пароль, какие-либо коды из смс, и т.д., youtube открывает для вас отдельное браузерное окно, где мы видим сервер авторизации google, и вот ему вы уже честно отдаете свой логин, пароль и все, что он у вас попросит. Аналогичная ситуация у github. Оба этих варианта подразумевают, что есть некий сервер авторизации, которому вы доверяете, на нем вы проходили регистрацию, и приложение всегда предупреждает вас, что именно этот сервер сейчас запросит у вас учетные данные. Безопасно получить доступ к этому серверу можно только через браузер, который должен открыться отдельно от самого приложения. У того же google процесс авторизации внешне выглядит одинаково, при этом неважно, где бы вы авторизовывались – где-то в браузере на своем ПК или в мобильном приложении. Что касается первых двух приложений, то все, что требует протокол авторизации вводится исключительно в самом приложении (не в отдельно открытом браузере). И тут важно понимать почему это небезопасно.
Вот что написано в RFC:
Наверное, кто-то скажет, что это ведь не password grant как таковой, но по факту разницы нет. Это ровным счетом тоже самое, более правильно было бы написать не про конкретный grant, а про возможность ввода каких-либо авторизационных данных на клиенте в принципе.
Про потенциальные утечки пароля, трояны, перехватывающие otp и т.д. мы уже слышали много раз. Да, такое возможно, история знает много примеров, когда учетные данные куда-то утекали из клиентского приложения. В принципе, я верю, что такое сейчас случается нечасто и в этом плане современные мобильные приложения можно считать относительно безопасными. Что конечно же является большой натяжкой. Не нужно сбрасывать со счетов этот момент, но прежде всего стоит обратить внимание на кое-что другое – вы привыкаете вводить свой логин и пароль в приложение, в его интерфейс, а не в браузер. Никто вас не предупреждает, что ваше приложение хочет использовать какой-либо сервер для авторизации. Вы просто верите, что вы вводите пароль туда, куда надо. Наученные годами пользования youtube пользователи могут несколько раз подумать прежде, чем вводить свой пароль куда-то в другое место, где не выскакивает окно предупреждения и не открывается привычная страница google.com со знакомыми кнопками. А могут и не думать вовсе, т.к. в телефоне есть куча приложений, где такого нет, а значит можно вводить свой логин пароль как угодно и куда угодно.
Удивительно, что такой проблемой страдают, наверное, все отечественные банки, где процесс авторизации идет исключительно в мобильном приложении. И как бы странно это не звучало, но на вопрос «неужели крупный банк может подвергать опасности меня и мои финансы?» ответ – да, может. Если посмотреть с какой периодичностью в том же app store появляются откровенно мошеннические приложения, которые пользуются, тем фактом, что пользователь просто не привык видеть то, что он видит при авторизации в том же youtube. Например, раз, два, три. Это классическая атака «человек посередине».
Можно бесконечно предупреждать о фейковых приложениях в app store, пользователям от этого легче не станет, причины таких атак и, как следствие украденных учетных данных (и денег тоже) кроются в самих компаниях-разработчиках этих приложений – нужно предпринимать конкретные шаги для уменьшения вероятности атак, следуя рекомендациям rfc и хотя бы того же Oauth 2.0.
Подробно обсуждать ситуацию с телеграм я не буду. Всем и так известно, что количество угнанных аккаунтов исчисляется тысячами. Примерно по тем же самым причинам, что и в вышеописанных случаях. Последствия в общем-то тоже известны – многие истории настолько драматичны, что хочется искренне посочувствовать жертвам мошенников.
И что нам делать?
Увы, мы тут заложники ситуации. Пока в наших телефонах будут такие приложения мы будем вынуждены вводить свои учетные данных именно так, как они требуют. Неважно безопасно это или нет. Причин тому может быть много, я слышал разные объяснения – от классического «исторически так сложилось» до «бизнес требует». Наверное, в первую очередь тут стоит работать с разработчиками приложений и специалистами по it-безопасности, чтобы у них в головах появились новые категории и паттерны веб-секьюрити. Может ли решить все проблемы массовое внедрение настоящего Oauth 2.0 в мобильных приложениях. Я думаю, что нет, проблемы все равно останутся, но мы можем решить часть этих проблем и уменьшить поверхность атак и вариантов мошенничества, а это уже будет небольшой победой.
Вместо послесловия
Где-то год назад на форуме keycloak появился вопрос Programmatically registering & authenticating passkeys. Автор пытался понять есть ли у keycloak какой-либо REST API для авторизации через пасскеи (т.е. без пароля). На что получил весьма содержательный ответ от одного из основных разработчиков keycloak:
Тут добавить нечего…
Комментарии (30)
sshikov
02.01.2025 07:22Удивительно, что такой проблемой страдают, наверное, все отечественные банки, где процесс авторизации идет исключительно в мобильном приложении.
Погодите. С чего вы решили, что при входе в приложение банка я доверяю google.com, которому одновременно доверяет и банк? В приложение Сбер/Тиньков можно войти по кредам гугля? И давно ли?
В моем понимании, Сбер скажем использует Oauth не когда вы входите в Сбербанк Онлайн, а когда вы входите куда-то по СберID, т.е. именно сервис Сбера и является тем, кто аутентифицирует пользователя. Т.е. например, при входе по СберID в megamarket.ru, ну или там Купер и т.п. .
franticticktick Автор
02.01.2025 07:22Погодите. С чего вы решили, что при входе в приложение банка я доверяю google.com, которому одновременно доверяет и банк? В приложение Сбер/Тиньков можно войти по кредам гугля? И давно ли?
В статье речь шла не про вход по кредам гугла в приложениях сбера или тинька, а про то, что вход в них должен осуществляться через отдельное браузерное окно как и предполагает Oauth 2.0.
В моем понимании, Сбер скажем использует Oauth не когда вы входите в Сбербанк Онлайн, а когда вы входите куда-то по СберID, т.е. именно сервис Сбера и является тем, кто аутентифицирует пользователя.
Даже если это и правда, то так делать, как Сбер, категорически неверно. В rfc вполне четко прописан процесс авторизации для мобильных приложений, а если компания так, как написано в стандарте делать не хочет, то она не только подвергает своих пользователей лишней опасности, но и учит их доверять учетные данные своему приложению, а не серверу авторизации (тому же СберID или "Сбер Онлайн", неважно), что в общем-то прямо и сказано в спецификации. Отсюда и результат. Особенно интересно читать отзывы в app store от тысяч пользователей, которые установили себе эти приложения и чьи учетные данные угнали.
noavarice
02.01.2025 07:22@sshikov имеет в виду, что делегирование аутентификации/авторизации не нужно для first-party клиента - OAuth/OpenID придумали для third-party клиентов. Приложение VK это first-party клиент по отношению, поэтому там достаточно эндпойнта с логин-паролем (и 2FA), так что нет смысла делегировать аутентификацию самому себе. YouTube делегирует аутентификацию Гуглу, скорее всего, потому что это банально разные организации и домены. А github кмк просто какую-то фигню сделали
franticticktick Автор
02.01.2025 07:22@sshikov имеет в виду, что делегирование аутентификации/авторизации не нужно для first-party клиента - OAuth/OpenID придумали для third-party клиентов
Это неверное утверждение. First patry application - это приложение, созданное разработчиком самой платформы, например, предустановленные приложения для ios, разработчик которых apple. Для таких приложение есть особая авторизация, которая пока еще в драфте. В таких приложениях риски всегда ниже, поэтому стандартные процессы Oauth 2.0 во многом бессмысленны. Что сбер, что вк разработали не google и не apple, и они уж точно не предустановлены ни в одну из ОС.
noavarice
02.01.2025 07:22Я неверно выразился - на самом деле мобильное приложение ВК (если бы это был flow OAuth) было бы User Agent, а не клиентом. Клиент это сам сервер авторизации ВК, поэтому делегирование тут бессмысленно - сервер ВК не станет же просить доступа у себя самого
sshikov
02.01.2025 07:22Даже если это и правда, то так делать, как Сбер, категорически неверно.
Вы предлагаете отдельное окно, и считаете это критически важным? Ну ок, допустим - только я не улавливаю, почему пользователь, который не может отличить фейковое приложение банка от настоящего не перепутает точно так же фейковое окно браузера с настоящим?
P.S. По сути, вот ниже уже сформулировали мой вопрос иными словами:
если мы не доверяем приложению, то почему мы должны доверять контенту "браузерного окна", которое оно открывает?
Ну т.е. исходные данные для меня простые - я доверяю своему банку деньги. И я доверяю его приложению (хотя разумеется, допускаю, что там могут быть баги). И когда я ставлю это приложение, я убеждаюсь дважды, что оно настоящее. В противном же случая я не вижу разницы. Если вы видите - поясните, в чем она?
franticticktick Автор
02.01.2025 07:22Вы предлагаете отдельное окно, и считаете это критически важным?
Это не я предлагаю и считаю это критически важным, это предлагает rfc и ouath 2.0 в целом (и считает не просто критически важным, а основной идеей всего фрэймворка).
Ну т.е. исходные данные для меня простые - я доверяю своему банку деньги. И я доверяю его приложению (хотя разумеется, допускаю, что там могут быть баги). И когда я ставлю это приложение, я убеждаюсь дважды, что оно настоящее. В противном же случая я не вижу разницы. Если вы видите - поясните, в чем она?
К сожалению это то, к чему мы пришли на данный момент. С точки зрения rfc и oauth 2.0 в целом доверять нужно серверу авторизации, чью страницу для ввода логина и пароля мы видим в браузере. Точка. Можно с этим спорить, но это факт. На этой идее основаны современные мобильные sdk, так работает keycloak, и не просто так мэйнтейнеры того же keycloak нас предупреждают:
Secure authentication is always about doing the proper things on the secure server, aka Keycloak, with the use of the users browser. Please, do yourself and your users a favor and read and understand the specs, before implementing “something that just somehow” works.
Безопасная аутентификация всегда предполагает выполнение правильных действий на защищенном сервере, известном как Keycloak, с использованием браузера пользователя. Пожалуйста, сделайте себе и своим пользователям одолжение: прочитайте и поймите спецификации, прежде чем внедрять «что-то, что каким-то образом» работает.
Еще раз цитата из rfc:
The resource owner password credentials grant [RFC6749] MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the authorization server) and users are trained to enter their credentials in places other than the authorization server.
Даже если клиент безопасен, это приводит к увеличению поверхности атаки (учетные данные могут просачиваться не только на сервер авторизации), а пользователей обучают вводить свои учетные данные не только на сервере авторизации.
sshikov
02.01.2025 07:22Я понял, о чем вы. Практически согласен, кроме одного - вы говорите о стандарте, который не предназначен для first party apps. А стандарт для них - в драфте. И мне лично не очевидно, почему применение стандарта для приложений, к которым он (условно) не подходит, лучше в принципе, чем отступление от него. Да, отступление - это риски (которые надо анализировать конкретно). Да, это учит пользователей нехорошему - согласен.
franticticktick Автор
02.01.2025 07:22В first party apps все немного по-другому, там могут быть утечки пароля или логина с последующим перехватом их трояном например. Все, что мы ставим себе из сторов это не first party apps и там лучше следовать рекомендациям rfc. Грубо говоря, камере на айфоне это не нужно,т.к. это first party app, а вот сберу из app store не помешало бы, т.к. это third party app.
sshikov
02.01.2025 07:22Вот не очевидно. СберИд это тоже платформа, и если посмотреть в предлагаемый вами стандарт, то там написано так:
This specification MUST only be used by first-party applications, which is when the authorization server and application are operated by the same entity and the user understands them both as the same entity.
Т.е. сервер авторизации и приложение управляются Сбером? Значит Сбербанк Онлайн это first-party application, почему нет-то? Тут про ОС и предустановку ничего не написано (хотя ваши мысли что тут риска меньше, я вполне понимаю).
franticticktick Автор
02.01.2025 07:22First party application это, то что идет в комплекте с вашим девайсом. Если у вас iphone, то все, что там установлено по умолчанию это и есть first party application - safari, заметки и т.д. Для таких приложений сейчас принимаются попытки написать стандарт, цитату из которого вы привели. Приложение сбера или вк были бы first party application если бы его разработчиком был apple. Поэтому для вашего девайса (iphone например) это самые что ни на есть third party app и всегда есть отличный от нуля шанс скачать из app store что-то не то под видом сбера или вк. И ввести туда логин и пароль (который очень часто одинаковый везде, где только можно). Тут не идет речи о том, чтобы полностью решить эту проблему, это невозможно, но хотя бы сократить поверхность атак - если 40% пользователей обратят внимание, на то, что страница в браузере не та, то это уже хорошо.
sshikov
02.01.2025 07:22Ну в том стандарте ничего не написано про то, что приложение идет в комплекте. Я вам же точную цитату привел - авторы стандарта считают таковыми приложения, где сервер авторизации и приложение - единое целое. И "user understands them both as the same entity". Ну т.е. тут подчеркивается, что юзер должен понимать, что это одна компания.
franticticktick Автор
02.01.2025 07:22В то же время там написано вот что:
Because this specification enables a client application to interact directly with the end user, and the application handles sending any information collected from the user to the authorization server, it is expected to be used only for first-party applications when the authorization server also has a high degree of trust of the client.
This specification is not prescriptive on how the Authorization Server establishes it's trust in the first-partyness of the application. For mobile platforms, most support some mechanism for application attestation that can be used to identify the entity that created/signed/uploaded the app to the app store. App attestation can be combined with other mechanisms like Dynamic Client Registration [RFC7591] to enable strong client authentication in addition to client verification (first-partyness). The exact steps required are out of scope for this specification. Note that applications running inside a browser (e.g. Single Page Apps) context it is much more difficult to verify the first-partyness of the client. Please see Section 9.8 for additional details.
То есть в спецификации подразумевается, что между клиентов (приложением) и сервером авторизации есть некоторая степень доверия, а уже как она была достигнута, в спецификации не уточняется. Сказано лишь, что "есть какие-то способы это сделать в современных мобильных приложениях". Мы уже видели эти способы, как оно работает на самом деле и можно ли доверять на 100% сторам.
И тут же идут пункты 9.2 и 9.3, где прямым текстом говорится, что это не очень то и безопасно:
There are two ways using this specification increases the risk of phishing.
With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server. If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application.
In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites. By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials.
Благодаря этой спецификации клиент напрямую взаимодействует с конечным пользователем, собирая предоставленную пользователем информацию и отправляя ее на сервер авторизации. Если злоумышленник выдает себя за клиента и успешно обманом заставляет пользователя использовать его, он может не осознавать, что передает свои учетные данные вредоносному приложению.
Не стоит забывать, что пока что это драфт, т.е. эта версия стандарта еще не принята, что неудивительно, т.к. вопросов очень много. В любом случае ни одно из существующих, например, в app store приложений не может эту спецификацию реализовывать, т.к. ее еще банально нет. И как будто бы, из того, что я вижу она провисит в драфте не один год, пока не будет придуман тот самый механизм "app attestation", чтобы можно было устанавливать доверительные отношения между клиентом и сервером, но слабо себе представляю что это будет за механизм. Поэтому сейчас ничего лучше OAuth 2.0 for Native Apps сейчас нет, по крайней мере так считают эксперты мирового уровня.
inkelyad
02.01.2025 07:22If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application.
Если клиент-приложение злоумышленника выдает себя за правильного клиента - то он в процессе входа отправляет пользователя на какой-то левый сервер аутентификации, где пользователь вводит креды и... далее они успешно утекают. Чего и пытались избежать.
Т.е. мы заменяем задачу определения "а то ли злодейское ли это приложение, туда можно креды вводить?" на задачу "а злодейский ли этот сервер, туда можно креды вводить?"
Ну так себе замена. В случае сервиса без всякой "экосистемы", который только сам себя обслуживает и учетки свои собственные ведет (не технически, а с точки зрения пользователя) - получается только лишнее усложнение.
franticticktick Автор
02.01.2025 07:22Авторы спецификации подразумевали, что first party app по умолчанию обладает большим уровнем доверия. Как его достичь не уточняется, но это может быть, например, внутреннее приложение компании (для какой-нибудь курьерской службы, например), по сути это и есть first party app - предустановленный софт либо внутренние разработки не для массового сегмента. Вот что говорит microsoft по этому поводу на своем форуме.
В целом, я согласен, что при прочих равных условиях это небезопасно и противоречит оригинальной идее oauth 2.0
min8
02.01.2025 07:22Что мешает в фейковом приложении нарисовать аутентификацию в браузере и нарисовать любой нужный адрес? Фактически мы скрываем строку адреса и в фейковой строке адреса пишем что угодно хоть гугл хоть гуглосбер. При этом смысл приложения как раз в том, что мы не авторизуемся постоянно, а чуть ли не один раз на всю жизнь, и уже спустя неделю вы не вспомните как выглядел процесс авторизации и уж точно не будете помнить адрес сервера авторизации. Если брать гугл у него много разного добра и там часто можно столкнуться с авторизацией, в сбере не так часто, а условный тинек, где вы будете авторизовываться помимо самого тинька?
franticticktick Автор
02.01.2025 07:22Кстати СберID это не платформа как таковая, а сервер авторизации. Мне кажется, что это очень сильно кастомизированная keycloak., но могу ошибаться.
aamonster
02.01.2025 07:22Почему вход в приложение банка – это OAuth? Вы входите в банк с логином и паролем банка, а не с токеном со стороннего сервера аутентикации.
nerudo
02.01.2025 07:22"Не называйте мне никаких кодов. Сейчас я переключу вас на робота и вы продиктуете код ему". Просто вспомнилось, извините.
Mox
02.01.2025 07:22Я честно говоря не понял идею - если мы не доверяем приложению, то почему мы должны доверять контенту "браузерного окна", которое оно открывает?
franticticktick Автор
02.01.2025 07:22Эта идея - суть есть краеугольный камень всего oauth 2.0 (и не только). Ее можно критиковать (в некоторых аспектах вполне обоснованно), но реальность такова, что конкурентоспособной альтернативы предложено не было. И, к сожалению, эта идея почему-то вызывает у людей отторжение, видимо годами привыкшие вводить свои данные в нативные компоненты приложения, пользователи начали считать это нормой.
ilyamodder
02.01.2025 07:22Вы упускаете момент, что OAuth разрабатывался для браузеров, где действительно приложение не может залезть в соседнюю вкладку и посмотреть креды, поэтому принцип «не давать креды напрямую приложению» работает. В случае нативных приложений это не работает, потому что оно фактически имеет полный доступ к любым WebView, которое оно открывает, и в этом разделении нет смысла.
Да и, как вам уже написали выше, нет никакого смысла не доверять пароль от Тинькофф их же приложению. Вы предлагаете забить на здравый смысл и следовать стандарту ради следования стандарту.
briabeegost
02.01.2025 07:22Так так так, браузер получает и отправляет сетевые запросы для авторизации и получения токена сессии, приложение делает то же самое, но не рендерит html+css. В чём разница получается? В том, что не видим, на какой домен мы отправляем данные? Ну я лично не думаю что Тинькофф украдёт мой номер телефона и код для входа в тинькоффк.
Если же речь про зловреды и mitm, то с браузером ведь точно такая же история, а если говорить про уязвимости памяти, то достать введённые данные из нативных компонентов скорее всего сложнее, чем из формочки в браузере, разве нет?
И в чём проблема для фейковых приложений открыть страничку в браузере и просто получить токен сессии??? Это наоборот более уязвимая и простая для мошенников стратегия: пользователь увидит что домен настоящий и откинет сомнения, не надо пытаться повторить формы авторизации, все двухфакторки пользователь подтвердит сам, а зловред получит готовенький токен.
Когда же авторизация происходит в нативном клиенте, то у разработчиков есть отличные возможности для обнаружения поддельных запросов и подробностей о версии клиента, что усложняет процесс мошенникам.
Я понимаю, что это фундаментальный принцип какой-то там, придуманный кем-то там, но я не вижу особых причин для критики или сомнений в надёжности тех сервисов, которые его не придерживаются. Может я чего-то не понимаю?
franticticktick Автор
02.01.2025 07:22Так так так, браузер получает и отправляет сетевые запросы для авторизации и получения токена сессии, приложение делает то же самое, но не рендерит html+css. В чём разница получается? В том, что не видим, на какой домен мы отправляем данные? Ну я лично не думаю что Тинькофф украдёт мой номер телефона и код для входа в тинькоффк.
Тинькофф точно не украдет ваш номер телефона, по крайней мере мы хотим в этой верить)) А вот оно украдет. И как понять, что вы ввели логин пароль не в приложение т-банка а вот сюда? Окно браузера с всплывающим предупреждением дает хоть какой-то шанс на, что пользователь обратит внимание на то, куда он вводит логин и пароль. Особенно если он это делал годами и другого варианта у него нет.
И в чём проблема для фейковых приложений открыть страничку в браузере и просто получить токен сессии??? Это наоборот более уязвимая и простая для мошенников стратегия: пользователь увидит что домен настоящий и откинет сомнения, не надо пытаться повторить формы авторизации, все двухфакторки пользователь подтвердит сам, а зловред получит готовенький токен.
В момент редиректа зловредное приложение и правда может перехватить любые данные. Для этого был придуман Proof Key for Code Exchange by OAuth Public Clients - использование
code_verifierиcode_challenge. Кроме того, если использовать universal links или applink, то такая атака в принципе не сработает.inkelyad
02.01.2025 07:22В момент редиректа зловредное приложение и правда может перехватить любые данные.
Почему перехватить? Оно честно, точно так же как родное приложение банка делает, запросит токен доступа. И получит его. У сервера авторизации по большому счету нет же способа проверить, кто к нему стучится. Родное приложение или его слегка модифицированная злодеем версия.
franticticktick Автор
02.01.2025 07:22Как минимум зловреду нужно знать
client_id,а даже если он его получит, то ему все также надо пройтиauthorization code flow.Злоумышленник может создать приложение, которое перехватывает такие же редиректы, как у нашего приложение. Но с Proof Key for Code Exchange by OAuth Public Clients эта проблема решается.ilyamodder
02.01.2025 07:22Ничего не мешает отреверсить как зашитый в приложение client_id, так и алгоритм генерации code_challenge/code_verifier вместе с эндпоинтом, который в итоге выдаст токен доступа. Это почти никак не усложняет защиту от модификаций приложения.
nsk_fedotov
02.01.2025 07:22Идея использовать браузер для бозопасного доступа к доверенному серверу основана на том что сам браузер является доверенным, но пользователь может использовать любой браузер, в том числе и угоняющий его пароли из форм ввода, возможно не осознавая этого. Как рассмотренная техника может помочь в данном случае?
randomsimplenumber
Приложение может нарисовать окно, похожее на окно браузера.
franticticktick Автор
Увы, это факт. Поэтому при запросе авторизации приложение дает предупреждение о том, что будет использовано для авторизации, а в браузерном окне виден адрес сервера авторизации. Это не решит проблему в 10 из 10 случаев, но как минимум позволит уменьшить поверхность атаки для наиболее внимательных пользователей, особенно если они годами вводили логин и пароль именно таким способом.