Google Chrome 146 запровадив захист від крадіжки сесійних файлів cookie завдяки прив'язці до обладнання.

Олена Кожухар

ВідОлена КожухарЖурналіст із багаторічним досвідом. Спеціалізуюся на створенні посібників, порад, технічних лайфхаків, інструкцій з налаштування та експлуатації різних пристроїв.11.04.2026Поширити3 хв. на прочитання

Google інтегрувала в Chrome 146 для Windows інноваційну функцію безпеки — Device Bound Session Credentials (DBSC). Вона перешкоджає зловмисному програмному забезпеченню типу infostealer використовувати викрадені сесійні cookie для несанкціонованого доступу до акаунтів користувачів. Власники пристроїв на macOS отримають цей механізм захисту в майбутніх оновленнях браузера — конкретна дата поки не встановлена.

Зміст

Сутність сесійних cookie та причини їх викрадення
Принцип роботи DBSC
Приватність та відкриті стандарти
Результати експериментів та впровадження

Сутність сесійних cookie та причини їх викрадення

Сесійний cookie – це, по суті, цифровий ключ доступу, який сервер надає браузеру після успішної автентифікації користувача (введення логіна та пароля). Надалі браузер використовує цей cookie при кожній взаємодії з сервісом, що дозволяє підтримувати сесію без необхідності повторного введення облікових даних.

Ця зручність робить сесійні cookie надзвичайно цінними для зловмисників. Заволодівши таким файлом, зловмисник може отримати доступ до чужого профілю, не знаючи пароля. Для збору таких даних використовуються спеціалізовані шкідливі програми – infostealer.

Google відзначає, що деякі сімейства подібних програм, зокрема LummaC2, демонструють зростаючу ефективність у викраденні цієї інформації. Компанія визнає: «Після того, як складне шкідливе програмне забезпечення проникло на комп’ютер, воно може зчитувати локальні файли та оперативну пам’ять, де зберігаються автентифікаційні cookie браузерів. Тому не існує надійного способу запобігти викраденню cookie виключно програмними засобами на будь-якій операційній системі».

Принцип роботи DBSC

Технологія DBSC, представлена у 2024 році, вирішує цю проблему завдяки криптографічному прив’язуванню сесії користувача до конкретного апаратного пристрою. На платформі Windows для цього застосовується чіп Trusted Platform Module (TPM), а на macOS – Secure Enclave.

Ці апаратні модулі відповідають за генерацію унікальної пари ключів – відкритого та закритого – для шифрування та дешифрування даних. Ключова особливість: закритий ключ неможливо експортувати з пристрою.

«Видача нових, короткотривалих сесійних cookie залежить від можливості Chrome підтвердити серверу наявність відповідного закритого ключа», – пояснює Google. Якщо викрадений cookie потрапляє на інший пристрій, де відсутній необхідний ключ, він миттєво стає недійсним і марним для атакуючого.

Взаємодія браузер-сервер в контексті протоколу DBSC

Приватність та відкриті стандарти

Протокол DBSC розроблявся з урахуванням аспектів приватності: кожна сесія захищається унікальним ключем. Це унеможливлює відстеження активності користувача вебсайтами між різними сесіями або на різних ресурсах з одного пристрою. Під час обміну даними передається виключно відкритий ключ, необхідний для підтвердження прив’язки до пристрою, – ідентифікатори самого пристрою не розкриваються.

Протокол створювався у співпраці з Microsoft як відкритий вебстандарт. До його розробки також долучилися фахівці з веббезпеки. Специфікації доступні на ресурсах консорціуму World Wide Web Consortium (W3C).

Результати експериментів та впровадження

Протягом року тестування ранньої версії DBSC у співпраці з низкою вебплатформ, включаючи Okta, Google зафіксувала значне зниження випадків компрометації сесій.

Веб-розробники можуть інтегрувати підтримку DBSC, додавши на бекенд спеціальні точки для реєстрації та оновлення – без модифікації фронтенду та без шкоди для сумісності з існуючими системами. Детальний посібник з впровадження представлений Google, специфікації – на сайті W3C, а технічні роз’яснення – на GitHub.

Будь ласка, залиште це поле порожнім