- Автор темы
- #1
Разработчики Google начали внедрять в Chrome механизм Device Bound Session Credentials (DBSC), который должен помешать инфостилерам красть сессионные файлы cookie. Защита уже доступна в Chrome 146 для Windows, а в macOS появится в одном из будущих релизов.
Разработку DBSC в Google анонсировали еще в апреле 2024 года. Идея заключается в том, чтобы криптографически привязать сессию пользователя к конкретному оборудованию — модулю TPM в Windows или Secure Enclave в macOS. Уникальная пара ключей генерируется прямо в чипе безопасности, закрытый ключ невозможно извлечь с устройства, а без этого любые украденные cookie превращаются в бесполезный набор байтов.
В Google сообщают, что за время тестирования ранней версии DBSC совместно с Okta и другими партнерами наблюдалось заметное снижение количества инцидентов с угоном сессий.
Чтобы подключить защиту, сайтам достаточно добавить в бэкенд пару эндпоинтов — для регистрации и обновления сессии. Фронтенд при этом переделывать не придется, все веб-приложения продолжат работать со стандартными cookie.
Детали реализации специалисты Google описали в отдельном гайде для разработчиков, а спецификации были опубликованы на сайте W3C.
Разработчики пишут, что уже ведется работа над развитием DBSC. В планах — поддержка cross-origin-привязок, чтобы защитить федеративную аутентификацию, а также возможность привязывать новые сессии к уже существующим доверенным ключам. Кроме того, в компании рассматривают вариант работы с программными ключами (для устройств, где нет отдельного защищенного чипа).
Разработку DBSC в Google анонсировали еще в апреле 2024 года. Идея заключается в том, чтобы криптографически привязать сессию пользователя к конкретному оборудованию — модулю TPM в Windows или Secure Enclave в macOS. Уникальная пара ключей генерируется прямо в чипе безопасности, закрытый ключ невозможно извлечь с устройства, а без этого любые украденные cookie превращаются в бесполезный набор байтов.
Сессионный файл cookie, по сути, является токеном аутентификации с длительным сроком действия, который сервер создает после ввода логина и пароля. Именно поэтому такие cookie давно стали желанной добычей для операторов малвари: с ними можно проникнуть в чужой аккаунт вообще без пароля. В Google отмечают, что семейства вроде LummaC2 становятся все изощреннее, когда дело доходит до сбора таких учетных данных.
DBSC был спроектирован с оглядкой на приватность: каждой сессии соответствует своя пара ключей, так что сайты не могут связывать активность пользователя между разными сессиями или ресурсами на одном устройстве. Серверу передается только публичный ключ конкретной сессии, без каких-либо идентификаторов устройства.
В Google сообщают, что за время тестирования ранней версии DBSC совместно с Okta и другими партнерами наблюдалось заметное снижение количества инцидентов с угоном сессий.
Чтобы подключить защиту, сайтам достаточно добавить в бэкенд пару эндпоинтов — для регистрации и обновления сессии. Фронтенд при этом переделывать не придется, все веб-приложения продолжат работать со стандартными cookie.
Детали реализации специалисты Google описали в отдельном гайде для разработчиков, а спецификации были опубликованы на сайте W3C.
Разработчики пишут, что уже ведется работа над развитием DBSC. В планах — поддержка cross-origin-привязок, чтобы защитить федеративную аутентификацию, а также возможность привязывать новые сессии к уже существующим доверенным ключам. Кроме того, в компании рассматривают вариант работы с программными ключами (для устройств, где нет отдельного защищенного чипа).