8kSec Academy – In-Depth Mobile Security Courses

Deepen your expertise in Mobile Security with 8kSec Academy. Master iOS and Android security through our self-paced courses and get certified.

Get certified

OAuth до захоплення облікового запису

Reading time: 15 minutes

Основна інформація

OAuth пропонує різні версії, з основними відомостями, доступними в OAuth 2.0 documentation. Це обговорення в основному зосереджене на широко використовуваному OAuth 2.0 authorization code grant type, що надає рамки авторизації, які дозволяють додатку отримувати доступ або виконувати дії в обліковому записі користувача в іншому додатку (сервер авторизації).

Розгляньте гіпотетичний веб-сайт https://example.com, призначений для демонстрації всіх ваших публікацій у соціальних мережах, включаючи приватні. Для цього використовується OAuth 2.0. https://example.com запитає вашу згоду на доступ до ваших публікацій у соціальних мережах. Відповідно, на https://socialmedia.com з'явиться екран згоди, що описує дозволи, які запитуються, та розробника, який робить запит. Після вашої авторизації https://example.com отримує можливість доступу до ваших публікацій від вашого імені.

Важливо зрозуміти наступні компоненти в рамках OAuth 2.0:

• власник ресурсу: Ви, як користувач/суб'єкт, авторизуєте доступ до вашого ресурсу, наприклад, до публікацій у вашому обліковому записі соціальних мереж.
• сервер ресурсу: сервер, що керує аутентифікованими запитами після того, як додаток отримав access token від імені власника ресурсу, наприклад, https://socialmedia.com.
• клієнтський додаток: додаток, що запитує авторизацію у власника ресурсу, наприклад, https://example.com.
• сервер авторизації: сервер, що видає access tokens клієнтському додатку після успішної аутентифікації власника ресурсу та отримання авторизації, наприклад, https://socialmedia.com.
• client_id: Публічний, унікальний ідентифікатор для додатку.
• client_secret: Конфіденційний ключ, відомий лише додатку та серверу авторизації, що використовується для генерації access_tokens.
• response_type: Значення, що вказує тип запитуваного токена, наприклад, code.
• scope: рівень доступу, який клієнтський додаток запитує у власника ресурсу.
• redirect_uri: URL, на який користувач перенаправляється після авторизації. Це зазвичай повинно відповідати попередньо зареєстрованому URL перенаправлення.
• state: Параметр для збереження даних під час перенаправлення користувача до та з сервера авторизації. Його унікальність є критично важливою для виконання механізму захисту від CSRF.
• grant_type: Параметр, що вказує тип гранту та тип токена, що повертається.
• code: Код авторизації з сервера авторизації, що використовується разом з client_id та client_secret клієнтським додатком для отримання access_token.
• access_token: токен, який клієнтський додаток використовує для API запитів від імені власника ресурсу.
• refresh_token: Дозволяє додатку отримати новий access_token без повторного запиту у користувача.

Потік

Фактичний потік OAuth відбувається наступним чином:

1. Ви переходите на https://example.com і вибираєте кнопку “Інтегрувати з соціальними мережами”.
2. Сайт надсилає запит на https://socialmedia.com, просячи вашу авторизацію для надання доступу додатку https://example.com до ваших публікацій. Запит структурований як:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Вам буде представлено сторінку згоди.
4. Після вашого схвалення, Social Media надсилає відповідь на redirect_uri з параметрами code та state:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com використовує цей code, разом із своїм client_id та client_secret, щоб зробити запит на стороні сервера для отримання access_token від вашого імені, що дозволяє доступ до дозволів, на які ви погодилися:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Нарешті, процес завершується, коли https://example.com використовує ваш access_token для виконання API виклику до Social Media для доступу

Вразливості

Відкритий redirect_uri

redirect_uri є критично важливим для безпеки в реалізаціях OAuth та OpenID, оскільки він вказує, куди надсилаються чутливі дані, такі як коди авторизації, після авторизації. Якщо він неправильно налаштований, це може дозволити зловмисникам перенаправляти ці запити на шкідливі сервери, що дозволяє захоплення облікового запису.

Методи експлуатації варіюються в залежності від логіки валідації авторизаційного сервера. Вони можуть коливатися від суворого співпадіння шляхів до прийняття будь-якого URL в межах вказаного домену або підкаталогу. Загальні методи експлуатації включають відкриті редиректи, обходи шляхів, експлуатацію слабких регулярних виразів та HTML-ін'єкцію для крадіжки токенів.

Окрім redirect_uri, інші параметри OAuth та OpenID, такі як client_uri, policy_uri, tos_uri та initiate_login_uri, також підлягають атакам редиректу. Ці параметри є необов'язковими, і їх підтримка варіюється між серверами.

Для тих, хто націлений на сервер OpenID, кінцева точка виявлення (**.well-known/openid-configuration**) часто містить цінні деталі конфігурації, такі як registration_endpoint, request_uri_parameter_supported та "require_request_uri_registration. Ці деталі можуть допомогти в ідентифікації кінцевої точки реєстрації та інших специфікацій конфігурації сервера.

XSS в реалізації редиректу

Як згадано в цьому звіті про баги https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, можливо, що URL редиректу відображається у відповіді сервера після аутентифікації користувача, будучи вразливим до XSS. Можливий корисний вантаж для тестування:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Неправильна обробка параметра state

У реалізаціях OAuth неправильне використання або пропуск параметра state може значно підвищити ризик атак Cross-Site Request Forgery (CSRF). Ця вразливість виникає, коли параметр state або не використовується, використовується як статичне значення, або не перевіряється належним чином чи не асоціюється з сесією користувача під час входу, що дозволяє зловмисникам обходити захист CSRF.

Зловмисники можуть скористатися цим, перехоплюючи процес авторизації, щоб зв'язати свій обліковий запис з обліковим записом жертви, що призводить до потенційних взломів облікових записів, змушуючи користувача увійти в майже завершений oauth потік, що належить зловмиснику. Це особливо критично в додатках, де OAuth використовується для автентифікаційних цілей.

Приклади цієї вразливості в реальному світі були задокументовані в різних CTF викликах та хакерських платформах, підкреслюючи її практичні наслідки. Проблема також поширюється на інтеграції з сторонніми сервісами, такими як Slack, Stripe та PayPal, де зловмисники можуть перенаправляти сповіщення або платежі на свої облікові записи.

Належна обробка та перевірка параметра state є критично важливими для захисту від CSRF та забезпечення безпеки OAuth потоку.

Перед взломом облікового запису

1. Без перевірки електронної пошти при створенні облікового запису: Зловмисники можуть заздалегідь створити обліковий запис, використовуючи електронну пошту жертви. Якщо жертва пізніше використовує сторонній сервіс для входу, додаток може ненавмисно зв'язати цей сторонній обліковий запис з попередньо створеним обліковим записом зловмисника, що призводить до несанкціонованого доступу.
2. Використання слабкої перевірки електронної пошти в OAuth: Зловмисники можуть скористатися сервісами OAuth, які не перевіряють електронні адреси, зареєструвавшись у їхньому сервісі, а потім змінивши електронну адресу облікового запису на електронну адресу жертви. Цей метод також несе ризик несанкціонованого доступу до облікового запису, подібно до першого сценарію, але через інший вектор атаки.

Розкриття секретів

Визначення та захист секретних параметрів OAuth є критично важливими. Хоча client_id можна безпечно розкривати, розкриття client_secret несе значні ризики. Якщо client_secret буде скомпрометовано, зловмисники можуть скористатися ідентичністю та довірою додатка, щоб вкрасти access_tokens та приватну інформацію.

Загальна вразливість виникає, коли додатки помилково обробляють обмін авторизаційного code на access_token на стороні клієнта, а не на стороні сервера. Ця помилка призводить до розкриття client_secret, що дозволяє зловмисникам генерувати access_tokens під виглядом додатка. Більше того, через соціальну інженерію зловмисники можуть підвищити привілеї, додаючи додаткові області до авторизації OAuth, ще більше експлуатуючи довірений статус додатка.

Брутфорс секрету клієнта

Ви можете спробувати брутфорсити client_secret постачальника послуг з ідентифікатором постачальника, щоб спробувати вкрасти облікові записи.
Запит на BF може виглядати приблизно так:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

Якщо клієнт має код і стан, і вони відображаються в заголовку Referer при переході на іншу сторінку, то це вразливість.

Access Token Stored in Browser History

Перейдіть до історії браузера і перевірте, чи збережено токен доступу.

Everlasting Authorization Code

Код авторизації повинен існувати лише деякий час, щоб обмежити часовий проміжок, протягом якого зловмисник може його вкрасти і використати.

Authorization/Refresh Token not bound to client

Якщо ви можете отримати код авторизації і використати його з іншим клієнтом, то ви можете захопити інші облікові записи.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Перевірте цей пост

AWS Cognito

У цьому звіті про баг-баунті: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ ви можете побачити, що токен, який AWS Cognito повертає користувачу, може мати достатньо прав для перезапису даних користувача. Тому, якщо ви можете змінити електронну пошту користувача на іншу електронну пошту, ви можете захопити інші облікові записи.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Для більш детальної інформації про те, як зловживати AWS cognito, перегляньте:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Зловживання токенами інших додатків

Як зазначено в цьому звіті, потоки OAuth, які очікують отримати токен (а не код), можуть бути вразливими, якщо не перевіряють, що токен належить додатку.

Це пов'язано з тим, що зловмисник може створити додаток, що підтримує OAuth і входити через Facebook (наприклад) у своєму додатку. Потім, коли жертва входить через Facebook у додатку зловмисника, зловмисник може отримати OAuth токен користувача, наданий його додатку, і використовувати його для входу в OAuth додаток жертви, використовуючи токен користувача жертви.

Два посилання та cookie

Згідно з цим звітом, було можливим змусити жертву відкрити сторінку з returnUrl, що вказує на хост зловмисника. Ця інформація буде збережена в cookie (RU), а на пізнішому етапі підказка запитає користувача, чи хоче він надати доступ до цього хосту зловмисника.

Щоб обійти цю підказку, було можливим відкрити вкладку для ініціювання Oauth потоку, яка встановить це RU cookie, закрити вкладку до того, як з'явиться підказка, і відкрити нову вкладку без цього значення. Тоді підказка не повідомить про хост зловмисника, але cookie буде встановлено на нього, тому токен буде надіслано на хост зловмисника під час редиректу.

Обхід взаємодії з підказкою

Як пояснено в цьому відео, деякі реалізації OAuth дозволяють вказати параметр prompt GET як None (&prompt=none), щоб запобігти запитам до користувачів на підтвердження наданого доступу в підказці на веб-сайті, якщо вони вже увійшли на платформу.

response_mode

Як пояснено в цьому відео, можливо вказати параметр response_mode, щоб вказати, де ви хочете, щоб код був наданий у фінальному URL:

• response_mode=query -> Код надається всередині GET параметра: ?code=2397rf3gu93f
• response_mode=fragment -> Код надається всередині фрагмента URL параметра #code=2397rf3gu93f
• response_mode=form_post -> Код надається всередині POST форми з полем введення, названим code, і значенням
• response_mode=web_message -> Код надсилається в пост-повідомленні: window.opener.postMessage({"code": "asdasdasd...

OAuth ROPC потік - обхід 2 FA

Згідно з цим блогом, це OAuth потік, який дозволяє входити в OAuth через ім'я користувача та пароль. Якщо під час цього простого потоку повертається токен з доступом до всіх дій, які може виконати користувач, то можливо обійти 2FA, використовуючи цей токен.

ATO на веб-сторінці, що перенаправляє на основі відкритого редиректу на реферер

Цей блог коментує, як було можливим зловживати відкритим редиректом на значення з реферера, щоб зловживати OAuth для ATO. Атака полягала в наступному:

1. Жертва заходить на веб-сторінку зловмисника
2. Жертва відкриває шкідливе посилання, і відкривач запускає Google OAuth потік з response_type=id_token,code&prompt=none як додаткові параметри, використовуючи реферер веб-сайту зловмисника.
3. У відкривачі, після того як постачальник авторизує жертву, він повертає їх назад до значення параметра redirect_uri (веб-сайт жертви) з кодом 30X, який все ще зберігає веб-сайт зловмисника в реферері.
4. Веб-сайт жертви ініціює відкритий редирект на основі реферера, перенаправляючи користувача жертви на веб-сайт зловмисника, оскільки respose_type був id_token,code, код буде надіслано назад до зловмисника у фрагменті URL, що дозволяє йому захопити обліковий запис користувача через Google на сайті жертви.

Параметри SSRFs

Перевірте це дослідження Для подальших деталей цієї техніки.

Динамічна реєстрація клієнтів у OAuth є менш очевидним, але критично важливим вектором для вразливостей безпеки, зокрема для атак Server-Side Request Forgery (SSRF). Цей кінцевий пункт дозволяє серверам OAuth отримувати деталі про клієнтські додатки, включаючи чутливі URL, які можуть бути використані в атаках.

Ключові моменти:

• Динамічна реєстрація клієнтів часто відображається на /register і приймає деталі, такі як client_name, client_secret, redirect_uris та URL для логотипів або JSON Web Key Sets (JWKs) через POST запити.
• Ця функція відповідає специфікаціям, викладеним у RFC7591 та OpenID Connect Registration 1.0, які включають параметри, потенційно вразливі до SSRF.
• Процес реєстрації може ненавмисно піддавати сервери SSRF кількома способами:
• logo_uri: URL для логотипу клієнтського додатку, який може бути отриманий сервером, викликаючи SSRF або призводячи до XSS, якщо URL обробляється неналежно.
• jwks_uri: URL до документа JWK клієнта, який, якщо його зловмисно створити, може змусити сервер здійснити вихідні запити до сервера, контрольованого зловмисником.
• sector_identifier_uri: Посилається на JSON масив redirect_uris, які сервер може отримати, створюючи можливість SSRF.
• request_uris: Перераховує дозволені запитувані URI для клієнта, які можуть бути використані, якщо сервер отримує ці URI на початку процесу авторизації.

Стратегія експлуатації:

• SSRF може бути ініційовано реєстрацією нового клієнта з зловмисними URL в параметрах, таких як logo_uri, jwks_uri або sector_identifier_uri.
• Хоча пряма експлуатація через request_uris може бути пом'якшена контролем білого списку, надання попередньо зареєстрованого, контрольованого зловмисником request_uri може полегшити SSRF під час етапу авторизації.

Умови гонки постачальників OAuth

Якщо платформа, яку ви тестуєте, є постачальником OAuth прочитайте це, щоб перевірити можливі умови гонки.

Атака на змінні претензії

У OAuth поле sub унікально ідентифікує користувача, але його формат варіюється в залежності від сервера авторизації. Щоб стандартизувати ідентифікацію користувачів, деякі клієнти використовують електронні адреси або імена користувачів. Однак це ризиковано, оскільки:

• Деякі сервери авторизації не гарантують, що ці властивості (як електронна адреса) залишаються незмінними.
• У певних реалізаціях — таких як "Увійти через Microsoft" — клієнт покладається на поле електронної адреси, яке контролюється користувачем у Entra ID і не перевіряється.
• Зловмисник може скористатися цим, створивши свою власну організацію Azure AD (наприклад, doyensectestorg) і використовуючи її для виконання входу через Microsoft.
• Навіть якщо Object ID (збережений у sub) є незмінним і безпечним, покладання на змінне поле електронної адреси може дозволити захоплення облікового запису (наприклад, захоплення облікового запису на кшталт victim@gmail.com).

Атака на плутанину клієнтів

У Атаці на плутанину клієнтів додаток, що використовує OAuth Implicit Flow, не перевіряє, що фінальний токен доступу спеціально згенерований для його власного Client ID. Зловмисник створює публічний веб-сайт, який використовує OAuth Implicit Flow Google, обманюючи тисячі користувачів на вході та таким чином збираючи токени доступу, призначені для сайту зловмисника. Якщо ці користувачі також мають облікові записи на іншому вразливому веб-сайті, який не перевіряє Client ID токена, зловмисник може повторно використовувати зібрані токени, щоб видавати себе за жертв і захоплювати їхні облікові записи.

Атака на підвищення обсягу

Тип Authorization Code Grant передбачає безпечну комунікацію між серверами для передачі даних користувача. Однак, якщо Authorization Server імпліцитно довіряє параметру обсягу в запиті на токен доступу (параметр, не визначений у RFC), зловмисний додаток може підвищити привілеї авторизаційного коду, запитуючи вищий обсяг. Після того, як токен доступу згенеровано, ресурсний сервер повинен його перевірити: для токенів JWT це передбачає перевірку підпису JWT та витягування даних, таких як client_id та scope, тоді як для токенів випадкових рядків сервер повинен запитати у сервера авторизації, щоб отримати деталі токена.

Викрадення схеми редиректу

У мобільних реалізаціях OAuth додатки використовують кастомні URI-схеми для отримання редиректів з авторизаційними кодами. Однак, оскільки кілька додатків можуть зареєструвати одну й ту ж схему на пристрої, припущення, що лише легітимний клієнт контролює URI редиректу, порушується. Наприклад, на Android URI наміру, як com.example.app://, oauth перехоплюється на основі схеми та необов'язкових фільтрів, визначених у намірі додатку. Оскільки розв'язання намірів Android може бути широким — особливо якщо вказана лише схема — зловмисник може зареєструвати шкідливий додаток з ретельно розробленим фільтром наміру, щоб викрасти код авторизації. Це може дозволити захоплення облікового запису або через взаємодію користувача (коли кілька додатків можуть обробляти намір) або через техніки обходу, які експлуатують надто специфічні фільтри, як детально описано в діаграмі оцінки Ostorlab.

Посилання

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html