Крадіжка сесій через викрадені cookies залишається одним із найефективніших інструментів зловмисників, попри розвиток багатофакторної аутентифікації. Google оголосила про широке впровадження технології Device Bound Session Credentials (DBSC) у браузері Chrome для Windows, починаючи з версії Chrome 146. Її головна мета — криптографічно прив’язати сесію до конкретного пристрою та різко зменшити цінність викрадених сесійних токенів.
Крадіжка сесій і cookies: чому це одна з головних загроз
Механізм угону сесії (session hijacking) ґрунтується на тому, що сесійні cookies у браузері виконують роль «квитка» до акаунта. Отримавши цей квиток, зловмисник може увійти в обліковий запис без пароля, без SMS-кодів та інших факторів захисту. Найчастіше такі cookies викрадає шкідливе ПЗ класу info‑stealer, яке користувач несвідомо встановлює разом із піратським ПЗ, «кряками» або вкладеннями з фішингових листів.
Сучасні стилери на кшталт Atomic Stealer, Lumma, Vidar Stealer та десятків їх аналогів спеціалізуються на зборі:
— сесійних cookies та токенів доступу;
— збережених паролів і даних автозаповнення;
— історії браузера;
— криптогаманців та іншої чутливої інформації.
Проблему посилює те, що багато сесійних токенів мають тривалий строк життя. Це дозволяє зловмисникам протягом тижнів або навіть місяців непомітно заходити в облікові записи, уникаючи всіх процедур повторної аутентифікації. Викрадені набори даних продаються на підпільних майданчиках і використовуються для компрометації пошти, хмарних сервісів, банківських та корпоративних систем.
Як працює Device Bound Session Credentials у Google Chrome 146
Технологія Device Bound Session Credentials, публічно представлена у 2024 році, покликана зробити так, щоб викрадені cookies були практично непридатними за межами пристрою, на якому вони були видані. Ключова ідея — пов’язати сесію з конкретним пристроєм через апаратні криптографічні ключі.
TPM і Secure Enclave: апаратна прив’язка сесії до пристрою
DBSC використовує апаратні модулі безпеки, які вже є у більшості сучасних систем: на Windows — Trusted Platform Module (TPM), на macOS — Secure Enclave. У цих модулях створюється унікальна пара ключів публічний / приватний, причому приватний ключ ніколи не покидає пристрій і не може бути експортований програмно.
Під час успішної аутентифікації Chrome запитує у сервера не звичайні сесійні cookies, а токени, які пов’язані з конкретною криптографічною парою. Публічний ключ слугує ідентифікатором, що серверу достатньо, аби переконатися: браузер працює на тому пристрої, де зберігається відповідний приватний ключ усередині TPM або Secure Enclave.
Короткочасні cookies і криптографічне підтвердження володіння ключем
DBSC змінює сам підхід до видачі сесійних токенів: кожен новий, короткоживущий cookie сервер видає лише після того, як Chrome криптографічно доведе володіння приватним ключем. Перевірка базується на стандартних протоколах з електронним підписом або розшифруванням даних.
У результаті, навіть якщо info‑stealer скопіює cookies з браузера та передасть їх на іншу машину, токени швидко «протухнуть» і не зможуть бути оновлені, оскільки в атакуючого немає доступу до приватного ключа, фізично заблокованого в апаратному модулі жертви. Якщо ж пристрій не підтримує безпечне зберігання ключів, DBSC автоматично відкотиться до звичайного механізму сесій, зберігаючи сумісність і не ламаючи авторизацію.
Масштабування DBSC: від Chrome 146 до відкритого веб-стандарту
На поточному етапі DBSC активовано для всіх користувачів Google Chrome на Windows, починаючи з версії 146. Підтримка macOS очікується в найближчих релізах. За даними Google, під час відкритого бета‑тестування вже фіксується відчутне зменшення успішних атак із крадіжкою сесій, що підтверджує ефективність підходу.
Важливий аспект — реалізація DBSC вимагає змін не лише в браузері, а й на стороні серверних застосунків, які повинні навчитися працювати з новим типом сесійних токенів. Чим більше великих сервісів і корпоративних платформ інтегрують підтримку Device Bound Session Credentials, тим сильнішим буде вплив на всю екосистему: від особистої пошти до доступу до критично важливих бізнес‑ресурсів.
Приватність, відкритий стандарт і наслідки для бізнесу
Google розробляла Device Bound Session Credentials спільно з Microsoft із прицілом на перетворення DBSC на відкритий веб‑стандарт. Це відкриває шлях до подальшої підтримки у сторонніх браузерах і корпоративних продуктах без прив’язки лише до Chrome.
Окрема увага приділяється захисту приватності та запобіганню трекінгу. Архітектура DBSC спроєктована так, щоб:
— сайти не могли використовувати сесійні креденшли як механізм відстеження між різними ресурсами;
— сервер отримував мінімальний набір інформації — фактично лише публічний ключ для підтвердження володіння;
— DBSC не перетворювався на «цифровий відбиток пристрою» та не посилював крос‑сайт трекінг.
Для організацій це поєднання особливо цінне: підвищення стійкості до крадіжки сесій без погіршення конфіденційності користувачів. На тлі зростання атак info‑stealer і регуляторних вимог у сфері захисту даних компаніям доцільно вже зараз:
— проаналізувати сумісність своїх веб‑додатків із DBSC і запланувати підтримку стандарту;
— посилити контроль за шкідливими завантаженнями та стилерами на робочих станціях;
— оновити політики безпеки браузерів і рекомендувати користувачам перехід на актуальні версії Chrome.
Широке впровадження Device Bound Session Credentials здатне суттєво знизити ринкову цінність викрадених cookies, ускладнити життя кіберзлочинцям і зменшити кількість успішних угонів акаунтів. Користувачам і бізнесу варто уважно стежити за розвитком цього стандарту, регулярно оновлювати браузери та, за можливості, вмикати підтримку DBSC у своїх сервісах — це один із небагатьох механізмів, що безпосередньо б’є по економіці атак, заснованих на крадіжці сесій.
