Каждый раз, когда вы вводите пароль на сайте, браузер получает специальный файл - сессионную куку. Именно она и говорит серверу: этот человек уже прошёл проверку, пускайте его без лишних вопросов. Удобно. Быстро. И при этом чудовищно уязвимо - потому что любой, кто получил эту куку, автоматически становится вами в глазах сервера. Пароль не нужен. Двухфакторная аутентификация не нужна. Просто файл, который лежит в памяти браузера и ждёт, пока кто-нибудь его не заберёт.
Google годами смотрела на эту проблему и наконец сделала шаг, который давно назревал. В Chrome 146 компания запустила Device Bound Session Credentials - механизм, который физически привязывает сессионные куки к конкретному устройству пользователя. Со всеми вытекающими последствиями для индустрии безопасности.
Почему кража сессионных куки стала самым прибыльным инструментом современного киберкриминала
Чтобы понять, что именно меняет DBSC, нужно сначала разобраться в масштабе угрозы, которую он призван закрыть. Цифры здесь говорят сами за себя - и говорят тревожно.
По данным KELA за 2025 год, вредоносное ПО класса infostealer скомпрометировало 3,9 миллиарда учётных данных на 4,3 миллионах заражённых устройств только за 2024 год. В среднем с каждого заражённого устройства похищалось 1 861 куки. Это не просто пароли - это активные сессии, дающие немедленный доступ к аккаунтам без какой-либо дополнительной аутентификации.
В 2025 году среди похищенных учётных данных 276 миллионов содержали активные сессионные куки, что позволяло злоумышленникам полностью обойти многофакторную аутентификацию - это 31% всех скомпрометированных данных из вредоносного ПО. Трёхзначная цифра процентов от тех, кто пострадал от вымогательского ПО, восходит именно к этому вектору: 54% жертв атак с шифровальщиками имели свои корпоративные учётные данные в дампах инфостилеров ещё до самой атаки.
Ключевая семья этого рынка - LummaC2. ESET зафиксировал рост числа обнаружений LummaC2 на 369% между первой и второй половинами 2024 года. Microsoft идентифицировала более 394 000 заражённых Windows-компьютеров по всему миру за всего два месяца в 2025 году. После того как правоохранители в мае 2025 года обрушили инфраструктуру из более чем 2 300 командных серверов, малварь восстановилась за несколько недель и вернулась на прежние позиции.
Google прямо признала: как только вредоносное ПО получает доступ к машине, оно может читать локальные файлы и память браузера, где хранятся аутентификационные куки. Надёжного способа предотвратить кражу кук программными средствами на любой операционной системе не существует. Это - ключевое признание, объясняющее всю логику DBSC. Если программный барьер принципиально пробиваем, значит, защиту нужно переносить на уровень железа.
Как Device Bound Session Credentials использует TPM и Secure Enclave для защиты от кражи аутентификационных данных
Протокол криптографически привязывает аутентификационные сессии к конкретному устройству с использованием аппаратных модулей безопасности: Trusted Platform Module на Windows и Secure Enclave на macOS. Эти модули генерируют уникальную пару публичного и приватного ключей, которая не может быть экспортирована с машины.
Механизм работает следующим образом. Когда пользователь входит на сайт, поддерживающий DBSC, Chrome генерирует криптографическую пару ключей прямо внутри защищённого чипа. Выпуск новых краткосрочных сессионных кук обусловлен тем, что Chrome доказывает серверу владение соответствующим приватным ключом. Поскольку злоумышленники не могут украсть этот ключ, любые похищенные куки быстро истекают и становятся для них бесполезными.
Разница принципиальная. Традиционная кука живёт часами и даже сутками - именно поэтому её кража так ценна. DBSC-кука намеренно делается краткосрочной. Сервер не просто принимает её - он периодически требует от браузера подтвердить, что приватный ключ по-прежнему находится на том же устройстве. Когда краткосрочная кука истекает, Chrome инициирует процедуру обновления, отправляя серверу подписанное доказательство владения приватным ключом в формате JWT. Сервер проверяет подпись и выпускает новую куку с временем жизни в 600 секунд.
Атакующий, получивший такую куку любым способом - через малварь, перехват трафика, физический доступ к диску - получает файл, который уже через несколько минут превращается в ничто. И обновить его без приватного ключа, намертво зашитого в TPM жертвы, невозможно.
Детали реализации для разработчиков и корпоративные сценарии с Google Workspace
DBSC уже активен по умолчанию для пользователей Chrome 146 на Windows 10 версии 1903 и выше, а также Windows 11. Поддержка macOS ожидается в одном из следующих обновлений Chrome, хотя конкретные сроки Google не назвала.
Для разработчиков веб-приложений изменения минимальны. Большинство существующих конечных точек не требуют никаких изменений. DBSC спроектирован как аддитивный и ненарушающий. Когда необходимая краткосрочная кука отсутствует или истекла, Chrome приостанавливает запрос и пытается обновить её. Сайту нужно добавить лишь два дополнительных эндпоинта - регистрационный и для обновления куки - и существующая логика аутентификации продолжает работать.
Для корпоративных сред Google Workspace администраторы уже могут включить DBSC через консоль администратора: Безопасность - Управление доступом и данными - Контроль сессий Google. После включения система периодически проверяет, имеют ли пользователи, обращающиеся к защищённым приложениям, DBSC-привязанные сессии.
В плане дальнейшего развития Google работает над тремя направлениями. Первое - федеративная идентификация: в корпоративных средах с единой точкой входа (SSO) команда строит межисточниковые привязки, чтобы сессия у проверяющей стороны оставалась привязанной к тому же ключу устройства, что и при начальном входе через провайдера идентификации. Второе - расширенная регистрация с привязкой к предсуществующим доверенным материалам ключей, таким как mTLS-сертификаты или аппаратные ключи безопасности. Третье - программные ключи для устройств без специализированного защищённого железа.
Приватность по замыслу и почему DBSC не превращается в инструмент отслеживания пользователей
Первая интуитивная реакция на описание "ключ, уникальный для устройства, который сервер может проверять" - это же идеальный инструмент для отслеживания. Если сервер знает, что это то же самое устройство, разве он не может строить профиль пользователя?
Google предусмотрела этот вопрос и ответила на уровне архитектуры. Каждая DBSC-сессия поддерживается отдельным криптографическим ключом. Эта архитектура не позволяет веб-сайтам использовать учётные данные для корреляции активности пользователя в разных сессиях или на разных сайтах одного устройства. Протокол не передаёт серверу идентификаторы устройства или аттестационные данные - только публичный ключ сессии, необходимый для проверки владения.
Иными словами, каждый новый логин порождает новую независимую пару ключей. Сервер не может связать два разных входа на один и тот же сайт, не может отследить пользователя между разными сайтами, не может получить никакой информации об устройстве, кроме факта, что оно существует и держит нужный ключ. Это принципиально отличает DBSC от браузерных fingerprint-техник, которые как раз собирают детальный профиль железа.
При отсутствии поддержки безопасного хранения ключей на устройстве DBSC корректно откатывается к стандартному поведению без нарушения потока аутентификации. Пользователи со старым оборудованием без TPM просто продолжают работать в обычном режиме.
Что отрасль получает от открытого стандарта W3C и насколько реальна широкая адаптация
DBSC разрабатывался в процессе W3C и принят Рабочей группой по безопасности веб-приложений. Google работала над стандартом совместно с Microsoft, а провайдер идентификации Okta участвовал в испытаниях на протяжении прошлого года. Открытость стандарта принципиальна: если бы DBSC оставался проприетарной функцией Chrome, его ценность была бы ограничена. Веб работает только тогда, когда безопасность реализована повсеместно, а не в одном браузере.
Google уже на протяжении прошлого года проводила раннее развёртывание протокола на собственных ресурсах. Для сессий, защищённых DBSC, компания зафиксировала измеримое снижение числа краж сессий с момента начала развёртывания. Это первые реальные данные об эффективности, а не теоретические оценки.
Главный вопрос остаётся открытым: насколько быстро веб-разработчики добавят поддержку на стороне серверов? DBSC требует от сайтов реализации двух дополнительных эндпоинтов, и пока это не сделано - защита не работает, даже если браузер её поддерживает. Отрасль уже видела похожую ситуацию с переходом на HTTPS: понадобились годы и давление со стороны крупных игроков, чтобы большинство сайтов реализовало шифрование по умолчанию.
Разработчики вредоносного ПО оперативно адаптируются к каждому новому защитному слою Chrome. Когда в Chrome 127 появилось шифрование, привязанное к приложению, несколько семей стилеров временно приостановили распространение. Это окно закрылось быстро - к середине 2025 года несколько семей уже реализовали обходы. DBSC принципиально другой: аппаратный корень доверия нельзя обойти программным способом. Похитить приватный ключ из TPM через малварь невозможно по архитектурным причинам, а не по причине недостаточных усилий атакующего.
Именно поэтому DBSC в Chrome 146 - не очередной патч в бесконечной гонке вооружений, а структурный сдвиг в самой логике браузерной аутентификации. Вопрос теперь не в том, сработает ли механизм технически. Вопрос в том, как быстро веб-индустрия решится его поддержать.
Канал сайта в Telegram
Канал сайта на YouTube