Push-фишинг в банковских приложениях: методы защиты от атак

Если злоумышленник уже получил пароль, он способен запустить серию попыток входа и отправлять push-запросы на устройство клиента. Расчёт простой: человек устанет от сигналов или примет один из них за штатное действие.

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

Механика атаки: от украденного пароля до подтверждения

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

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

Другой сценарий использует браузерные и мобильные уведомления. Через API Notifications и Push можно показывать всплывающие баннеры, стилизованные под сообщения банка или операционной системы. В баннере может быть ссылка на страницу, где просят войти в онлайн-банк, подтвердить личность или разблокировать аккаунт. Если пользователь вводит там пароль, данные уходят мошенникам.

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

На практике атаки разделяются по тому, что именно пытаются получить:

Таблица показывает важное различие. При MFA Fatigue атакующий добивается одобрения входа. При поддельном баннере он стремится похитить данные. В APP-сценарии пользователь может войти в настоящий банк и самостоятельно отправить деньги на указанные мошенником реквизиты. Один универсальный фильтр эти задачи не закрывает.

Почему частые запросы работают

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

По данным исследований МТС RED и Phishman, около 80% киберинцидентов связаны с человеческим фактором. Эту цифру не следует трактовать как долю атак, которые можно предотвратить обучением. Она указывает на системную роль действий пользователя, но не отменяет ответственности архитектуры: если интерфейс предлагает подтверждать запрос без контекста, ошибка становится предсказуемой.

Признаки подозрительной ситуации обычно видны не в одном сообщении, а в последовательности событий:

• push-запросы приходят, хотя пользователь не входил в приложение и не начинал восстановление доступа;
• уведомления повторяются после отказа или игнорирования;
• сообщение торопит, угрожает блокировкой либо предлагает срочно «защитить счёт»;
• ссылка ведёт в браузер, где снова запрашивают банковский пароль;
• текст баннера не совпадает с тем, что отображается внутри официального приложения.

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

Push-запрос без инициированного пользователем входа — событие безопасности. Его нельзя трактовать как обычное уведомление, которое нужно убрать с экрана.

Number Matching: контекст вместо кнопки

Один из способов снизить риск случайного одобрения — сопоставление чисел, или Number Matching. При входе система показывает число на экране авторизации. Пользователь должен выбрать или ввести то же число в приложении-аутентификаторе. Простое нажатие «Разрешить» перестаёт быть достаточным действием.

Механика добавляет контекст в подтверждение:

1. Пользователь начинает вход на сайте или в приложении.

2. Система отображает запрос и контрольное число.

3. На доверенном устройстве появляется запрос с числом для сопоставления.

4. Пользователь сверяет значения и подтверждает только совпадающую попытку.

5. Сервер связывает подтверждение с конкретной сессией входа.

Если злоумышленник запускает вход параллельно, пользователь не должен выбирать число наугад. Однако Number Matching не превращает украденные учётные данные в безопасные. Метод уменьшает вероятность бездумного одобрения и затрудняет массовую атаку, но результат зависит от реализации: насколько понятно показаны сведения о входе, как система ограничивает повторные запросы и можно ли сопоставить подтверждение с нужной сессией.

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

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

FIDO2 и аппаратные ключи

Следующий уровень — криптографическая аутентификация с использованием FIDO2. В отличие от push-подтверждения, где пользователь одобряет запрос в приложении, FIDO2 связывает аутентификатор с конкретным веб-доменом. Это затрудняет фишинг через поддельную страницу: ключ не должен подтвердить вход на домене, отличном от зарегистрированного.

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

Архитектурно переход обычно затрагивает несколько компонентов:

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

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

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

APP-мошенничество и транзакционные уведомления

В APP-сценарии клиент сам подтверждает перевод, но делает это под влиянием обмана. По данным британского PSR, в 2022 году на мошенничество с авторизованными push-платежами пришлось 40% финансовых потерь от мошенничества в Великобритании. Показатель относится к конкретному рынку и периоду; его нельзя автоматически переносить на другие страны или трактовать как долю всех банковских атак.

Транзакционное уведомление должно помогать проверить действие, а не просто сообщать, что оно произошло. Для оценки операции клиенту нужны как минимум сумма и понятные сведения о получателе. Если уведомление предлагает перейти по ссылке и «отменить» перевод на внешней странице, это повод остановиться. Банк не должен строить критичный процесс защиты вокруг перехода по ссылке из баннера.

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

Те же требования относятся к цифровым платформам за пределами банков. Чем больше городских и финансовых сервисов переводят взаимодействие в приложения и уведомления, тем важнее разделять информационные сообщения и команды, меняющие данные или запускающие операцию. Например, цифровые сервисы планирования городской поездки описаны в материале о платформе «Умный город» и планировании путешествий в Беларуси. Для любой такой платформы принцип одинаков: уведомление должно вести в проверяемый сервис, а чувствительное действие — требовать подтверждения в надёжном контексте.

Практическая модель защиты

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

Для банка рабочая последовательность выглядит так:

1. Ограничить частоту запросов и прекращать серию после отказов или тайм-аута.

2. Привязать подтверждение к конкретной сессии, используя Number Matching или более сильный фактор.

3. Разделить уведомления о событиях и подтверждения входа или платежа.

4. Анализировать необычные комбинации устройства, времени, сетевого контекста и последовательности действий.

5. Предусмотреть безопасное восстановление доступа, не слабее основного сценария аутентификации.

6. Давать клиенту понятный путь реагирования без перехода по ссылкам из подозрительного сообщения.

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

Безопасность push-уведомлений в необанках определяется всей цепочкой: хранением учётных данных, серверными лимитами, привязкой подтверждения к сессии, защитой восстановления и обработкой платежей. Number Matching снижает риск механического одобрения. FIDO2 усложняет фишинг учётных данных. Ни один из этих методов не закрывает социальную инженерию вокруг добровольного перевода. Стоимость защиты складывается не только из внедрения аутентификатора, но и из поддержки, мониторинга и безопасных процедур восстановления.