Google начала массово включать в Chrome механизм DBSC, который криптографически привязывает сессию к конкретному устройству и мешает использовать украденные cookie для входа в аккаунт. Для русскоязычной IT-аудитории это важная история не про «еще одну галочку в браузере», а про то, что защита cookie-сессий наконец выходит на уровень массового веба и бьет по одному из самых неприятных сценариев последних лет: захвату учеток уже после MFA.
Речь идет о функции Device Bound Session Credentials, или DBSC. Как пишет BleepingComputer, 29 мая 2026 года Google объявила, что механизм стал общедоступным и разворачивается для клиентов Google Workspace, подписчиков Workspace Individual и пользователей личных Google-аккаунтов. В бета-режиме функция была доступна с апреля 2026 года, а впервые Google представила сам подход еще в 2024-м. Идея проста: если злоумышленник украл session cookie, этого больше недостаточно, чтобы тихо зайти в аккаунт с другой машины.
Технически DBSC работает так: браузер связывает сессию не просто с учетной записью, а с аппаратным корнем доверия на устройстве. На Windows это TPM, на macOS — Secure Enclave. Ключевая пара генерируется и используется внутри такого модуля, а значит, ее нельзя просто вытащить вместе с файлами браузера или унести через инфостилер. В результате похищенный cookie сам по себе превращается в довольно бесполезный сувенир: у атакующего нет криптографического ключа, который подтверждает, что сессия действительно принадлежит тому устройству, где пользователь аутентифицировался.
Практическая ценность здесь очевидна. Обычный сценарий атаки последних лет выглядел так: пользователь проходит MFA, браузер получает валидную сессию, затем инфостилер вытаскивает cookie, а злоумышленник использует их, чтобы обойти повторную проверку. Для жертвы это особенно неприятно, потому что формально второй фактор был включен и даже честно сработал. Google прямо подчеркивает, что DBSC усиливает защиту уже после входа в систему и заметно осложняет эксплуатацию украденных cookie даже в том случае, если на устройстве успело поселиться вредоносное ПО.
Контекст тоже не абстрактный, а очень предметный. В материале упоминается, что злоумышленники раньше использовали недокументированную конечную точку Google OAuth MultiLogin API, чтобы получать новые аутентификационные cookie после истечения украденных. Кроме того, операторы инфостилеров Lumma и Rhadamanthys заявляли, что могут восстанавливать просроченные cookie Google, похищенные во время атак, и за счет этого снова получать доступ к аккаунтам. Для защитников это была довольно раздражающая асимметрия: пользователь уже потерял сессию, срок ее жизни вышел, а атакующий все равно продолжал играть в ту же партию. На этом фоне аппаратная привязка сессии выглядит не косметическим апдейтом, а попыткой закрыть именно класс атаки, а не отдельный симптом.
Для компаний на Google Workspace новость еще жестче и интереснее: по мере разворачивания функция будет включаться по умолчанию, и администраторы не смогут ее отключить. С точки зрения enterprise это типичный гугловский подход: если защита касается базовой модели доверия, опция «ну давайте не будем» считается лишней роскошью. Для ИБ-команд это, скорее, плюс. Чем меньше ручных исключений и локальных компромиссов, тем ниже шанс, что защита развалится из-за наследуемой конфигурации, забытого пилота или одного очень занятого администратора. Но есть и управленческий вывод: если часть внутренних веб-приложений или интеграций живет на хрупкой логике вокруг сессий, тестировать совместимость с новыми схемами привязки стоит заранее, а не в момент, когда helpdesk уже тонет в заявках.
Для разработчиков и владельцев продуктов история тоже показательная. DBSC демонстрирует, куда в целом двигается веб-аутентификация: одной парой «логин, пароль, MFA» больше не обойтись, если сама сессия остается переносимой между устройствами. Следующий нормальный вопрос для любой команды, которая строит SaaS, личные кабинеты или B2B-панели: что происходит после логина и насколько ваша архитектура рассчитана на кражу уже выданной сессии? Если ответ сводится к «ну у нас же есть второй фактор», это уже не ответ, а мем из прошлой эпохи. Защита cookie-сессий постепенно становится не дополнительной опцией для параноиков, а новым базовым ожиданием от крупных платформ.
При этом DBSC не отменяет старую добрую гигиену. Если на устройстве пользователя работает инфостилер, проблема никуда не исчезает: вредонос может воровать данные, токены других сервисов, пароли, содержимое буфера обмена и использовать сам зараженный хост как точку атаки. Раньше Google советовала удалять malware и включать режим Enhanced Safe Browsing в Chrome для защиты от фишинга и вредоносных кампаний. Эта рекомендация никуда не делась. Просто теперь у защитников появляется дополнительный слой, который не пытается ловить атаку постфактум по странной активности, а заранее делает украденный артефакт менее пригодным для злоумышленника.
Самый интересный вопрос теперь не в том, сработает ли подход у Google, а в том, насколько быстро подобная защита cookie-сессий станет нормой за пределами экосистемы компании. Если аппаратная привязка сессий начнет массово появляться у других крупных веб-сервисов, рынок инфостилеров получит не просто новую помеху, а удар по одной из своих самых прибыльных техник. И вот это уже меняет правила игры заметно сильнее, чем очередной баннер про важность MFA.