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

Страницы входа и согласия могут действительно принадлежать Microsoft, Google или другому провайдеру. Настоящий домен не делает стороннее приложение безопасным: проверять нужно издателя, происхождение запроса, список разрешений и деловую причину. Microsoft определяет фишинг согласия как обман, заставляющий пользователя дать вредоносному облачному приложению доступ к законным сервисам и данным.［1］

Ключевые выводы

Настоящая страница OAuth не подтверждает честность приложения и задачи.

До согласия сравните издателя, источник перехода и каждое разрешение с нужной функцией.

Смена пароля не обязана удалять разрешение OAuth: доступ подозрительного приложения нужно отозвать отдельно.

После согласия выясните не только потенциальный объем доступа, но и реальные действия приложения.

Как выглядит нормальное согласие OAuth?

OAuth — механизм авторизации. Он позволяет одному сервису попросить ограниченный доступ к ресурсам другого сервиса, не получая многоразовый пароль пользователя. Календарь может разрешить инструменту видеть расписание, а редактор документов — создавать файлы. Провайдер проверяет личность и показывает экран с приложением и запрошенными возможностями.

Преимущество модели — разделение секрета и полномочий: приложение получает токен, представляющий разрешенный доступ. Но согласие остается решением о безопасности. Приложение с ненужными правами, неизвестным издателем или неожиданной легендой может получить устойчивый канал к данным, даже если пароль и MFA не были украдены.

Microsoft различает делегированный доступ, когда приложение действует от имени вошедшего пользователя и не может превысить его собственные права, и доступ приложения, когда оно действует как самостоятельная идентичность без присутствия пользователя. Во втором случае применяются разрешения приложения, которые обычно требуют согласия администратора; привилегированные делегированные разрешения также могут требовать такого согласия.［2］

Модель	От чьего имени работает приложение	Граница	Главный вопрос
Делегированные разрешения	Вошедший пользователь	Доступ пользователя плюс одобренные области	Нужна ли функции возможность действовать как я?
Разрешения приложения	Само приложение	Ресурсы, охваченные ролью приложения	Почему фоновому сервису нужен такой масштаб?
Связь для входа	Идентичность пользователя	Поля профиля из запроса	Это то приложение, куда я собирался войти?
Обмен данными	Связанные сервисы	Указанные данные и длительность связи	Как удалить связь и что сохранит третья сторона?

Как проходит фишинг через согласие OAuth?

Атакующий регистрирует или захватывает приложение, настраивает желаемые разрешения и создает предлог: общий документ, голосовое сообщение, отчет о расходах, приглашение на встречу, файл для найма, обновление безопасности или обязательная интеграция. Ссылка открывает процесс авторизации. Пользователь может пройти настоящую проверку личности у провайдера, поэтому знакомое оформление снижает настороженность.

Экран согласия показывает имя приложения и запрошенные права. Злоумышленник рассчитывает на усталость от запросов, общее название вроде «Просмотр документов», знакомый логотип или срочность. После согласия платформа записывает разрешение и выдает токены по своим правилам. Приложение может читать почту, файлы, контакты и данные профиля, отправлять сообщения или обращаться к другим ресурсам из одобренного набора — причем без новой поддельной страницы входа.

Поэтому атака отличается от обычного фишинга: пароль может не покидать провайдера, а MFA работает правильно. Вредное решение — авторизация. Одна приманка иногда одновременно крадет пароль или сеанс, но такие пути нужно устранять отдельно.

Что проверять на экране согласия?

Начните с пути. Вы сами открыли приложение из известного каталога, официального сайта или утвержденного рабочего процесса? Настоящий экран, открытый из неожиданного письма, остается рискованным. Подтвердите запрос у отправителя через другой канал, если задача не ожидалась.

Затем проверьте четыре элемента. Общее или похожее имя приложения не является удостоверением. Издатель и его домен должны соответствовать настоящему поставщику, хотя подтвержденный издатель лишь уменьшает неопределенность, а не гарантирует честное поведение. Сравните каждое разрешение с точной функцией и оцените масштаб и длительность доступа: автономная работа, чтение и отправка почты, все файлы, контакты, каталог и административные действия требуют ясного обоснования.

Сигнал	Менее рискованный вариант	Более рискованный вариант
Источник	Вы начали с известного продукта	Неожиданное письмо, чат или QR-код
Издатель	Ожидаемая компания и совпадающий домен	Неизвестный, ошибочный или несвязанный
Права	Узкий набор для конкретной функции	Почта, файлы, отправка или доступ «ко всему»
Момент	Вы включаете соответствующую функцию	Срочное согласие вне текущей задачи
Объяснение	Понятная цель и политика данных	Размытая причина и давление

Не считайте отметку подтвержденного издателя автоматическим разрешением. Microsoft советует проверять источник и запрошенные права даже для подтвержденных издателей. Если приложение не может обосновать разрешение, отклоните запрос: принцип минимальных привилегий требует предоставить только тот доступ, без которого заявленная функция не работает.

Почему смена пароля не заменяет отзыв доступа приложения?

Пароль участвует в аутентификации личности, а разрешение OAuth хранит авторизацию приложения. Это разные серверные объекты. Смена пароля защищает будущие входы и может повлиять на часть сеансов, но провайдер может продолжить признавать ранее выданное согласие и связанный токен обновления. Удаление локального приложения, файлов cookie или сеанса браузера также не гарантирует удаления серверного разрешения.

Поэтому нужны две линии. Если могли утечь пароль или сеанс, защитите идентичность. Отдельно удалите подозрительное приложение в настройках подключений или корпоративной панели. Google позволяет просматривать связанные приложения, видеть их доступ, удалять его и отправлять жалобу из настроек аккаунта.［3］

Отзыв не действует задним числом. Он останавливает будущий доступ по этой авторизации, но не возвращает скопированные данные, не отменяет отправленную почту и не стирает сведения на стороне разработчика. Некоторые провайдеры отдельно предупреждают, что удаление связи для входа не удаляет данные, сохраненные сторонним сервисом. Поэтому нужно оценить прошлую активность и доступный набор данных, а при важном вопросе хранения обратиться к разработчику или администратору.

Что делать, если вы одобрили подозрительное или вредоносное OAuth-приложение?

С доверенного устройства вручную откройте официальный адрес провайдера. Не возвращайтесь через приманку. Если безопасно, запишите название, издателя, права, время согласия, идентификаторы приложения и исходное сообщение, затем отзовите связь.

Уровень воздействия	Действие пользователя	Действие администратора
Экран открыт, согласия не было	Закрыть и сообщить о приманке	Заблокировать или исследовать приложение и отправителя, если это рабочая среда
Одобрены узкие права	Отозвать и проверить недавнюю активность	Сопоставить разрешение, области доступа и использование токенов
Доступ к почте, файлам, контактам или отправке	Отозвать; проверить правила, отправку и общий доступ	Изучить журналы аудита и входов, сохранить доказательства и при необходимости уведомить владельцев данных
Согласие администратора или признаки злоупотребления	Немедленно обратиться в службу безопасности, защитить восстановление	Отключить приложение или его субъект-службу, отозвать разрешения и токены, проверить других пользователей, оценить обязанность сообщить о раскрытии

Если приманка также получила пароль, смените его и отзовите неизвестные сеансы. При незнакомом входе используйте порядок из материала Кто-то вошел в мой аккаунт. Проверьте пересылку почты, делегатов, общий доступ к файлам, восстановление и новые приложения. Доступ к почте способен дать материал для дальнейшей социальной инженерии даже без смены пароля.

Для рабочего или учебного аккаунта пользовательская страница не всегда показывает влияние на всю организацию. Сообщите команде время и детали. Администраторы должны проверить записи согласия, объект приложения, типы разрешений, события аудита, использование токенов и других пользователей, одобривших то же приложение. В некоторых сценариях отключения уже выданные токены доступа могут действовать до истечения, поэтому реагирование должно следовать актуальной процедуре отзыва у провайдера.

Как организации предотвращают фишинг согласия?

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

Обучение должно честно объяснять: домен провайдера может быть настоящим, а приложение — вредоносным. Сотрудник должен сравнивать права с задачей и уметь сообщить о запросе, не одобряя его. Быстрый законный процесс запроса программ снижает давление обходить контроль.

Технические меры должны обеспечивать минимальные привилегии, ограничивать высокорисковое согласие, отслеживать необычные разрешения и сохранять полезные журналы аудита. Кражу учетных данных и захват сеанса рассматривайте как отдельные пути. Общую базу для аккаунта и восстановления дает руководство по онлайн-безопасности, а управление приложениями добавляет слой авторизации.

Часто задаваемые вопросы (FAQ)

OAuth сам по себе небезопасен?

Нет. OAuth дает ограниченную авторизацию без передачи многоразового пароля каждому приложению. Риск создают одобрение недоверенного приложения, чрезмерные разрешения, слабое управление или ошибка реализации.

Остановит ли MFA фишинг согласия?

Не полностью. MFA защищает аутентификацию, но не определяет, заслуживает ли приложение разрешения. Пользователь может корректно пройти MFA и одобрить опасный запрос.

Безопасен ли экран на домене Microsoft или Google?

Не обязательно. Страница провайдера может быть настоящей, а запрашивающее приложение — вредоносным. Проверяйте само приложение, издателя, источник перехода, список разрешений и деловую цель.

Чем отличаются делегированные разрешения и разрешения приложения?

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

Удаление приложения отзывает OAuth-доступ?

Не всегда. Удалите серверную связь или разрешение в настройках поставщика идентификации либо организации, а затем подтвердите, что доступ действительно исчез.

Нужно ли менять пароль после подозрительного согласия?

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

Возвратит ли отзыв уже скопированные данные?

Нет. Он блокирует будущий авторизованный доступ, но не стирает прошлый экспорт и выполненные действия. Нужна проверка активности.

Когда обращаться к администратору?

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

Материал объясняет общие риски авторизации. Названия разрешений и поведение отзыва меняются, поэтому используйте актуальные элементы управления провайдера и процедуру своей организации.

Источники

Microsoft Learn — Protect against consent phishing — https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing
Microsoft Learn — Overview of permissions and consent in the Microsoft identity platform — https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview
Google Account Help — Manage links between your Google Account and apps from other developers — https://support.google.com/accounts/answer/13533235?hl=en

Sources checked 28 августа 2026 г.

Что такое фишинг через согласие OAuth?