8. Podatności JWT

Jednym z często stosowanych narzędzi do przechowywania informacji w aplikacjach internetowych są tokeny w formacie JWT (JSON web tokens). Najpopularniejszym zastosowaniem jest przechowywanie po stronie klienckiej informacji o uwierzytelnionej sesji, ale są na tyle uniwersalne, że mogą służyć też innym celom. Format jest ustandaryzowany w dokumencie RFC 7519 [35]. Przed opisaniem potencjalnych problemów przy używaniu JWT przyjrzyjmy się bliżej formatowi. Składa się on trzech części:

  • nagłówka w formacie JSON zawierającego informację o algorytmie użytym do podpisania oraz może zawierać informacje o kluczach potrzebnych do weryfikacji (jwk),
  • treści w formacie JSON,
  • podpisu cyfrowego.

Wszystkie trzy części kodowane są do tekstowej postaci zgodnej z polami URL algorytmem Base64URL a następnie po połączeniu kropkami stanowią token.

Tokeny, jako, że są kryptograficznie podpisane traktujemy jako całkowicie zaufane źródło informacji, a są przechowywane wyłącznie po stronie klienckiej. Z tego powodu są chętnie atakowane w celu przejęcia uwierzytelnionych sesji. Potencjalne problemy wynikają z niedokładnej lub niepoprawnej implementacji standardu w bibliotekach do obsługi, bądź po stronie aplikacji – brak weryfikacji oczekiwanej postaci tokenu. Przyjrzyjmy się im:

  • pierwszy problem to, jak w przypadku każdej weryfikacji uwierzytelnienia, nie sprawdzanie na wszystkich końcówkach API bądź ignorowanie zdefiniowanego w tokenie czasu życia,
  • ataki brute force na klucz HMAC jeśli taki jest użyty (kategoria złego użycia kryptografii),
  • modyfikacja algorytmu podpisu na ‘none’. Standard definiuje format nieuwierzytelniony (bez podpisu) i jeżeli po stronie aplikacji nie zostanie sprawdzone czy oczekiwany algorytm służył do podpisu, jest to najprostsza metoda obejścia podpisu [36],
  • modyfikacja algorytmu z podpisu RSA (asymetrycznego) na podpis HMAC (symetryczny) – do podpisu – w efekcie klucz publiczny zostanie użyty jako klucz symetryczny [37],
  • dodanie własnego klucza publicznego w nagłówku [38].
Obrona trywialna, ale wiele aplikacji, w których znaleziono podatności tego typu jej zaniechała zakładając, że np. token w ciasteczku jest bezpieczny – poprawna weryfikacja czy parametry tokenu odpowiadają oczekiwanym przez aplikację parametrom.