Десктопные и мобильные приложения — это встроенные браузеры, которые помогают пройти весь процесс OAuth 2.0
Процесс показан на рисунке
OAuth2.0 web
1) Вернуть authCode в указанный веб-redirectUri (этот URI настроен разработчиком приложения)
2) Чтобы изменить токен, необходимо передать clientId и clientSecret для подтверждения идентичности клиента (полученных через сервер приложения)
Обратив внимание на два вышеуказанных пункта,
1) Поскольку не перенаправление веб-приложения, обнаружение Uri некорректно
2) Поскольку нет бэкенд-сервиса, Secret не защищён
Тогда атака, с которой мы можем столкнуться, такова, как показано на рисунке ниже: возможно, вредоносное приложение перехватит authCode и отправит сообщение в AuthorizationServer с целью получения токена, чтобы токен был получен без разрешения клиента для приложения, а на другую официальную авторизацию приложения, достигая цели атаки.
Решение:
1. Клиент генерирует случайную строку: код верификатор и сохраняет эту случайную строку
code_challenge = преобразование(code_verifier, [Plain| S256])
Если метод преобразования прост, то вызов кода эквивалентен проверяющему коду
Если метод преобразования — S256, то задание кода равно хэшу Sha256 проверителя кода
2. Внесите вызов в запрос авторизационного кода и определите, как создать вызов кода. Оба этих кода связаны с кодом авторизации, выданным сервером
3. После получения кода авторизации клиент использует первоначально сгенерированный верификатор кода при обмене кода авторизации на токен доступа. Сервер вычисляет верификатор кода по методу связанного преобразования, сравнивает вычисленный результат с задачей связанного кода и выдает Access Token, если он согласован. |
Опубликовано 28.11.2020 20:51:48
|
|
|
|
