Skip to main content
idego

Używanie JWT z otwartymi oczami – ryzyko ślepego korzystania z bibliotek zewnętrznych

Autor: Idego Group

Używanie JWT z otwartymi oczami – ryzyko ślepego korzystania z bibliotek zewnętrznych

JSON Web Token to standard zdefiniowany w RFC 7519 do bezpiecznego przesyłania danych między usługami. Zapewnia integralność danych, pozwalając usłudze weryfikować, czy token nie został zmodyfikowany podczas przesyłania. Programiści webowi często zlecają implementację JWT zewnętrznym bibliotekom, zakładając, że są one poprawne i bezpieczne. Jednak ślepe ufanie tym bibliotekom może mieć poważne konsekwencje dla bezpieczeństwa.

JWT składa się z trzech elementów zakodowanych w base64, rozdzielonych kropkami: nagłówka, ładunku i podpisu. Nagłówek określa typ tokena i algorytm używany do tworzenia podpisu. Ładunek zawiera dane funkcjonalne, takie jak identyfikacja użytkownika. Podpis gwarantuje integralność danych poprzez podpisanie zakodowanego nagłówka i ładunku kluczem prywatnym.

RFC 7519 dopuszcza none jako wartość parametru nagłówka alg, przeznaczoną dla przypadków, gdy bezpieczeństwo danych jest zapewnione innymi środkami. Jednak słabo zaimplementowane biblioteki JWT mogą albo zwracać błąd 500, albo całkowicie pomijać weryfikację podpisu po napotkaniu tej wartości. Mogłoby to pozwolić atakującym na wysyłanie niepodpisanych tokenów i otrzymywanie poufnych danych bez żadnej weryfikacji.

Krytyczna podatność może powstać, gdy klienci mogą określić HS256 jako algorytm podczas podpisywania kluczem publicznym serwera. Nieprawidłowo skonfigurowane systemy mogą weryfikować przy użyciu HMAC z tym samym kluczem publicznym, całkowicie obchodząc zamierzone zabezpieczenia. Atakujący może sfałszować tokeny, podpisując je publicznie dostępnym kluczem, twierdząc jednocześnie, że używa algorytmu symetrycznego.

Samo dekodowanie base64 nie weryfikuje autentyczności tokena. Samo dekodowanie danych nagłówka i ładunku nie potwierdza, że token pochodzi z deklarowanego źródła lub nie został zmodyfikowany. Częstym błędem jest używanie tylko funkcji dekodowania zamiast funkcji weryfikacji sprawdzających kryptograficzny podpis.

Biblioteki bezpieczeństwa są tak godne zaufania, jak ich implementacje. Chociaż rozwiązania zewnętrzne są generalnie odpowiednie, programiści powinni dokładnie rozumieć, jak działają. Aktualizuj biblioteki, monitoruj pod kątem podatności i aktualizuj szybko po odkryciu problemów.

Powiązane artykuły