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