Кража сессионных cookies долгое время оставалась одним из самых неприятных способов угона аккаунтов. Схема простая: пользователь случайно ставит себе инфостилер вроде Lumma, Vidar Stealer или Atomic, малварь вытягивает из браузера сессионные токены и отправляет их на сервер злоумышленника. Дальше эти токены пакуют и перепродают другим атакующим. Пароль вводить не нужно, двухфакторка не спасает — куки часто живут долго, и по ним можно зайти в аккаунт напрямую.
Google решила бороться с этим на аппаратном уровне. Ещё в апреле 2024 года компания анонсировала механизм под названием Device Bound Session Credentials (DBSC). Какое-то время он работал в открытой бете. А теперь, с выходом Chrome 146, DBSC доступен всем без исключения пользователям Windows.
Суть технологии в следующем. При включённом DBSC браузер генерирует уникальную пару криптографических ключей — публичный и приватный. Приватный ключ создаётся внутри аппаратного модуля безопасности: на Windows это TPM (Trusted Platform Module), на macOS планируется использовать Secure Enclave. Ключ нельзя экспортировать, скопировать или прочитать программно. Он физически привязан к конкретному устройству.
Когда сервер выдаёт сессионную куку, он делает это только после того, как Chrome докажет владение приватным ключом. Выданные куки при этом живут очень недолго. Если злоумышленник их украдёт, они быстро протухнут. А обновить их без приватного ключа, который остаётся на устройстве жертвы, невозможно. Фактически украденные куки превращаются в бесполезный мусор.
Разработчики позаботились и о совместимости. Если на устройстве пользователя нет TPM или другого защищённого хранилища ключей, DBSC просто не активируется, и браузер работает с куками по-старому. Ничего не ломается, логин не перестаёт работать.
Отдельно стоит сказать про приватность. Команды Chrome и Account Security в Google проектировали DBSC так, чтобы механизм не создавал новых возможностей для слежки. Для каждой сессии используется отдельный ключ, сайты не могут сопоставлять активность пользователя между разными ресурсами или даже между сессиями на одном и том же сайте. Протокол не передаёт серверу идентификаторы устройства или данные аттестации — только публичный ключ текущей сессии. Кросс-сайтовый трекинг и фингерпринтинг устройства через DBSC невозможны.
Стандарт разрабатывался не в вакууме. Google привлекла к работе Microsoft, и обе компании планируют продвигать DBSC как открытый веб-стандарт, доступный для любых браузеров и сервисов.
По данным Google, уже на этапе бета-тестирования наблюдалось заметное снижение количества успешных краж сессий. Конкретных цифр компания пока не раскрывает, но формулировка «significant reduction» в их посте, опубликованном в четверг, звучит обнадёживающе.
Что дальше? Расширение на macOS запланировано на один из ближайших релизов Chrome. Кроме того, Google намерена адаптировать DBSC для более широкого спектра устройств и добавить расширенные возможности для корпоративных сред, где массовая кража сессий особенно болезненна.
Пока DBSC работает только при наличии TPM и только на Windows с Chrome 146. Это значит, что пользователям Linux, старых машин без TPM или других браузеров пока рассчитывать не на что. Но сам подход — привязка сессии к железу, а не к файлу в папке профиля — выглядит как давно назревший шаг. Стилеры, конечно, никуда не денутся, но торговать украденными куками станет куда менее выгодно.
Изображение носит иллюстративный характер
Google решила бороться с этим на аппаратном уровне. Ещё в апреле 2024 года компания анонсировала механизм под названием Device Bound Session Credentials (DBSC). Какое-то время он работал в открытой бете. А теперь, с выходом Chrome 146, DBSC доступен всем без исключения пользователям Windows.
Суть технологии в следующем. При включённом DBSC браузер генерирует уникальную пару криптографических ключей — публичный и приватный. Приватный ключ создаётся внутри аппаратного модуля безопасности: на Windows это TPM (Trusted Platform Module), на macOS планируется использовать Secure Enclave. Ключ нельзя экспортировать, скопировать или прочитать программно. Он физически привязан к конкретному устройству.
Когда сервер выдаёт сессионную куку, он делает это только после того, как Chrome докажет владение приватным ключом. Выданные куки при этом живут очень недолго. Если злоумышленник их украдёт, они быстро протухнут. А обновить их без приватного ключа, который остаётся на устройстве жертвы, невозможно. Фактически украденные куки превращаются в бесполезный мусор.
Разработчики позаботились и о совместимости. Если на устройстве пользователя нет TPM или другого защищённого хранилища ключей, DBSC просто не активируется, и браузер работает с куками по-старому. Ничего не ломается, логин не перестаёт работать.
Отдельно стоит сказать про приватность. Команды Chrome и Account Security в Google проектировали DBSC так, чтобы механизм не создавал новых возможностей для слежки. Для каждой сессии используется отдельный ключ, сайты не могут сопоставлять активность пользователя между разными ресурсами или даже между сессиями на одном и том же сайте. Протокол не передаёт серверу идентификаторы устройства или данные аттестации — только публичный ключ текущей сессии. Кросс-сайтовый трекинг и фингерпринтинг устройства через DBSC невозможны.
Стандарт разрабатывался не в вакууме. Google привлекла к работе Microsoft, и обе компании планируют продвигать DBSC как открытый веб-стандарт, доступный для любых браузеров и сервисов.
По данным Google, уже на этапе бета-тестирования наблюдалось заметное снижение количества успешных краж сессий. Конкретных цифр компания пока не раскрывает, но формулировка «significant reduction» в их посте, опубликованном в четверг, звучит обнадёживающе.
Что дальше? Расширение на macOS запланировано на один из ближайших релизов Chrome. Кроме того, Google намерена адаптировать DBSC для более широкого спектра устройств и добавить расширенные возможности для корпоративных сред, где массовая кража сессий особенно болезненна.
Пока DBSC работает только при наличии TPM и только на Windows с Chrome 146. Это значит, что пользователям Linux, старых машин без TPM или других браузеров пока рассчитывать не на что. Но сам подход — привязка сессии к железу, а не к файлу в папке профиля — выглядит как давно назревший шаг. Стилеры, конечно, никуда не денутся, но торговать украденными куками станет куда менее выгодно.
