“Многие в ИТ считают безопасность браузера задачей для пользователей. Но когда механизмы удобства прямо в коде браузера создают слепые зоны, угроза становится организационной. Допуск бухгалтерии к операциям с деньгами через обычный браузер, это брешь, о которой не пишут в 152-ФЗ, но которая обходится компаниям в сотни тысяч” .

Мы потеряли 300 тысяч из-за автозаполнения в браузере бухгалтера

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

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

Как браузер «помогает» и что он запомнил

Функция автозаполнения (autofill), это не просто сохранение логина и пароля. Современные браузеры стремятся запомнить всё, что может ускорить взаимодействие пользователя с формой.

Основные категории данных, которые браузеры часто сохраняют для автозаполнения:

• Учётные данные: логины, пароли (часто с предложением их сохранить).
• Платёжная информация: номера банковских карт, имена держателей, сроки действия, CVC/CVV коды (зависит от настроек и версии браузера).
• Адреса: как почтовые, так и адреса для выставления счетов.
• Персональные данные: ФИО, номера телефонов, email.
• Данные форм: любое значение, введённое в поле input, которое браузер посчитал повторяющимся или стандартным. Ключевой момент: браузер часто не делает различий между сайтом условного интернет-магазина и корпоративным банк-клиентом. Его задача — запомнить данные и подставить их в поля с похожими атрибутами (name="card-number", type="tel" и т.д.). Более того, если сотрудник ранее вводил данные платёжной карты компании для, например, оплаты облачного сервиса, браузер может «предложить» эти же реквизиты для поля «номер счёта получателя» в банковской системе.

Сценарий атаки: когда удобство становится вектором

Стандартный сценарий компрометации сессии (через XSS или кражу cookies) здесь не нужен. Атака может быть проще и использовать легитимные функции.

1. Подготовка. У сотрудника (бухгалтера) в браузере сохранены данные для авторизации в критичных сервисах (банк, ГИС, отчётность) и, возможно, реквизиты карт.
2. Фишинг или легитимный, но уязвимый сайт. Сотрудник переходит по ссылке, это может быть фишинговое письмо, маскирующееся под внутренний сервис, или даже вполне легитимный, но малоизвестный отраслевой портал, требующий регистрации. Сайт содержит обычную форму.
3. Срабатывание автозаполнения. При клике на первое поле формы (например, «Email») браузер, стремясь помочь, автоматически заполняет не только его, но и все остальные скрытые (type="hidden") или невидимые для пользователя поля, которые разработчики страницы могли добавить в форму.
   • «
   • «
   • «
4. Отправка данных. Сотрудник, ничего не подозревая, вводит в форму только видимые поля (например, имя для регистрации) и нажимает «Отправить». Вместе с этими данными на сервер злоумышленника отправляются все автоматически подставленные браузером чувствительные данные. В нашем случае произошло иное, но схожее по духу: бухгалтер, заполняя форму перевода в банк-клиенте, использовал автозаполнение для поля «Счёт получателя». Браузер подставил туда не номер контрагента, а номер корпоративной карты, который ранее был сохранён для онлайн-оплат. Из-за схожести структуры поля (просто числовой ввод) браузер не отличил счёт от номера карты. Деньги ушли на карту, с которой их оперативно обналичили. Транзакцию оспорить не удалось — операция была подтверждена одноразым паролем с привязанного телефона, который был у бухгалтера.

Почему это сложно предотвратить стандартными мерами

Типичные меры ИБ в корпоративной среде часто не работают против таких сценариев.

• DLP-системы (Защита от утечек). Настроены на перехват конфиденциальных данных по каналам (email, веб). Но если данные покидают рабочий компьютер не в виде файла или текста письма, а в виде автоматически подставленных значений в HTTP-запросе к (на первый взгляд) легитимному сайту, DLP может не сработать.
• Антивирусы и EDR. Не отслеживают логику работы встроенных функций браузера. Для них автозаполнение, это штатная операция.
• Политики 152-ФЗ и ФСТЭК. Сосредоточены на защите информационных систем (ИС) и персональных данных. Они регламентируют шифрование, контроль доступа, аудит событий внутри самих ИС. Но они почти не регулируют то, что происходит на рабочем месте пользователя до отправки запроса в систему. Конфигурация рабочего места (ПК) и правила его использования — часто остаются на усмотрение организации.
• Запрет сохранения паролей в браузере. Частая организационная мера. Но она не отключает автозаполнение для других типов данных: платёжных реквизитов, адресов, телефонов. Эту функцию нужно отключать отдельно, на уровне групповых политик или с помощью специального ПО для управления браузерами.

Что можно сделать: практические шаги для ИТ-отдела

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

1. Сегментация доступа и выделенные рабочие места. Операции с финансами, работа с ГИС и другими критичными госсервисами должны выполняться не из общего браузера на основном рабочем ПК. Решения:

   • Выделенный физический или виртуальный АРМ (автоматизированное рабочее место) с жёстко настроенным, «стерильным» браузером, где отключены все функции сохранения данных.
   • Использование защищённых браузеров, встроенных непосредственно в ПО банк-клиентов (если банк предоставляет такое решение).
   • Работа через удалённый доступ (VDI) на специально подготовленном образе системы.

2. Централизованное управление настройками браузеров. Запретить сохранение данных средствами пользователя недостаточно. Необходимо применять групповые политики (GPO) для браузеров, используемых в организации.

   • Для Chrome/Chromium: политики PasswordManagerEnabled, AutofillAddressEnabled, AutofillCreditCardEnabled выставить в false.
   • Аналогичные политики существуют для Firefox и Edge. Конфигурация должна распространяться на все рабочие станции.

3. Техническая защита на стороне веб-сервисов. Разработчикам внутренних и критичных коммерческих сервисов (банки, отчётность) следует использовать атрибуты HTML, явно указывающие браузеру не запоминать данные.

   • Атрибут autocomplete="off" для всей формы или ключевых полей (номера счетов, логины, одноразовые коды).
   • Использование autocomplete="new-password" для полей с паролями, чтобы браузер не предлагал старые сохранённые варианты.
   • Важно: современные браузеры иногда игнорируют autocomplete="off" ради удобства пользователя. Поэтому это мера должна дополняться, а не заменять другие.

4. Создание и доведение регламентов. Чёткие инструкции для сотрудников финансовых отделов:

   • Запрет на использование основного браузера для финансовых операций.
   • Обязательное использование режима инкогнито/приватного просмотра при работе с внешними сервисами, если нет выделенного АРМ.
   • Правило «чистых сессий»: выход из аккаунтов по окончании работы, а не просто закрытие вкладки.
   • Регулярная очистка кеша и данных браузера на выделенных АРМ.

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