Chrome 146 привязал сессии к чипу TPM — как работает DBSC
Если ваш бэкенд выдаёт сессионные cookies, появилась серьёзная альтернатива связке HttpOnly+Secure. Chrome 146 привязывает сессии к TPM-чипу — и украденный cookie на чужой машине не работает.
Новости Tproger
Если ваш бэкенд выдаёт сессионные cookies и вы до сих пор полагались только на связку HttpOnly + Secure — появилась серьёзная альтернатива. Google включила в Chrome 146 для Windows протокол Device Bound Session Credentials (DBSC): сессионные cookies криптографически привязываются к чипу TPM устройства, и украденный cookie на чужой машине просто не работает.
Поддержка macOS через Secure Enclave появится в одном из следующих релизов — конкретных сроков Google не назвала. Linux в анонсе вообще не упоминается.
Ключевые выводы
- Chrome 146 для Windows автоматически использует DBSC на сайтах, которые его поддерживают
- Даже заражённая малварью машина не отдаст ключ: приватный ключ сессии живёт в TPM и не может быть оттуда прочитан — даже самим Chrome
- Украденный cookie быстро становится бесполезным: сервер требует подпись challenge приватным ключом с оригинального устройства при каждом обновлении
- Внедрение для бэкенда — два новых эндпоинта (регистрация + refresh), фронтенд трогать не нужно
- DBSC — открытая спецификация в рамках W3C, разработанная Google совместно с Microsoft; Firefox и Safari пока молчат
- Это вторая попытка Google защитить cookies после App-Bound Encryption 2024 года, которую малварь обошла за пару месяцев
Что такое DBSC и зачем оно нужно
Сессионный cookie — это токен авторизации, который сервер выдаёт после успешного логина и принимает вместо пары логин-пароль. Из-за того что одного cookie достаточно для входа в аккаунт в обход 2FA, инфостилеры (LummaC2, MeduzaStealer, Vidar, StealC и десятки других) превратили кражу сессионных cookies в основной способ монетизации взломанных машин. Google в анонсе признаёт прямо: «как только продвинутая малварь получила доступ к машине, она может читать локальные файлы и память, где браузер хранит cookies. Нет надёжного способа предотвратить exfiltration программными средствами».
DBSC меняет архитектуру защиты: если украсть cookie всё равно можно, сделаем так, чтобы украденный cookie был бесполезен. Вместо одного долгоживущего cookie браузер получает серию короткоживущих, и каждый новый выдаётся сервером только после того, как Chrome докажет владение приватным ключом, лежащим в TPM. Длительность задаёт сам сервер, Google конкретных цифр не публикует.
Как это работает технически
- При создании сессии Chrome просит TPM сгенерировать пару ключей — приватный остаётся внутри чипа, публичный уходит на сервер и привязывается к сессии
- Сервер выдаёт короткоживущий session cookie и запоминает публичный ключ
- Cookie быстро истекает; Chrome запрашивает новый и получает challenge от сервера
- Chrome подписывает challenge приватным ключом через TPM — ключ при этом не покидает чип
- Сервер проверяет подпись публичным ключом и выдаёт следующий cookie
Если инфостилер украл файл с cookies и залил его на свою машину — на следующем refresh сервер потребует подписать challenge, а без TPM с оригинального устройства ключа для подписи нет. Cookie устаревает, использовать его нельзя. За год тестирования в партнёрстве с Okta и ещё несколькими платформами Google заявила о снижении краж сессий, но конкретных цифр не привела.
Отдельный момент — приватность. Для каждой сессии генерируется уникальный ключ, так что сайт не может использовать DBSC как трекер между сессиями или между сайтами. Обмен ограничен одним публичным ключом, никаких device ID не утекает — этот момент Google подчёркивала ещё при первом анонсе протокола в 2024 году.
Почему прошлая попытка провалилась
В 2024 году Google уже запускала защиту cookies в Chrome 127 — App-Bound Encryption. Идея была проще: шифровать cookies системным сервисом Windows, работающим с правами SYSTEM, а не обычного пользователя. Малварь бы не смогла расшифровать cookies без прав SYSTEM или инъекции кода в процесс Chrome — обе операции шумные и заметные для антивирусов.
Защита продержалась около двух месяцев. К сентябрю 2024 авторы MeduzaStealer, WhiteSnake, LummaC2, Lumar, Vidar и StealC выкатили обход, не требующий прав SYSTEM. Разработчики другой малвари, Rhadamanthys, тогда похвастались, что реверс-инжиниринг защиты занял у них 10 минут.
Почему DBSC должен сработать лучше: App-Bound Encryption был программной защитой — малварь на машине в принципе могла её сломать, потому что ключ хранился в памяти того же компьютера. DBSC переносит ключ в TPM: Chrome может попросить TPM подписать challenge, но не может прочитать или экспортировать сам ключ. Это архитектурное отличие, а не «усилили обфускацию» — украсть содержимое TPM без физического доступа к железу невозможно.
Что нужно сделать бэкенд-разработчикам
Главное — DBSC не требует изменений во фронтенде. Браузер сам берёт на себя всю работу с ключами и подписями. На бэкенде нужно добавить следующее:
- Эндпоинт регистрации сессии — принимает публичный ключ от браузера и сохраняет его рядом с сессией
- Эндпоинт обновления сессии — выдаёт новый короткоживущий cookie после проверки подписи challenge приватным ключом
- Логику выдачи cookies — вместо одного долгоживущего теперь серия короткоживущих с refresh каждые несколько минут
- Graceful degradation для браузеров без DBSC — чтобы Firefox и Safari не ломались на тех же эндпоинтах
Спецификация опубликована на сайте W3C как открытая спецификация, разработанная Google совместно с Microsoft, — так что другие браузеры теоретически могут подхватить. Google подготовила гайд по внедрению для разработчиков, а для тех, кто хочет глубже — explainer на GitHub.
Что это значит для обычного пользователя
Если вы просто пользуетесь Chrome — обновитесь до 146. Дальше делать ничего не нужно: защита включается автоматически на сайтах, которые уже внедрили DBSC. Для остальных сайтов всё работает как раньше — обычные cookies без аппаратной привязки. Пока что DBSC активна только на Windows с TPM 2.0; на ПК без TPM Chrome откатится на обычные cookies.
Часто задаваемые вопросы
DBSC делает двухфакторку ненужной?
Нет. DBSC защищает от кражи уже существующей сессии — токен на чужой машине не работает. Но если злоумышленник добыл ваш логин и пароль, он просто залогинится со своей машины, и DBSC привяжет новую сессию уже к его TPM. 2FA по-прежнему защищает сам логин, а DBSC — сессию после логина. Эти механизмы дополняют друг друга.
Когда поддержка Firefox и Safari?
Неизвестно. Спецификация опубликована в W3C как открытый стандарт, но ни Mozilla, ни Apple публично не объявляли о планах внедрения. Учитывая, что DBSC сделали Google и Microsoft, какое-то время Chromium-браузеры будут в выигрыше — Edge тоже получит защиту, как и другие форки.
Что с macOS и Linux?
macOS получит DBSC через Secure Enclave в одном из следующих релизов Chrome — конкретных сроков Google не называет. Linux в анонсе вообще не упоминается: стандартной аппаратной альтернативы TPM в Linux-экосистеме нет, а те, что есть, редко доступны на обычных ПК.
Мне нужно что-то делать, если у меня обычный сайт на WordPress?
Пока нет. DBSC требует поддержки на уровне бэкенда, и готовых плагинов для популярных CMS ещё не появилось. Смотреть в сторону DBSC стоит в первую очередь командам, которые держат критичные сервисы — банкинг, корпоративный IAM, облачные админки — и где кража сессии стоит дороже, чем пара недель работы на переделку cookie-логики.
DBSC работает без TPM?
Нет, нужен аппаратный TPM 2.0 на устройстве. Для Windows 11 он и так обязателен, для Windows 10 — часто встречается, но не всегда. Без TPM Chrome просто откатится на обычные сессионные cookies без аппаратной привязки.
Что с мобильным Chrome на Android и iOS?
В текущем анонсе мобильные платформы не упоминаются вообще. На Android технически всё готово — StrongBox и TEE есть на большинстве современных устройств, и они архитектурно эквивалентны TPM. На iOS Chrome использует WebKit Apple, так что там DBSC будет работать только если сначала его внедрит сам Safari. Сроков Google не называет ни для одной из платформ.
А что если TPM сломался или пользователь сменил материнскую плату?
Сессия инвалидируется: приватный ключ жил в старом TPM, новый чип его не знает. Пользователь должен будет залогиниться заново, и бэкенд создаст новую сессию, привязанную уже к новому TPM. Это та же логика, что и при смене устройства — DBSC архитектурно её усиливает. Для корпоративных сред с VDI-сценариями без реального TPM DBSC пока неприменим, и это одна из известных проблем протокола.
Выводы
Главное — защита от кражи сессий впервые переносится с программного уровня на аппаратный. Это ломает бизнес-модель инфостилеров, которая последние годы была построена на перепродаже украденных cookies: украденный токен просто перестаёт стоить денег, если его нельзя использовать на чужой машине. Если вы держите критичный сервис — добавляйте DBSC в беклог. Если просто пользуетесь Chrome — обновитесь до 146 и ждите, когда Firefox и Safari подтянутся.
Источники: BleepingComputer | Google Online Security Blog | gHacks
