Десктопні та мобільні додатки — це вбудовані браузери, які допомагають завершити весь процес 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. Після отримання коду авторизації клієнт приносить спочатку згенерований верифікатор коду при обміні коду авторизації на Access Token. Сервер обчислює перевірку коду відповідно до методу зв'язаного перетворення, порівнює обчислений результат із викликом зв'язаного коду та видає Access Token, якщо він узгоджений. |
Опубліковано 28.11.2020 20:51:48
|
|
|
|
