Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Google rozpoczął publiczne udostępnianie mechanizmu Device Bound Session Credentials (DBSC) dla użytkowników systemu Windows korzystających z Chrome 146. To rozwiązanie ma utrudnić przejmowanie aktywnych sesji internetowych poprzez kryptograficzne powiązanie sesji z konkretnym urządzeniem, a nie wyłącznie z samym ciasteczkiem sesyjnym.
W praktyce DBSC odpowiada na jeden z najbardziej uporczywych problemów współczesnego krajobrazu zagrożeń: kradzież cookies sesyjnych przez infostealery i inne rodzaje malware. Jeżeli sesja jest powiązana z lokalnie chronionym kluczem prywatnym, samo wykradzenie cookie przestaje wystarczać do odtworzenia dostępu na innym urządzeniu.
W skrócie
- DBSC wiąże sesję użytkownika z parą kluczy kryptograficznych generowanych lokalnie.
- Klucz prywatny pozostaje chroniony przez mechanizmy systemowe lub sprzętowe, takie jak TPM na Windows.
- Serwer wydaje krótkotrwałe cookies sesyjne po potwierdzeniu posiadania właściwego klucza.
- Przechwycenie samego cookie znacząco traci wartość operacyjną dla atakującego.
- Publiczne wdrożenie rozpoczęto dla Chrome 146 na Windows, a obsługa macOS ma pojawić się później.
Kontekst / historia
Przejmowanie sesji od lat pozostaje jedną z najskuteczniejszych metod uzyskiwania nieautoryzowanego dostępu do kont. W ostatnich latach problem nasilił się wraz z rozwojem malware-as-a-service oraz rynku infostealerów, które specjalizują się w kradzieży haseł, danych zapisanych w przeglądarkach, tokenów oraz ciasteczek sesyjnych.
Takie ataki są szczególnie groźne, ponieważ przechwycona sesja może umożliwiać obejście części klasycznych zabezpieczeń logowania, w tym mechanizmów MFA stosowanych jedynie podczas uwierzytelnienia. Google zapowiedział DBSC w 2024 roku jako inicjatywę rozwijaną otwarcie z myślą o przyszłym standardzie webowym, a kolejne etapy obejmowały testy, origin trial i wdrożenia pilotażowe.
Analiza techniczna
DBSC zmienia model ochrony sesji z podejścia opartego na bearer cookie na podejście wymagające potwierdzenia posiadania klucza prywatnego. Po zalogowaniu aplikacja może zainicjować rejestrację DBSC, a przeglądarka generuje parę kluczy i przekazuje serwerowi klucz publiczny. Klucz prywatny pozostaje na urządzeniu i ma być przechowywany w sposób utrudniający eksport.
Następnie serwer wiąże sesję z danym kluczem publicznym i przechodzi na model krótkotrwałych cookies. Kiedy cookie wygasa lub zbliża się do końca ważności, przeglądarka wykonuje odświeżenie sesji przez dedykowany endpoint. Warunkiem uzyskania nowego cookie jest kryptograficzne udowodnienie, że przeglądarka nadal dysponuje właściwym kluczem prywatnym.
Z punktu widzenia obrońcy oznacza to istotną redukcję wartości skradzionego artefaktu. Atakujący, który wykradnie wyłącznie cookie, nie powinien móc odtworzyć sesji na innym urządzeniu bez dostępu do nieeksportowalnego klucza prywatnego. Google zaprojektował ten mechanizm tak, aby ograniczyć konieczność przebudowy całej aplikacji, choć wdrożenie nadal wymaga dostosowania logiki serwera, endpointów rejestracji i odświeżania oraz testów niezawodności.
Istotny jest również aspekt prywatności. Każda sesja ma korzystać z odrębnego klucza, co ogranicza ryzyko śledzenia użytkownika między sesjami i witrynami. W przypadku braku odpowiedniego magazynu kluczy lub problemów środowiskowych przeglądarka może przejść do trybów awaryjnych zamiast zrywać logowanie.
Konsekwencje / ryzyko
Dla użytkowników końcowych wdrożenie DBSC oznacza przede wszystkim mniejsze ryzyko wykorzystania skradzionych cookies poza urządzeniem ofiary. To szczególnie ważne w środowiskach korporacyjnych, gdzie przejęta sesja może otworzyć drogę do poczty, usług chmurowych, paneli administracyjnych czy danych wrażliwych.
Nie jest to jednak rozwiązanie eliminujące cały problem kompromitacji. Jeśli malware działa lokalnie na urządzeniu i może operować w kontekście aktywnej sesji, DBSC nie zablokuje wszystkich scenariuszy nadużycia. Mechanizm ogranicza przenaszalność skradzionego cookie, ale nie zastępuje ochrony endpointu, EDR ani dobrych praktyk hardeningu.
Wyzwania pojawiają się także po stronie serwisów wdrażających tę technologię. Krótkotrwałe cookies, zależność od endpointów odświeżania oraz obsługa błędów związanych z TPM, siecią czy politykami cookie mogą wprowadzać nowe scenariusze awarii i problemy kompatybilności. Z tego względu implementacja wymaga równoczesnego spojrzenia na bezpieczeństwo i niezawodność.
Rekomendacje
Organizacje rozwijające własne aplikacje webowe powinny rozważyć wdrożenie DBSC wszędzie tam, gdzie sesje mają wysoką wartość biznesową lub zapewniają dostęp do krytycznych funkcji. Dotyczy to szczególnie platform SaaS, paneli administracyjnych, środowisk enterprise, systemów finansowych i usług chmurowych.
- zidentyfikować sesje wymagające silniejszej ochrony niż klasyczny bearer cookie,
- wdrożyć krótkotrwałe cookies dla operacji wysokiego ryzyka,
- przygotować endpointy rejestracji i odświeżania zgodne z architekturą DBSC,
- przetestować scenariusze awaryjne związane z TPM, siecią i politykami cookie,
- monitorować nieudane próby odświeżania sesji oraz anomalie w cyklu życia tokenów,
- utrzymać silne zabezpieczenia endpointów, ponieważ DBSC nie chroni przed pełną kompromitacją hosta,
- połączyć nowe mechanizmy z EDR, hardeningiem przeglądarek i ochroną przed infostealerami.
Z perspektywy zespołów bezpieczeństwa warto także zaktualizować playbooki reagowania na incydenty. Wdrożenie sesji związanych z urządzeniem zmienia charakter nadużyć i może wymusić nowe metody analizy przejęć kont oraz anomalii sesyjnych.
Podsumowanie
Uruchomienie DBSC w Chrome 146 to ważny krok w kierunku ograniczenia skuteczności kradzieży sesji internetowych. Google nie eliminuje w ten sposób całego problemu kompromitacji stacji roboczych, ale znacząco obniża wartość samych skradzionych cookies jako przenaszalnych tokenów dostępu.
Dla dostawców usług internetowych i zespołów bezpieczeństwa to wyraźny sygnał, że tradycyjny model sesji oparty wyłącznie na bearer cookies staje się niewystarczający wobec skali współczesnych kampanii infostealerów. DBSC może stać się istotnym elementem nowoczesnej architektury ochrony tożsamości i sesji.
Źródła
- The Hacker News — https://thehackernews.com/2026/04/google-rolls-out-dbsc-in-chrome-146-to.html
- Google Online Security Blog: Protecting Cookies with Device Bound Session Credentials — https://security.googleblog.com/2026/04/protecting-cookies-with-device-bound.html
- Chrome for Developers: Device Bound Session Credentials (DBSC) — https://developer.chrome.com/docs/web-platform/device-bound-session-credentials
- Chromium Blog: Fighting cookie theft using device bound sessions — https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html
- Chrome for Developers: Origin trial: Device Bound Session Credentials in Chrome — https://developer.chrome.com/blog/dbsc-origin-trial