Luki w JWT: alg=none i pomylenie kluczy

Tokeny JWT są podpisane kryptograficznie, ale wiele bibliotek miało poważne podatności. Najczęściej wykorzystywane to atak alg=none, atak pomieszania RS256→HS256 oraz brute force słabego sekretu. Wszystkie wynikają z zaufania do pól nagłówka kontrolowanych przez atakującego.

Specyfikacja JWT dopuszcza alg:"none" dla niezabezpieczonych tokenów. Błędne biblioteki akceptowały tę wartość i całkowicie pomijały weryfikację podpisu. Atakujący modyfikuje payload (np. "role":"admin"), ustawia alg:"none", usuwa podpis, a serwer akceptuje token.

Oryginał: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Atak: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (pusty podpis, końcowa kropka). Podatny serwer pomyślnie weryfikuje token i przyznaje dostęp administratora.

Nigdy nie akceptuj alg:"none" w środowisku produkcyjnym. Jawnie określaj dozwolone algorytmy: jwt.decode(token, key, algorithms=["HS256"]). Większość nowoczesnych bibliotek (PyJWT 2+, jsonwebtoken 9+) domyślnie odrzuca alg=none.

Jeśli serwer używa RS256, a klient zmieni alg na HS256, serwer może przeprowadzić weryfikację, używając klucza publicznego RSA jako sekretu HMAC. Ponieważ klucz publiczny jest... publiczny, atakujący podpisuje nim dowolne payloady, a serwer je weryfikuje.

Kroki: 1) Pobierz klucz publiczny z endpointu JWKS. 2) Zbuduj złośliwy payload. 3) Podpisz go za pomocą HMAC-SHA256, używając surowych bajtów klucza publicznego PEM jako sekretu HMAC. 4) Ustaw alg:"HS256" w nagłówku. 5) Ścieżka HS256 serwera pomyślnie przeprowadza weryfikację.

Zawsze jawnie określaj oczekiwany algorytm w wywołaniu weryfikacji. Nigdy nie wyprowadzaj algorytmu z nagłówka tokenu. Używaj oddzielnych ścieżek kodu dla RS256 i HS256, których wywołujący nie może przełączać.

HS256 ze słabymi sekretami (o entropii mniejszej niż 256 bitów) można złamać metodą brute force offline. Narzędzia takie jak hashcat obsługują łamanie JWT: hashcat -a 0 -m 16500 token.txt wordlist.txt. Używaj kryptograficznie losowych sekretów o długości co najmniej 32 bajtów.

Nagłówek kid (identyfikator klucza) wskazuje, którego klucza należy użyć. Jeśli serwer używa kid jako parametru zapytania SQL lub ścieżki systemu plików bez odpowiedniego oczyszczenia: kid="../../dev/null" → HMAC z pustym kluczem → sfałszowany token zostaje zaakceptowany. Zawsze oczyszczaj kid.

Nagłówek jwk zawiera osadzony klucz publiczny używany do weryfikacji. Podatny serwer może użyć bezpośrednio osadzonego klucza, pozwalając atakującemu dostarczyć własną parę kluczy, podpisać token kluczem prywatnym i osadzić klucz publiczny. Weryfikuj wyłącznie względem zarejestrowanych kluczy.

Niektóre implementacje zapominały sprawdzać claim exp lub niespójnie korzystały z czasu serwera. Zawsze jawnie weryfikuj exp, nbf i iat. Używaj biblioteki, która domyślnie je sprawdza, i nigdy nie wyłączaj walidacji claimów w środowisku produkcyjnym.

W ataku pomieszania kluczy RS256→HS256 czego atakujący używa jako sekretu HMAC?

Podatności JWT wynikają z zaufania do nagłówka alg, akceptowania alg=none i używania słabych sekretów. Naprawa: przypinaj algorytmy po stronie weryfikatora, używaj silnych sekretów i oczyszczaj kid. Dalej: bezpieczne praktyki implementacji JWT.