Компания Google объявила о выходе общедоступной функции Device Bound Session Credentials (DBSC) для пользователей Windows: она будет доступна в Chrome 146. Поддержка для macOS запланирована на один из ближайших релизов — сроки компания отдельно обозначила как «в грядущем обновлении». Технология нацелена на снижение риска кражи пользовательских сессий, когда злоумышленники пытаются воспользоваться уже «входными» состояниями браузера.
Что такое кража сессий и почему она опаснее, чем кажется
Речь идет о ситуации, когда вредоносная программа попадает на компьютер или другое устройство и затем извлекает из браузера данные, которые подтверждают авторизацию. В большинстве случаев это происходит через похищение сессионных файлов (часто в виде cookies), которые позволяют серверу считать пользователя уже прошедшим проверку.
Подобные действия характерны для семейств инфостилеров — программ, которые нацелены на сбор учетных данных и связанных сессий. В сообщении компании отдельно упоминается LummaC2: такие инструменты могут собирать токены и сессионные сведения, а затем использовать их для доступа к аккаунтам без необходимости подбирать пароли.
Google также подчеркнула важный практический момент: если вредоносное ПО уже получило доступ к устройству, то на любом из основных операционных систем не существует гарантированного «только программного» способа надежно остановить утечку cookie. То есть борьба переносится с запрета на уровне софта на защиту ключевой логики авторизации аппаратными средствами и привязкой к устройству.
Как DBSC защищает авторизацию: привязка к конкретному устройству
DBSC решает проблему не «маскировкой» cookie, а криптографической привязкой сессии к конкретному устройству. Идея проста: даже если злоумышленник каким-то образом получит cookie, он не сможет использовать их на другом устройстве, потому что сервер будет требовать доказательства владения соответствующим ключом, который хранится на целевой машине.
Механизм построен вокруг аппаратных модулей безопасности:
- На Windows используется Trusted Platform Module (TPM) — аппаратный компонент, который помогает генерировать и защищать криптографические ключи.
- На macOS применяется Secure Enclave — защищенная подсистема, изолированная от основной операционной среды.
Система генерирует уникальную пару «открытый/закрытый ключ». Ключевая деталь в том, что закрытый ключ не подлежит экспорту с устройства. После этого Chrome выпускает новые короткоживущие сессионные cookies только тогда, когда браузер может подтвердить серверу, что именно он обладает закрытым ключом, соответствующим этой сессии.
Что именно изменилось для пользователей в Chrome 146
Согласно объявлению, DBSC теперь доступна публично для Windows в Chrome 146. Это означает, что технология перестает быть исключительно экспериментальной и становится частью стандартного набора функций браузера для соответствующих сценариев защиты.
Поддержка для macOS будет добавлена в одном из следующих релизов Chrome. Таким образом, в будущем планируется распространить принцип «сессия привязана к устройству» на большее число пользователей, независимо от платформы.
Результаты внедрения: снижение краж сессий
Google заявила, что после внедрения ранней версии протокола наблюдалось существенное уменьшение случаев session theft для сессий, защищенных DBSC. Компания не приводит точный процент в предоставленном материале, но указывает на практическую эффективность подхода: привязка авторизации к аппаратному ключу ограничивает ценность похищенных cookie для злоумышленников.
Открытый стандарт и участие экосистемы
Важной частью истории DBSC является его стандартизация. Google сообщила, что технология спроектирована как открытый веб-стандарт через процесс World Wide Web Consortium (W3C) — организации, которая разрабатывает и согласует спецификации для веб-технологий. Также компания отметила партнерство с Microsoft в рамках стандарта.
Дополнительно указано, что за прошедший год в двух Origin Trials участвовали веб-платформы, включая Okta. Origin Trials — это механизм, позволяющий разработчикам и платформам тестировать новые веб-возможности в реальных условиях до их полного распространения.
Куда будет развиваться DBSC дальше
В дальнейшем Google планирует расширять функциональность защиты авторизации. В сообщении перечислены ключевые направления:
- Усиление безопасности федеративной идентификации (federated identity) за счет привязок между разными контекстами и доменами — то есть cross-origin bindings.
- Развитие расширенных возможностей регистрации, чтобы привязывать DBSC-сессии к уже существующему доверенному набору ключевого материала.
- Расширение поддержки устройств: включая сценарии, где вместо выделенного защищенного аппаратного решения будут применяться программные ключи для устройств без соответствующих secure hardware.
Справка: что означает «federated identity»
Федеративная идентификация — это модель, при которой пользователь входит в сервис, используя учетные данные, управляемые внешним провайдером (например, корпоративной системой или специализированной платформой). Такой подход удобен для организаций, но усложняет защиту сессий, поскольку авторизация может переходить через несколько доменов и компонентов.
Именно поэтому в планах Google — не только «защитить cookie», но и обеспечить устойчивость DBSC в более сложных сценариях межсайтовой и междоменной авторизации.