Как защититься от атак через уязвимости в Microsoft Edge WebView2

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

Почему WebView2 — это цель

WebView2 используется десятками приложений: от корпоративных мессенджеров до клиентов облачных сервисов. Внутри него работает практически полноценный браузер — с поддержкой JavaScript, доступом к файловой системе (если разработчик не ограничил), сетевыми запросами и взаимодействием с хост-приложением через WebMessage. Именно эта связка «браузер ↔ приложение» и становится вектором атаки.

Что делает WebView2 привлекательным для атакующих:

• Пользователи часто доверяют содержимому внутри приложения больше, чем в обычном браузере — это «корпоративная среда», значит, безопасно.
• Приложение может быть запущено с повышенными привилегиями.
• Встроенный браузерный движок обновляется отдельно от самого приложения — и не всегда вовремя.
• Через WebMessage и postMessage можно передавать данные между веб-контентом и хостом, и если эти данные не валидируются — это прямой путь к инъекциям.

Основные векторы атак

1. Уязвимости в движке Chromium

WebView2 базируется на движке Edge (Chromium). А в Chromium регулярно находят уязвимости — от use-after-free в V8 до проблем с песочницей. Проблема в том, что даже если ваш код идеален, уязвимость в самом движке может позволить выполнить код в процессе приложения.

Пример: в 2023–2024 годах было несколько CVE, связанных с V8 и обработкой WebAssembly. Атакующий мог создать веб-страницу, которая при открытии в WebView2 выполняла произвольный код вне песочницы.

2. Небезопасная интеграция с хост-приложением

Это самый частый и самый предотвратимый вектор. Разработчик добавляет WebView2, включает WebMessageReceived и обрабатывает сообщения от веб-контента — без должной проверки. В итоге вредоносная страница может отправить сообщение, которое приложение выполнит как команду.

Типичные ошибки:

• Принимаются сообщения от любого источника без проверки Source или Origin.
• Данные из сообщения подставляются в SQL-запросы, команды ОС или пути файлов без санитизации.
• Через сообщения передаются токены или пароли, которые могут быть перехвачены.

3. Загрузка непроверенного контента

Если ваше приложение может открыть любой URL внутри WebView2 — это риск. Пользователь (или атакующий через фишинг) может загрузить страницу с вредоносным скриптом, который попытается взаимодействовать с хост-приложением или использовать уязвимости движка.

4. Устаревшая версия WebView2 Runtime

Многие приложения работают с фиксированной версией WebView2 или полагаются на установленный у пользователя Runtime. Если Runtime устарел — все известные патчи безопасности не применены. Это как использовать Chrome двухлетней давности и удивляться вирусам.

Что делать: практические методы защиты

Обновляйте WebView2 Runtime

Это база. Без этого все остальные меры теряют смысл.

1. Если используете фиксированную версию (Fixed Version) — встройте в процесс сборки проверку актуальности и обновляйте при выходе патчей безопасности.
2. Если используете Evergreen Runtime — проверяйте версию при запуске приложения и уведомляйте пользователя, если она устарела.
3. В корпоративной среде — настройте централизованное управление версией Runtime через групповые политики или MDM.

Ограничьте возможности WebView2

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

Что отключить, если не используете:

• AreDefaultScriptDialogsEnabled — диалоговые окна JavaScript (alert, confirm, prompt).
• IsStatusBarEnabled — строка статуса (может использоваться для фишинга).
• AreDevToolsEnabled — инструменты разработчика в продакшене.
• IsZoomControlEnabled — управление зумом (не влияет на безопасность напрямую, но уменьшает поверхность).
• AreDefaultContextMenusEnabled — контекстное меню.

Настройки задаются через CoreWebView2Settings после инициализации:

await coreWebView2.EnsureCoreWebView2Async();
coreWebView2.Settings.AreDefaultScriptDialogsEnabled = false;
coreWebView2.Settings.AreDevToolsEnabled = false;

Контролируйте, что загружается

Не позволяйте WebView2 открывать что угодно. Реализуйте белый список разрешённых доменов.

private void CoreWebView2_NavigationStarting(object sender, CoreWebView2NavigationStartingEventArgs args)
{
    var uri = new Uri(args.Uri);
    var allowedDomains = new[] { "https://app.yourcompany.com", "https://login.yourcompany.com" };
    
    if (!allowedDomains.Any(d => uri.AbsoluteUri.StartsWith(d)))
    {
        args.Cancel = true;
        // Открыть во внешнем браузере
        Process.Start(new ProcessStartInfo(args.Uri) { UseShellExecute = true });
    }
}

Безопасная работа с WebMessage

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

1. Проверяйте Origin. Перед обработкой сообщения убедитесь, что оно пришло с ожидаемого домена.
2. Не доверяйте данным. Всё, что приходит из веб-контента — потенциально вредоносное. Валидируйте, санитизируйте, экранируйте.
3. Не передавайте чувствительные данные в веб-контент. Токены, пароли, ключи — всё это не должно уходить в DOM.

private void CoreWebView2_WebMessageReceived(object sender, CoreWebView2WebMessageReceivedEventArgs args)
{
    var origin = args.Source;
    // Проверяем, что сообщение пришло с нашего домена
    if (!origin.StartsWith("https://app.yourcompany.com")) return;
    
    string message = args.TryGetWebMessageAsString();
    // Парсим строго по ожидаемой схеме, не доверяем входным данным
    // Никаких eval, подстановок в команды или SQL

Настройка песочницы и политик

WebView2 запускает рендерер в песочнице — и это хорошо. Но нужно убедиться, что она реально работает:

• Не запускайте приложение с правами администратора без крайней необходимости.
• Убедитесь, что на уровне ОС включены все механизмы защки: ASLR, DEP, CFG (для Windows).
• Если возможно — используйте AppContainer или аналогичные механизмы для изоляции процесса.

Сравнение подходов к защите

Что выбрать в зависимости от ситуации

Если вы разработчик приложения с WebView2: начните с обновления Runtime и отключения всего ненужного. Это делается за час, а закрывает большинство известных CVE. Затем — белый список доменов и валидация WebMessage. Это ваш минимум.

Если вы используете чужое приложение с WebView2: проверьте версию Edge WebView2 Runtime на своей машине. Откройте edge://version в Edge и посмотрите версию. Если приложение давно не обновлялось — это красный флаг. Обратитесь к разработчику с вопросом, какую версию Runtime использует приложение.

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

Частые ошибки

«Мы просто показываем веб-страницу, тут нечего защищать». Показывать веб-страницу через WebView2 — это как встроить браузер в ваше приложение. Если страница скомпрометирована (например, через XSS на легитимном сайте) — атакующий получает доступ к вашему приложению со всеми его возможностями.

• Приём сообщений от любого источника. Если вы не проверяете Origin в WebMessageReceived — любой сайт, открытый в WebView2 (или через iframe), может отправлять сообщения вашему приложению.
• Использование WebView2 для отображения пользовательского HTML без санитизации. Если вы берете текст от пользователя и отображаете его черей NavigateToString — это XSS в контексте вашего приложения.
• Хардкод токенов в JavaScript. Некоторые разработчики передают токены авторизации через ExecuteScriptAsync или PostWebMessageAsString. Если вредоносный скрипт попадёт в WebView2 — он получит эти токены.
• Игнорирование обновлений Runtime. Фиксированная версия WebView2, встроенная в приложение полгода назад, может содержать уже известные и эксплуатируемые уязвимости.
• Отключение песочницы «для отладки» и забытие включить обратно. Были случаи, когда разработчики отключали песочницу для решения проблем с файловой системой и забывали вернуть её перед релизом.

Как лучше сделать: чек-лист

1. Runtime обновлён до последней версии — проверено.
2. Отключены DevTools, диалоги JS, строка статуса — всё, что не нужно в продакшене.
3. Реализован белый список доменов для навигации.
4. WebMessage проверяется на Origin и валидируется по схеме.
5. Чувствительные данные не передаются в веб-контент.
6. Пользовательский HTML санитизируется перед отображением через NavigateToString.
7. Приложение не запускается с повышенными привилегиями без необходимости.
8. Настроен мониторинг обновлений WebView2 Runtime для корпоративных пользователей.
9. Content Security Policy настроен для загружаемого контента.

Инструменты для проверки

• Edge DevTools — подключитесь к WebView2 через --remote-debugging-port для отладки и проверки сетевых запросов.
• Process Explorer — проверьте, в каком песочнице работает процесс рендерера.
• WebView2 Sample App — официальный пример от Microsoft, где можно посмотреть правильную настройку безопасности.
• Microsoft Security Response Center — отслеживайте CVE, связанные с Edge и WebView2.

Итог

WebView2 — мощный инструмент, который привносит в ваше десктопное приложение всю мощь и все риски Chromium. Главные три вещи, которые нужно сделать: обновляйте Runtime, не доверяйте веб-контенту и контролируйте взаимодействие между браузером и приложением. Если вы делаете только эти три вещи — вы уже защищены лучше, чем 80% приложений с WebView2, которые я видел в реальной практике.

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