token w nieprawidłowym formacie Base64

Token w nieprawidłowym formacie Base64 wskazuje na błąd generowania lub uszkodzenie podczas transmisji.

Co oznacza nieprawidłowy zapis tokenu Base64

Token w nieprawidłowym formacie Base64 to ciąg znaków, którego nie można poprawnie zdekodować według reguł użytego wariantu kodowania. Klasyczny Base64 opisany w RFC 4648 korzysta z 64 znaków: wielkich i małych liter alfabetu łacińskiego, cyfr oraz znaków „+” i „/”. Końcowe znaki „=” mogą pełnić funkcję dopełnienia, czyli paddingu, gdy liczba bajtów danych wejściowych nie dzieli się przez trzy. Sam fakt, że token zawiera litery i cyfry, nie wystarcza więc do uznania go za poprawny.

Błąd może wynikać z obecności niedozwolnego znaku, usunięcia części ciągu, nieprawidłowej liczby znaków albo niewłaściwego położenia dopełnienia. W poprawnym klasycznym Base64 długość całego tekstu zwykle jest wielokrotnością czterech, a znak „=” występuje wyłącznie na końcu i może pojawić się najwyżej dwa razy. Niektóre biblioteki dopuszczają brak paddingu i uzupełniają go samodzielnie, inne traktują taki zapis jako błąd. Znaczenie komunikatu zależy zatem od konkretnego dekodera oraz od tego, czy aplikacja oczekuje klasycznego Base64, czy jego odmiany.

Różnica między Base64 a Base64URL w tokenach internetowych

W aplikacjach internetowych często stosuje się Base64URL, czyli wariant przystosowany do umieszczania danych w adresach URL i nagłówkach HTTP. W tym zapisie znak „+” jest zastępowany przez „-”, a znak „/” przez „_”. Padding „=” bywa pomijany. Token zakodowany jako Base64URL może więc zostać odrzucony przez dekoder oczekujący klasycznego Base64, mimo że jego zawartość została zakodowana prawidłowo dla innego wariantu. Odwrotna sytuacja również prowadzi do błędu, gdy dekoder URL-safe wymaga znaków „-” i „_”, a otrzymuje „+” lub „/”.

Przykładem struktury wykorzystującej Base64URL jest token JWT. Standardowy JWT składa się z trzech części rozdzielonych kropkami: nagłówka, danych oraz podpisu. Dwie pierwsze części są zapisane jako Base64URL bez dopełnienia, natomiast podpis także ma postać zakodowanego ciągu Base64URL. Nie każdy token zawierający kropki jest jednak JWT, dlatego sama próba rozdzielenia go na trzy elementy nie stanowi poprawnej diagnozy. Najpierw trzeba ustalić, jaki format przewidział twórca konkretnej aplikacji, a dopiero potem zastosować właściwe reguły dekodowania.

Typowe źródła uszkodzenia podczas tworzenia i przesyłania

Nieprawidłowy token może powstać już w chwili generowania. Błąd programistyczny może polegać na zakodowaniu reprezentacji tekstowej zamiast bajtów, dwukrotnym zakodowaniu wartości, obcięciu końcówki albo połączeniu tokenu z dodatkowym prefiksem, którego dekoder nie obsługuje. Częstym przypadkiem jest także pomieszanie surowej wartości z całym nagłówkiem autoryzacyjnym. Przykładowo aplikacja może oczekiwać samego tokenu, a otrzymać tekst zawierający „Bearer ”. Taki prefiks jest poprawny w nagłówku HTTP „Authorization”, lecz nie należy do danych Base64 i musi zostać odseparowany przed dekodowaniem, jeśli wymaga tego użyta biblioteka.

Do uszkodzenia może dojść podczas transportu lub zapisu. Znak „+” może zostać potraktowany jako spacja po przejściu przez formularz kodowany jako application/x-www-form-urlencoded. Token może również zostać zmieniony przez nieprawidłowe zawijanie wierszy, konwersję kodowania znaków, obcięcie pola w bazie danych albo błędne kopiowanie z interfejsu użytkownika. Problem nie zawsze oznacza awarię sieci: nawet udana transmisja HTTP może dostarczyć zmienioną wartość, jeżeli po jednej stronie użyto Base64, a po drugiej Base64URL. Przy analizie warto porównać długość tokenu przed wysłaniem i po odebraniu, sprawdzić znaki niewystępujące w dozwolonym alfabecie oraz ustalić, czy klient i serwer stosują ten sam wariant.

Bezpieczne postępowanie z błędnym tokenem w serwisie

Diagnostykę należy rozpocząć od ustalenia miejsca, w którym token przestaje być poprawny: podczas generowania, zapisu, odczytu konfiguracji, budowania żądania czy dekodowania po stronie odbiorcy. Warto rejestrować metadane potrzebne do porównania przepływu, takie jak długość ciągu, wybrany wariant kodowania i etap obsługi, ale nie należy zapisywać pełnej wartości tokenu w zwykłych logach. Do testów można użyć kontrolnej, nieaktywnej wartości oraz dekodera działającego w trybie ścisłym, który zgłasza niedozwolone znaki i błędne paddingowanie zamiast je cicho ignorować. Usunięcie białych znaków może być uzasadnione tylko wtedy, gdy format dopuszcza takie separatory; automatyczne wycinanie dowolnych znaków może ukryć rzeczywistą usterkę.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, w tym diagnostyką problemów z aplikacjami, konfiguracją oraz komunikacją między urządzeniami. W przypadku błędu tokenu serwisant może sprawdzić ustawienia programu, wersje używanych komponentów, sposób przekazywania parametrów i zgodność formatów po stronie klienta. Sama poprawna składnia Base64 nie potwierdza jeszcze ważności tokenu: po dekodowaniu aplikacja może dodatkowo sprawdzać strukturę danych, czas obowiązywania, podpis lub uprawnienia. Dlatego naprawa powinna obejmować cały przepływ wartości, a nie tylko ręczne dopisanie brakujących znaków „=” na końcu.