Dane uwierzytelniające sesji powiązanej z urządzeniem (DBSC) zapewniają dodatkową warstwę zabezpieczeń sprzętowych, aby ograniczyć to ryzyko i zapewnić, że sesje są powiązane z określonymi urządzeniami.
Wprowadzenie
Wiele witryn korzysta z długotrwałych plików cookie do uwierzytelniania użytkowników, ale są one podatne na przejęcie sesji. Dane uwierzytelniające sesji powiązanej z urządzeniem (DBSC) zapewniają dodatkową warstwę zabezpieczeń sprzętowych, aby ograniczyć to ryzyko i zapewnić, że sesje są powiązane z określonymi urządzeniami.
Ten przewodnik jest przeznaczony dla deweloperów, którzy utrzymują procesy uwierzytelniania w aplikacjach internetowych. Wyjaśnia on, jak działa DBSC i jak zintegrować go z Twoją witryną.
Jak działa DBSC
W ogólnych zarysach DBSC wprowadza parę kluczy kryptograficznych powiązanych z urządzeniem użytkownika. Chrome generuje tę parę kluczy podczas logowania i przechowuje klucz prywatny na bezpiecznym sprzęcie, takim jak moduł TPM (Trusted Platform Module), jeśli jest dostępny. Sesje używają plików cookie o krótkim czasie ważności. Gdy jeden z tych plików cookie wygaśnie, Chrome przed ich odświeżeniem potwierdza posiadanie klucza prywatnego. Ten proces łączy ciągłość sesji z pierwotnym urządzeniem.
Jeśli urządzenie użytkownika nie obsługuje bezpiecznego przechowywania kluczy, DBSC płynnie przełączy się na standardowe działanie bez zakłócania procesu uwierzytelniania.
Omówienie wdrażania
Aby zintegrować DBSC z aplikacją, musisz wprowadzić te zmiany:
- Zmodyfikuj proces logowania, aby uwzględnić nagłówek
Sec-Session-Registration. - Dodaj punkt końcowy rejestracji sesji, który:
- Przypisuje klucz publiczny do sesji użytkownika.
- Udostępnia konfigurację sesji.
- Przejście na pliki cookie o krótkim czasie ważności.
- Dodaj punkt końcowy odświeżania, aby obsługiwać odnawianie plików cookie i weryfikację posiadania klucza.
Większość dotychczasowych punktów końcowych nie wymaga żadnych zmian. DBSC ma być uzupełnieniem i nie zakłócać pracy.
Jeśli wymagany plik cookie krótkotrwały jest niedostępny lub wygasł, Chrome wstrzymuje żądanie i próbuje odświeżyć plik cookie. Dzięki temu aplikacja może nadal używać zwykłych kontroli plików cookie sesji, aby potwierdzić, że użytkownik jest zalogowany. Ponieważ jest to zgodne z typowymi przepływami uwierzytelniania, DBSC działa z minimalnymi zmianami w logice logowania.
Etapy wdrażania
W tej sekcji znajdziesz informacje o koniecznych zmianach w systemie uwierzytelniania, w tym o tym, jak zmodyfikować proces logowania, obsłużyć rejestrację sesji i zarządzać krótkotrwałym odświeżaniem plików cookie. Każdy krok został zaprojektowany tak, aby można było go łatwo zintegrować z dotychczasową infrastrukturą.
Kroki implementacji są zgodne ze zwykłym procesem, który zalogowany użytkownik musi wykonać, gdy aktywna jest usługa DBSC: rejestracja podczas logowania, a potem regularne odświeżanie plików cookie o krótkim czasie ważności. Każdy krok możesz przetestować i zaimplementować niezależnie od siebie w zależności od poziomu czułości sesji aplikacji.
1. Zmiana procesu logowania
Gdy użytkownik się zaloguje, odpowiedz z długotrwałym plikiem cookie i nagłówkiem Sec-Session-Registration. Na przykład:
Po pomyślnym zarejestrowaniu sesji zwracany jest ten nagłówek odpowiedzi HTTP:
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
Jeśli urządzenie obsługuje bezpieczne przechowywanie kluczy, Chrome skontaktuje się z urządzeniem końcowym /StartSession za pomocą klucza publicznego w tokenie sieciowym JSON (JWT).
W tym przykładzie auth_cookie oznacza token sesji. Plik cookie możesz nazwać dowolnie, o ile tylko nazwa ta pasuje do pola name w konfiguracji sesji i jest używana konsekwentnie w całej aplikacji.
2. Implementacja punktu końcowego rejestracji sesji
Na serwerze /StartSession musisz:
- Powiązaj otrzymany klucz publiczny z sesją użytkownika.
- Odpowiedz, podając konfigurację sesji.
- Zastąp długotrwały plik cookie krótkim.
W tym przykładzie plik cookie o krótkim czasie ważności jest skonfigurowany tak, aby tracił ważność po 10 minutach:
HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutes Set-Cookie: Domain=example.com; Secure; SameSite=Lax
{
"session_identifier": "session_id",
"refresh_url": "/RefreshEndpoint",
"scope": {
"origin": "https://example.com",
"include_site": true,
"scope_specification": [
{ "type": "exclude", "domain": "*.example.com", "path": "/static" }
]
},
"credentials": [{
"type": "cookie",
"name": "auth_cookie",
"attributes": "Domain=example.com; Secure; SameSite=Lax"
}]
}
3. Implementowanie punktu końcowego odświeżania
Gdy krótkotrwały plik cookie wygaśnie, Chrome inicjuje proces odświeżania, aby potwierdzić posiadanie klucza prywatnego. Ten proces wymaga skoordynowanych działań Chrome i serwera:
Chrome przekazuje żądanie użytkownika do Twojej aplikacji i wysyła prośbę o odświeżenie do
/RefreshEndpoint:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_idSerwer odpowiada wyzwaniem:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"Chrome podpisuje wyzwanie za pomocą przechowywanego klucza prywatnego i ponownie wysyła żądanie:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>Twój serwer weryfikuje podpisany dowód i wydaje odświeżony krótkotrwały plik cookie:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=LaxChrome otrzymuje odświeżony plik cookie i wznawia pierwotne opóźnione żądanie.
Alternatywny schemat integracji
Aby zwiększyć odporność, witryny mogą dodać drugi plik cookie, który nie jest plikiem cookie zgodnym z DBSC, oprócz krótkotrwałego pliku cookie. Ten długotrwały plik cookie jest używany tylko do wydawania nowych krótkotrwałych tokenów i pomaga odróżnić żądania bez uwierzytelnienia od tymczasowych błędów DBSC.
- Plik cookie długotrwały jest przechowywany nawet wtedy, gdy DBSC się nie powiedzie.
- Plik cookie o krótkim czasie życia jest odświeżany za pomocą DBSC i wymagany w przypadku operacji wrażliwych.
Ten wzór daje witrynom większą kontrolę nad tym, jak mają być obsługiwane przypadki szczególne.
Zastrzeżenia i zachowanie w przypadku braku możliwości wyświetlenia kreacji
Chrome może pomijać operacje DBSC i wysyłać żądania bez obsługiwanego przez DBSC krótkotrwałego pliku cookie w tych scenariuszach:
- Punkt końcowy odświeżania jest niedostępny z powodu błędów sieci lub problemów z serwerem.
- TPM jest zajęty lub napotyka błędy podpisywania. TPM jest współdzielony w ramach procesów systemowych, więc nadmierne odświeżanie może przekroczyć limity szybkości.
- Zarządzany przez DBSC krótkotrwały plik cookie jest plikiem cookie innej firmy, a użytkownik zablokował pliki cookie innych firm w ustawieniach przeglądarki.
W takich sytuacjach Chrome używa pliku cookie długookresowego, jeśli taki plik jest nadal dostępny. Ten sposób zastępczy zastosujesz tylko wtedy, gdy Twoja implementacja obejmuje zarówno długotrwały, jak i krótkotrwały plik cookie. W przeciwnym razie Chrome wysyła żądanie bez ciasteczka.
Podsumowanie
Dane uwierzytelniające sesji powiązane z urządzeniem zwiększają bezpieczeństwo sesji przy minimalnych zmianach w aplikacji. Zapewniają one lepszą ochronę przed przechwyceniem sesji poprzez powiązanie sesji z konkretnymi urządzeniami. Większość użytkowników korzysta z tych funkcji bez żadnych zakłóceń, a DBSC automatycznie przełącza się na nieobsługiwany sprzęt.
Więcej informacji znajdziesz w specyfikacji DBSC.