OAuth 2.0 Device Flow

OAuth 2.0 Device Flow: как угнать токен через телевизор

OAuth 2.0 Device Flow — это поток авторизации, спроектированный для устройств без клавиатуры и браузера: смарт-ТВ, игровых консолей, CLI-инструментов и IoT-девайсов. Но там, где есть удобство — есть и уязвимости, и сегодня мы вскроем всё по-честному.

Как это работает (под капотом)

Классический Device Flow описан в RFC 8628 и выглядит так:

Ключевые параметры ответа на /device_authorize:

ПолеСмысл
device_codeСекрет устройства, хранится на TV
user_codeКороткий код для пользователя (8 символов)
verification_uriURL, куда идёт юзер
expires_inTTL кода (обычно 900 сек)
intervalПауза между поллингами (обычно 5 сек)

Вектор атаки #1: Брутфорс user_code

Это самый тупой и самый рабочий вектор. user_code — короткий, читабельный человеком. Стандарт рекомендует 8 символов из ограниченного алфавита (без похожих символов: 0OI1).

Пространство поиска при формате XXXX-XXXX из 20 символов: 20^8 = 25.6 миллиарда. Звучит страшно, но если TTL = 15 минут, а rate limit отсутствует…

Почему это работает: многие реализации не делают rate limiting на /token endpoint, считая его «серверным» вызовом.

Вектор атаки #2: Device Code Phishing (реальный APT-вектор

Это то, что реально использовали против Microsoft 365 зимой 2025 года. Атака описана Volexity и называется Device Code Phishing.

Схема атаки:

Атакующий получает токен, действительный 60 дней, без каких-либо уведомлений жертве. Никакого фишинга паролей — только легитимный OAuth flow.

Реализация Device Code Phishing:

Вектор атаки #3: Race Condition при обмене кода

Если сервер не инвалидирует device_code мгновенно после выдачи токена — можно попытаться получить несколько токенов по одному коду.

Вектор атаки #4: Перехват через открытый редирект

В некоторых реализациях verification_uri_complete содержит user_code прямо в URL. Если приложение делает промежуточный редирект через незащищённый эндпоинт — код утечёт в Referer header.

Как детектить и защищаться

Для красного:

  • Ищи /device_authorize или /devicecode эндпоинты в Burp через поиск по History
  • Проверяй длину и алфавит user_code — если меньше 8 символов, пробуй брут
  • Проверяй наличие rate limit: 50+ запросов в секунду на /token без блокировки = уязвимость

Для синего:

  • Rate limiting на /token endpoint: не более 5 запросов в 5 секунд на device_code
  • Короткий TTLexpires_in не более 5-10 минут для чувствительных систем
  • Энтропия user_code: минимум 20 бит (8 символов из 20-символьного алфавита)
  • Уведомления: push-нотификация пользователю при попытке активации устройства
  • Контекст устройства: привязка device_code к IP/UA инициатора
  • Мониторинг: алерты на VS Code client_id (04b07795...) в логах авторизации

Итог по векторам

ВекторСложностьРеальностьОбнаружимость
Брутфорс user_codeНизкаяСредняя (нужен слабый rate limit)Высокая (много запросов)
Device Code PhishingНизкаяОчень высокая (реальные APT)Низкая (легитимный flow)
Race ConditionСредняяНизкаяСредняя
Open Redirect утечкаСредняяСредняяНизкая

Device Code Phishing — самый опасный вектор именно потому, что не нарушает ни одного технического контроля. Это чистая социальная инженерия поверх легитимного RFC. Защита только одна: пользователи должны знать, что никогда не стоит вводить коды авторизации по просьбе третьих лиц, даже если это выглядит как ссылка на легитимный домен Microsoft или Google.

OAuth 2.0 Device Flow: как угнать токен через телевизор

На этом все. Всем хорошего дня!