🔘 Login CSRF → тихий захват аккаунта
Если state не проверяется или хранится криво — можно:
1. Авторизоваться через OAuth у себя
2. Подсунуть жертве ссылку на callback
3. Жертва «логинится» в ваш аккаунт
Дальше — phishing, data exfiltration, business-logic abuse.
🔘 Substitution attack через ID Token
Классика SPA:
Backend не проверяет:
• aud
• iss
• nonce
• подпись через JWK
Берём валидный id_token от другого клиента → отправляем в API → логинимся. Если нет строгой валидации claims — это ATO.
🔘 OAuth + Open Redirect = перехват кода
Сценарий:
1. redirect_uri проходит слабую проверку
2. Внутри него есть open redirect
3. Authorization code уходит на атакующий домен
4. Обмен кода → access_token
Это уже не просто баг — это полный доступ к аккаунту.
🔘 SSRF через OAuth metadata
Некоторые реализации динамически подтягивают:
/.well-known/openid-configuration
Если можно подменить issuer → сервер сам сделает SSRF.
Дальше:
• Внутренние сервисы
• Cloud metadata
• Credential leak
OAuth превращается в pivot.
🔘 Email collision → маппинг на чужой аккаунт
Приложение доверяет: email = уникальный идентификатор
Но:
• email_verified не проверяется
• Разные провайдеры могут вернуть одинаковый email
• Нет жесткой привязки к provider ID
Результат — silent account takeover.
📍 Навигация: [Вакансии]
🐸 Библиотека хакера
#breach_breakdown