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

Flash: как отказ от плагина убрал целый класс атак

В январе 2015 года посетитель обычного сайта мог попасть под атаку через рекламный баннер. Реклама перенаправляла браузер на страницу Angler — набора эксплоитов, который подбирал подходящую атаку под установленное ПО. Среди его целей был Adobe Flash Player — отдельный браузерный модуль (плагин) для анимации, видео и интерактивных приложений.

Что не так было с Flash

Одна из используемых тогда уязвимостей Flash получила номер CVE-2015-0311, а Adobe сообщала об атаках на Internet Explorer и Firefox в Windows. При уязвимой версии Flash вредоносная страница могла без дополнительных действий пользователя передать плагину специально подготовленный объект. Исследователи Malwarebytes наблюдали, как Angler после эксплуатации CVE-2015-0311 устанавливал Bedep — вредоносную программу, способную загружать дополнительные компоненты.

Проблема не сводилась только к уязвимостям Flash. Плагины добавляли в браузер сторонний код, а обновлялись не всегда вовремя. На одном компьютере могли оставаться разные версии одного модуля для разных браузеров. Состояние защиты зависело уже не только от версии Chrome, Firefox или Internet Explorer, но и от каждого подключенного компонента.

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

Когда отказались от Flash и что это изменило

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

Adobe прекратила поддержку Flash 31 декабря 2020 года, а 12 января 2021 года заблокировала запуск флеш-содержимого в самом проигрывателе. В актуальных массовых браузерах исчез целый путь атаки через этот компонент. Причиной стало не исправление всех возможных ошибок Flash, а исчезновение самого Flash из обычной архитектуры веба.

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

WizardOpium: как защита браузера разрывает цепочку атаки

Осенью 2019 года исследователи «Лаборатории Касперского» обнаружили вредоносный код на корейскоязычном новостном портале. Посетитель открывал знакомый ресурс, а внедренный сценарий проверял его браузер и ОС. На подходящее устройство сайт загружал эксплоит для уязвимости в WebAudio — браузерном компоненте обработки звука. Кампания получила название Operation WizardOpium.

Первый этап. Захват рендерера

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

Первая уязвимость в цепочке получила номер CVE-2019-13720. Она относилась к классу use-after-free, при котором программа продолжает обращаться к объекту после освобождения занятой им памяти. Освободившийся участок может получить новое содержимое, хотя часть программы все еще воспринимает его как прежний объект. При удачной эксплуатации атакующий получает возможность влиять на данные процесса и добиваться выполнения машинного кода.

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

Песочница — барьер для атакующего

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

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

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

Второй этап. Получение системных привилегий

Для второй задачи Operation WizardOpium использовала еще одну уязвимость. CVE-2019-1458 находилась уже не в Chrome, а в компоненте Windows win32k, связанном с оконной и графической подсистемой. Эксплоит позволял повысить привилегии и выйти за ограничения песочницы. После этого цепочка могла перейти к запуску вредоносной программы с возможностями, которых у рендерера раньше не было.

Успех зависел не только от двух ошибок. Имело значение, доступен ли уязвимый системный компонент из процесса страницы. В Windows 10 Chrome использовал Win32k lockdown, который закрывал рендерерам доступ к системным вызовам win32k. В Windows 7 такого барьера не было. «Лаборатория Касперского» предполагала, что кампания была ориентирована прежде всего на пользователей Windows 7.

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

Что мешает превратить ошибку памяти в устойчивую атаку

Браузерные механизмы безопасности отвечают на вопрос: что сайту разрешено видеть и с чем ему разрешено взаимодействовать? Но у атаки Operation WizardOpium есть и другой уровень. Даже если уязвимость находится внутри рендерера, она не всегда сразу превращается в полный контроль над процессом.

Между ошибкой памяти CVE-2019-13720 и устойчивым выполнением кода стоит отдельный слой защиты, большая часть которого пришла из ОС и компиляторов. Эти механизмы не знают, какой именно сайт открыт во вкладке и какую политику браузер применяет к его данным. Их задача ниже по уровню — сделать так, чтобы повреждение памяти не давало атакующему простой и повторяемый способ управлять выполнением программы. Вот из чего состоит этот защитный слой:

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

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

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

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

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

Spectre: почему запрета читать чужие данные недостаточно

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

Правило одного источника в браузерах

Браузеры давно используют правило одного источника (same-origin policy). Оно запрещает скрипту произвольно читать DOM, ответы и данные документа из другого источника. Это правило работает на уровне логики браузера. Оно решает, что можно отдать коду страницы, а что нельзя, но не гарантирует, что данные разных сайтов физически лежат в разных областях памяти.

До полной изоляции сайтов разные документы могли оказываться в одном рендерере — это касалось не только вкладок. Одна страница часто состоит из нескольких частей: основного документа, рекламных iframe, виджетов, аналитики. Пользователь видит одну страницу, но внутри нее могут работать документы с разных доменов. Даже если браузер соблюдает same-origin policy, данные этих документов все равно могут находиться рядом — в памяти одного процесса.

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

Атаки Spectre и изоляция сайтов

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

Но не все следы исчезают полностью. Некоторые изменения могут остаться в микроархитектурном состоянии процессора, например в кеше. Измеряя задержки последующих обращений к памяти, атакующий при подходящих условиях может восстановить сведения о данных, к которым у него не должно быть доступа. Это не обычный запрос к чужой странице и не прямой обход same-origin policy, а утечка через побочные эффекты вычислений.

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

На этот уровень и переносит защиту site isolation — изоляция сайтов. Разработчики Chrome начали эту работу еще до публичного раскрытия Spectre, но после него механизм стал особенно важен. В Chrome 67 изоляцию включили по умолчанию для почти всех пользователей в Windows, macOS, Linux и ChromeOS.

Идея site isolation в том, что браузер старается не помещать документы разных сайтов в один рендерер. Операционная система уже умеет отделять память одного процесса от памяти другого, и браузер использует эту границу как дополнительный слой защиты. Если вредоносный код выполняется в процессе рекламного iframe, он не должен автоматически получить доступ к памяти основного сайта, потому что основной документ может находиться в другом процессе.

Для пользователя страница при этом почти не меняется. Новостной сайт по-прежнему может показывать рекламный баннер внутри статьи. Но внутри браузера такой баннер может обрабатывать отдельный рендерер, а затем браузер собирает результаты работы нескольких процессов в одно видимое окно. Внешне это одна страница, с точки зрения памяти — уже несколько изолированных областей.

Дополнение изоляции сайтов

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

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

Цена такой защиты — дополнительные ресурсы. При включении полной site isolation на настольных системах Google оценивала рост общего потребления памяти примерно 10–13% в реальных сценариях с большим числом вкладок. Это была плата за более жесткое разделение: браузер стал создавать больше процессов и меньше экономить на совместном размещении документов.

Так Spectre не просто добавил еще одну заплатку в браузер — он показал, что граница между сайтами должна существовать не только в правилах доступа, но и в архитектуре процессов. Same-origin policy отвечает на вопрос: что сайту разрешено читать? А site isolation — на другой: должны ли чужие данные вообще находиться рядом с кодом этого сайта в памяти?

Вредоносное расширение может прийти как обычное обновление

Браузер можно защищать от уязвимостей в его коде, но злоумышленнику не обязательно ломать сам браузер. Можно атаковать компонент, которому уже выдали разрешения. В декабре 2024 года такой точкой стало расширение Cyberhaven. Через фишинг злоумышленники получили возможность опубликовать вредоносную версию легитимного дополнения.

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

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

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

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

Как браузер защищает сессию

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

Firesheep: почему шифровать нужно не только пароль

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

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

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

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

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

CSRF: как поддельный запрос использует авторизованный браузер

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

Межсайтовую подделку такого запроса называют CSRF. Атакующему не обязательно знать cookie. Достаточно заставить браузер жертвы отправить запрос туда, куда cookie прикладывается автоматически.

SameSite задает условия, при которых браузер отправляет cookie в межсайтовом контексте. Явно заданный SameSite=Lax не прикладывает cookie к обычной межсайтовой отправке формы методом POST, но сохраняет ее для некоторых переходов, когда сайт открывается как основная страница.

Механизм не закрывает все варианты подделки запросов. Поддомены могут относиться к одному сайту, а часть переходов с cookie остается разрешенной. Поэтому приложения дополнительно проверяют операции, меняющие данные, например с помощью CSRF-токенов. SameSite появился позже описанного случая с Gmail. Мы рассмотрели эту уязвимость как пример, но сам механизм появился не как ответ на этот конкретный случай.

О входе и не выходе: почему сессию нужно защищать отдельно

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

В расследовании, опубликованном Microsoft в июле 2022 года, описана схема, в которой злоумышленники ставили между пользователем и настоящей страницей входа собственный сервер-посредник. Это называется AiTM (adversary-in-the-middle) — вариант атаки с посредником, к которому пользователь подключается через поддельный адрес. Жертва вводила пароль, проходила многофакторную аутентификацию — подтверждала вход дополнительным способом, например кодом, — а посредник передавал эти данные реальному сервису. Затем он перехватывал сессионный cookie. В отдельных случаях от его кражи до получения доступа к Outlook и подготовки платежного мошенничества проходило около пяти минут.

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

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

• App-bound encryption. Шифрование с привязкой к приложению в Chrome в Windows затрудняет расшифровку cookie сторонней программой, поскольку доступ проверяется не только относительно пользователя, но и относительно приложения. По объяснению Google, это повышает требования к вредоносной программе, которой приходится искать другой доступ, например повышать привилегии или вмешиваться в работу Chrome.

• Device bound session credentials, DBSC. Это механизм привязки сессии к устройству. Браузер использует защищенный ключ устройства, а сервер выдает короткоживущие cookie и требует доказательство владения ключом для их обновления. Копия cookie на другой машине не позволяет неограниченно продлевать доступ. 9 апреля 2026 года Google объявила о публичной доступности DBSC в Chrome для Windows.
  

  

Даже с такой привязкой украденное значение может сохранять пользу до истечения срока, а вредоносная программа на исходном устройстве — пытаться действовать через настоящий браузер. Короткий срок хранения cookie тоже недостаточен сам по себе, поскольку прекращение доступа должен обеспечивать сервер, а не только браузер, удаляющий значение из своего хранилища. Поэтому защита сессии дополняет, но не заменяет безопасность устройства.

ClickFix: когда системную команду запускает сам пользователь

В марте 2025 года Microsoft описала кампанию, которую наблюдала с декабря 2024 года. Сотрудникам гостиниц приходили письма под видом уведомлений Booking.com. Ссылка вела на страницу с поддельной капчей:

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

В описанной кампании команда запускала вредоносный код через системную программу mshta.exe. Разные варианты доставляли в том числе Lumma Stealer и средства удаленного управления.

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

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

Что изменилось в модели безопасности браузера

История браузерной защиты складывается из разных этапов. Отказ от Flash убрал целый сторонний компонент, который годами расширял поверхность атаки. Песочница отделила захваченный рендерер от ОС. V8 Sandbox и механизмы защиты памяти добавили препятствия еще до выхода из процесса. Site isolation изменила положение данных разных сайтов в памяти и перенесла часть межсайтовой границы на уровень процессов. HTTPS закрыл простой перехват сессий в сети. SameSite ограничил автоматическую отправку cookie в части межсайтовых запросов. Passkeys изменили модель подтверждения входа, а app-bound encryption и DBSC начали усиливать защиту уже созданной сессии.

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

Современный браузер старается не позволить одному такому событию автоматически дать доступ ко всему остальному:

• Код страницы получает ограниченные полномочия.

• Разные сайты разделяются сильнее, чем раньше.

• Секреты защищаются не только при входе, но и после него.

• Часть проверок переносится из потенциально уязвимого процесса в более привилегированные компоненты.

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

Авторы: специалисты по исследованию веб-угроз команды BI.ZONE WAF Анастасия Кабирова и Никита Проказов