Атака Browser-in-the-Browser: как работает и как защититься

Что такое атака Browser-in-the-Browser

Атака Browser-in-the-Browser (BitB) создаёт внутри веб-страницы визуальную копию окна браузера. Поддельное окно рисуют средствами HTML и CSS: поддельная адресная строка, иконки, кнопки и элементы управления делают его очень правдоподобным. Мошенник может отобразить точный текст URL, например accounts.google.com, чтобы вызвать доверие и забрать учётные данные при вводе.

Короткое определение термина: BitB — это фишинговая техника, при которой веб-страница изображает второе окно браузера, не создавая реального системного окна.

Атака чаще всего нацелена на всплывающие окна авторизации (pop-up OAuth). У этих всплываек небольшой размер и они не убирают фокус с основной страницы, что позволяет легко подменить внешний вид без видимых переходов. Но BitB может также имитировать полноэкранное окно, если злоумышленник хочет полностью захватить внимание пользователя.

Важно: BitB долгое время был прототипом, но затем превратился в массовый инструмент, в том числе доступный в наборе фишинга как услуга (PhaaS). Это значит, что атаки становятся доступнее и масштабнее.

Как работает атака: пошагово

1. Жертве показывают страницу со ссылкой на «войти через третью сторону» или кнопку социального входа.
2. Вместо реального системного pop-up злоумышленник открывает обычную страницу или div-слой, стилизованный под окно браузера.
3. Поддельная адресная строка показывает корректный адрес и «замок», чтобы обмануть пользователя.
4. Пользователь вводит логин и пароль — данные отправляются злоумышленнику.
5. Злоумышленник может немедленно использовать учётные данные или перепродать доступ.

Технические приёмы, которые применяются чаще всего: абсолютное позиционирование, фиксированные слои, подделка теней и иконок, скрытие системных признаков активности окна.

Признаки атаки BitB

Даже очень правдоподобное поддельное окно даёт подсказки. Проверяйте следующие признаки:

• Всплывающее окно открывается моментально при клике. Реальные системные окна обычно имеют небольшую задержку и анимацию.
• Нет системной анимации открытия окна. У большинства ОС и браузеров при появлении окна есть визуальные переходы.
• На Windows в панели задач при появлении реального окна иконка браузера изменяется на «складки» или «стек» — поддельное окно этого не сделает.

• Поддельному окну может не хватать тени, или тень будет некорректной. Тень помогает глазу понять, что окно действительно поверх остальных элементов.
• Элементы окна (шрифты, отступы, иконки) могут отличаться. Часто разработчики фейковых окон неправильно воспроизводят системные шрифты.

Важно: менее опытные злоумышленники допускают ошибки в мелких UI-деталях — это первое место, где можно найти подсказку.

Как взаимодействовать с элементами, чтобы обнаружить BitB

BitB полагается на пассивное восприятие UI. Если вы начнёте взаимодействовать, подделка быстро обнаружится:

• Попробуйте перетащить окно — поддельное окно не выйдет за пределы вкладки и не станет отдельным системным окном.
• Нажмите в адресную строку и попытайтесь ввести текст. Подделка не позволит вставить текст в системную адресную строку.
• Щёлкните правой кнопкой по адресной строке: системное окно открывает контекстное меню адресной строки, подделка — нет.
• Нажмите на иконку «замок» в адресной строке, чтобы посмотреть сертификат и подробности TLS. Подделка обычно не раскрывает системную панель сведений о соединении.

• Кликните по области вне всплывающего окна: у реального системного окна фокус переключится, у поддельного — может остаться прежним.

Если вы сомневаетесь, закройте вкладку и откройте сайт вручную через адресную строку. Не вводите пароли до тех пор, пока не убедитесь, что окно — реальное.

Избегайте метода входа через всплывающее окно

Метод входа через всплывающее окно (pop-up OAuth) устарел и чаще подвержен злоупотреблениям. Он часто зависит от третьих cookies и сложнее безопасно реализуется в браузерах с усиленной политикой приватности. Редирект-метод (перенаправление на страницу авторизации поставщика и возврат обратно) надёжнее.

Если веб-сайт использует pop-up и предлагает выбор, лучше:

• Использовать альтернативный способ входа (redirect) если он есть.
• Не использовать «Войти через» на подозрительных сайтах.
• Если вынуждены пользоваться всплывающим окном, проверьте окно на признаки подделки (см. выше).

Используйте автозаполнение и менеджеры паролей

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

Рекомендации по использованию менеджера паролей:

• Храните пароли в надёжном менеджере (KeePass, Bitwarden, 1Password и т. п.).
• Не копируйте вручную и не храните пароли в текстовых файлах.
• Включите автозаполнение только для доверенных сайтов.

Важно: встроенные автозаполнения удобны, но автономные менеджеры дают больше контроля и функций (например, уникальные поля для заполнения и защита мастер‑паролем).

Используйте методы аутентификации, устойчивые к фишингу

Двухфакторная аутентификация (2FA) снижает риск, но не все реализации равны по безопасности.

• OTP по SMS или через приложение может быть перехвачен при быстрой атаке BitB.
• Prompt-based 2FA (например, push-уведомление от официального приложения) устойчивее, так как требует подтверждения на зарегистрированном устройстве.
• Наиболее надёжный вариант — аппаратные ключи (FIDO2 / WebAuthn) и passkey (безпарольная аутентификация). Они защищают от фишинга, поскольку привязаны к домену и не отсылают креденшалы на поддельный сайт.

Совет: переведите важные аккаунты на WebAuthn или аппаратные ключи там, где это возможно.

Рекомендации для разработчиков и администраторов

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

• Используйте редирект-метод OAuth вместо pop-up, когда это возможно.
• Внедрите PKCE (Proof Key for Code Exchange) для публичных клиентов.
• Установите корректные заголовки CSP (Content Security Policy) для ограничения инъекций и подложных скриптов.
• Активируйте заголовки X-Frame-Options или frame-ancestors (CSP) там, где фреймы не нужны, чтобы предотвратить clickjacking.
• Покажите пользователям явные инструкции: «Мы всегда перенаправляем вас на страницу провайдера. Если видите всплывающее окно — закройте и повторите вход».
• Логируйте необычные события авторизации: множественные попытки в короткий срок, попытки с неизвестных User-Agent/реферера.

Короткая методика для команды разработки:

1. Пересмотреть поток OAuth и по возможности отказаться от pop-up.
2. Тестировать поведение в браузерах с отключёнными визуальными эффектами.
3. Добавить в интерфейс подтверждающие подсказки и рекомендации по безопасности.

Чеклисты по ролям

Чеклист для пользователя:

• Не вводите пароль в внезапном окне. Проверяйте адресную строку.
• Попробуйте взаимодействовать с адресной строкой и перетащить окно.
• Используйте менеджер паролей и аппаратные ключи.
• Если сомневаетесь — закройте вкладку и откройте сайт вручную.

Чеклист для разработчика продукта:

• Откажитесь от pop-up OAuth, если можно.
• Внедрите PKCE и строгие CORS/CSP политики.
• Добавьте в интерфейс предупреждение о безопасности при третьих входах.
• Тестируйте на предмет UI-подделок (автоматические сканеры и ручной ревью).

Чеклист для отдела безопасности/ИТ:

• Мониторьте массовые фишинговые кампании, в том числе PhaaS.
• Распространяйте инструкции для сотрудников по выявлению BitB.
• Разработайте инцидентный план на случай утечки учётных данных.

Методика тестирования и минимальные тест-кейсы

Мини‑методология для пентестера и QA:

• Подготовить сценарий pop-up и редирект для авторизации.
• Создать контролируемую подделку BitB и попытаться произвести ввод учетных данных.
• Проверить поведение менеджеров паролей при подделке.
• Проверить, раскрываются ли сведения о TLS (щелчок по замку) в подделке.
• Тестировать на разных ОС и с разными визуальными эффектами (включён/выключён GPU-ускоритель, отключены анимации).

Критерии приёмки:

• Сайт по умолчанию использует редирект для OAuth.
• Менеджерам паролей не удаётся автоматически заполнить формы на поддельных страницах.
• Пользовательский интерфейс содержит инструкцию/предупреждение о стороннем входе.

Инцидентный план и восстановление после компрометации

Если вы подозреваете утечку учётных данных:

1. Немедленно смените пароль на официальном сайте, используя ручной ввод адреса.
2. Отключите сторонние ключи/сессии в настройках безопасности аккаунта.
3. Включите аппаратную 2FA (если доступно).
4. Просмотрите логи активности и сообщите о подозрительных сессиях поставщику услуги.
5. Если компрометация корпоративного аккаунта — задокументируйте и запустите внутренний инцидентный процесс.

Важно: меняя пароль, используйте надёжный менеджер паролей и не вводите новый пароль в том же окне, где произошёл инцидент.

Когда BitB не сработает: обратные примеры

BitB с высокой вероятностью не сработает, если:

• Пользователь использует аппаратные ключи WebAuthn. Ключ не авторизует запросы с поддельного домена.
• Менеджер паролей не находит совпадения домена и не подставляет пароль.
• Браузер или ОС отображает явные системные панели, которые невозможно подделать через HTML/CSS.

Контрпример: если пользователь автоматически копирует и вставляет пароль из менеджера в поддельную форму, защита «домена» ломается — поведение пользователя важнее технологии.

Правовые и вопросы приватности

При выборе сторонних аутентификаторов и попапов учитывайте требования конфиденциальности и локальные законы (например, GDPR в ЕС). Использование сторонних провайдеров авторизации может означать передачу идентификаторов и адресов электронной почты третьим лицам. Документируйте такие передачи и обновляйте политику конфиденциальности.

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

Диаграмма решений для пользователя

flowchart TB
  A[Нажали 'Войти через' на сайте] --> B{Открылось всплывающее окно?}
  B -- Нет --> C[Перенаправление: открыть вручную и войти]
  B -- Да --> D{Появились сомнения в окне?}
  D -- Да --> E[Не вводить данные, закрыть вкладку]
  D -- Нет --> F{Менеджер паролей предлагает автозаполнение?}
  F -- Да --> G[Безопасно: форма соответствует домену менеджера]
  F -- Нет --> E
  G --> H[Проверить 2FA: аппаратный ключ или prompt]
  H --> I[Если всё верно — продолжить]

1‑строчный глоссарий

• BitB: визуальная подделка окна браузера внутри страницы с целью фишинга.
• PKCE: расширение OAuth для публичных клиентов, защищающее обмен кодом авторизации.
• WebAuthn/FIDO2: стандарт для безпарольной аутентификации с аппаратной привязкой к домену.

Краткая сводка

• BitB — опасная, но обнаружимая фишинговая техника.
• Проверяйте фокус, адресную строку и поведение окна.
• Используйте менеджеры паролей и аппаратные 2FA для защиты.
• Разработчики должны избегать pop-up OAuth и укреплять политики CSP/PKCE.

Важно: при малейших сомнениях — не вводите данные. Закройте вкладку и войдите на сайт через адресную строку вручную.

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

Как быстро отличить поддельное окно от реального?

Попробуйте перетащить окно или кликнуть в адресную строку и ввести текст. Если окно не реагирует как системное, оно, вероятно, поддельное.

Поможет ли менеджер паролей против BitB?

Да. Надёжный менеджер паролей обычно автозаполняет данные только на совпадающих доменах и тем самым предотвращает автоматическую подстановку в поддельные формы.

Защитит ли SMS‑код от BitB?

SMS и другие OTP менее устойчивы: злоумышленник может получить код и быстро использовать его. Аппаратные ключи и passkey более надёжны.

Что должны сделать разработчики прямо сейчас?

Перейти на редирект‑модель авторизации, внедрить PKCE, настроить CSP и информировать пользователей о безопасных сценариях входа.