token dostępowy zapisany w lokalnej pamięci przeglądarki

Token zapisany w lokalnej pamięci przeglądarki jest podatny na kradzież przez skrypty działające na stronie.

Gdzie przeglądarka przechowuje token dostępowy

Token dostępowy zapisany w lokalnej pamięci przeglądarki znajduje się zwykle w mechanizmie Web Storage, najczęściej w obiekcie localStorage. Dane są przypisane do konkretnego źródła, czyli kombinacji schematu, hosta i portu. Skrypt uruchomiony w ramach tego samego źródła może odczytać wpis przez JavaScript, na przykład za pomocą localStorage.getItem(), jeżeli zna używany przez aplikację klucz. Lokalna pamięć jest trwała: wpis pozostaje po zamknięciu karty i zazwyczaj także po ponownym uruchomieniu przeglądarki, dopóki aplikacja albo użytkownik go nie usunie.

Token nie jest automatycznie chroniony przed odczytem przez kod JavaScript działający w kontekście aplikacji. Samo zapisanie wartości pod nazwą taką jak access_token, jwt lub authToken nie zmienia tej właściwości. Ochrona dostępu do interfejsu localStorage opiera się na regule tego samego źródła, a nie na tym, czy wartość jest zakodowana jako JWT, ciąg znaków czy inny format. Kodowanie Base64 nie stanowi szyfrowania i nie utrudnia skutecznie odczytu tokenu skryptowi, który ma dostęp do strony.

Dlaczego podatność XSS może ujawnić zapisane poświadczenie

Podstawowym zagrożeniem jest cross-site scripting, czyli XSS. W takim scenariuszu napastnik doprowadza do wykonania własnego kodu JavaScript w kontekście zaufanej aplikacji. Przyczyną może być na przykład niebezpieczne wstawianie niesprawdzonych danych do dokumentu HTML, błędne użycie właściwości innerHTML albo podatność w bibliotece używanej przez stronę. Jeżeli taki kod działa w tym samym źródle co aplikacja, może odczytać token z localStorage i wysłać go do zewnętrznego serwera przez żądanie sieciowe. Do kradzieży nie jest potrzebne poznanie hasła użytkownika, ponieważ token może już reprezentować uwierzytelnioną sesję.

Skutki zależą od zakresu uprawnień tokenu, czasu jego ważności i sposobu sprawdzania go przez serwer. Token typu bearer jest używany przez posiadacza, dlatego serwer zazwyczaj nie wymaga dodatkowego dowodu, że żądanie pochodzi od pierwotnej przeglądarki. Osoba, która przejmie ważną wartość, może próbować użyć jej w żądaniach do odpowiedniego API aż do wygaśnięcia tokenu, jego unieważnienia albo zmiany stanu sesji. Mechanizmy takie jak HTTPS chronią transmisję między przeglądarką a serwerem, ale nie uniemożliwiają odczytu tokenu z pamięci przez złośliwy skrypt już wykonujący się na stronie.

Bezpieczniejsze przechowywanie i ograniczanie skutków

Przy sesjach opartych na ciasteczkach często stosuje się ciasteczko z atrybutem HttpOnly. Ten atrybut powoduje, że wartość ciasteczka nie jest dostępna przez document.cookie, więc prosty skrypt XSS nie może jej bezpośrednio odczytać. Atrybut Secure ogranicza wysyłanie ciasteczka do połączeń HTTPS, a SameSite wpływa na wysyłanie ciasteczka w żądaniach międzywitrynowych. HttpOnly nie usuwa jednak samej podatności XSS: złośliwy skrypt nadal może wykonywać żądania z poziomu załadowanej aplikacji, jeśli bieżąca sesja automatycznie dołącza uwierzytelnienie.

Projekt aplikacji powinien więc łączyć kilka mechanizmów. Tokeny powinny mieć możliwie krótki czas życia i ograniczony zakres uprawnień, a serwer powinien odrzucać tokeny wygasłe, unieważnione lub użyte poza przewidzianym kontekstem. Przydatne są również rotacja tokenów odświeżających, unieważnianie sesji po wylogowaniu oraz kontrola wartości nagłówka Origin lub Referer tam, gdzie jest to uzasadnione architekturą. Po stronie przeglądarki należy stosować politykę Content Security Policy, poprawnie kodować dane zależnie od miejsca ich użycia i aktualizować zależności. Przeniesienie tokenu z localStorage do sessionStorage ogranicza trwałość wpisu, ale nie rozwiązuje problemu XSS, ponieważ kod strony może odczytywać także tę pamięć.

Sprawdzenie tokenu w praktyce serwisowej

Podczas diagnostyki można w narzędziach deweloperskich przeglądarki sprawdzić zakładkę Storage lub Application i ustalić, czy aplikacja zapisuje poświadczenia w localStorage. Należy zweryfikować nazwę klucza, źródło strony, moment utworzenia wpisu oraz zachowanie po wylogowaniu. Jeżeli token pozostaje po wylogowaniu, aplikacja może nie usuwać go prawidłowo albo polegać wyłącznie na jego wygaśnięciu po stronie serwera. W zakładce Network można sprawdzić, czy wartość jest wysyłana w nagłówku Authorization, ciasteczku lub innym elemencie żądania. Nie należy wklejać prawdziwego tokenu do publicznych narzędzi, zgłoszeń ani komunikatorów.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w ramach diagnostyki oprogramowania można również sprawdzić objawy problemów z sesją przeglądarki, nieprawidłowe wylogowanie oraz lokalne dane aplikacji. Usunięcie wpisu z pamięci przeglądarki może przerwać bieżącą sesję na danym urządzeniu, lecz nie zastępuje unieważnienia tokenu po stronie serwera. Jeżeli istnieje podejrzenie, że token został ujawniony, właściwą kolejnością jest wylogowanie sesji, unieważnienie lub rotacja poświadczenia przez aplikację oraz ponowne uwierzytelnienie, a dopiero potem czyszczenie lokalnych danych przeglądarki.