Przewodnik rozwiązywania problemów z sesją aplikacji hostowanej samodzielnie po zmianach w proxy i plikach cookie

Bezpieczne podejście polega na traktowaniu porównania warstwa po warstwie żądań bezpośrednich i przekazywanych przez proxy, plików cookie w odpowiedziach, pamięci przeglądarki oraz stanu sesji backendu jako sekwencji obserwowalnych bramek, a nie pojedynczego polecenia.

W przypadku samodzielnie hostowanej aplikacji internetowej działającej za odwrotnym proxy praktyczne ryzyko polega na tym, że użytkownicy zostaną wylogowani, utkną w pętli przekierowań lub nie będą mogli ustanowić sesji po zmianach proxy albo plików cookie. Zapisz bieżącą tożsamość i punkt przywracania, zacznij od najmniej inwazyjnego rozróżnienia, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz przerwij, gdy stan pamięci stanie się niestabilny lub jedyna możliwa do odzyskania kopia zostałaby ujawniona. Poniższa procedura kończy się dopiero wtedy, gdy pierwotne zadanie zakończy się powodzeniem albo dowody osiągną granicę wymagającą eskalacji.

Odtwórz jedną ścieżkę sesji i zachowaj dowody

Wybierz jednego użytkownika, profil przeglądarki, nazwę hosta i ścieżkę logowania. Zapisz pierwsze żądanie kończące się błędem, sekwencję statusów, lokalizacje przekierowań, nagłówki odpowiedzi Set-Cookie z zamaskowanymi wartościami, pliki cookie żądania, logi proxy, logi aplikacji oraz dokładną zmianę konfiguracji poprzedzającą awarię.

Nie zaczynaj od usunięcia wszystkich plików cookie ani rotacji sekretu aplikacji. Użyj prywatnego profilu przeglądarki jako czystego punktu kontrolnego, zachowując profil powodujący błąd do porównania. Sprawdź, czy bezpośredni dostęp do backendu działa; pozwala to rozdzielić uwierzytelnianie aplikacji od zachowania adresów URL i plików cookie zależnego od proxy.

Przerwij, jeśli aplikacja ujawnia tokeny w logach, proxy akceptuje sfałszowane nagłówki przekazywania od niezaufanych klientów lub logowanie omija TLS. Zabezpiecz dane uwierzytelniające i skoryguj granicę bezpieczeństwa przed kontynuowaniem diagnostyki funkcjonalnej.

Zweryfikuj schemat, hosta i zaufanie do przekazywania

Porównaj zewnętrzny adres URL z tym, co widzi aplikacja: schematem, hostem, portem, ścieżką bazową i adresem IP klienta. Sprawdź Host, X-Forwarded-Proto lub ustandaryzowane nagłówki przekazywania oraz listę zaufanych proxy aplikacji. Backend, który uważa żądania HTTPS za HTTP, może odrzucać bezpieczne pliki cookie lub generować niekończące się przekierowanie do HTTPS.

Użyj jednego zaufanego proxy do ustawiania lub zastępowania nagłówków przekazywania i skonfiguruj aplikację tak, aby ufała tylko temu przeskokowi. Nie dołączaj bezkrytycznie wartości dostarczonych przez klienta. Po każdej zmianie przetestuj logowanie i jedno bezwzględne przekierowanie, zamiast jednocześnie modyfikować nagłówki proxy i bazowy adres URL aplikacji.

Poradnik ZimaSpace dotyczący diagnozowania logowania bezpośredniego i przez proxy wykorzystuje to samo porównanie po ponownym uruchomieniu proxy. Przykład z Immich jest węższy, ale ścieżkę dowodową można zastosować również tutaj: najpierw potwierdź działanie sesji backendu, a następnie sprawdź nagłówki przekazywania, routing i stan przeglądarki.

Sprawdź zakres plików cookie i decyzje przeglądarki

Sprawdź nazwę pliku cookie, atrybuty Domain, Path, Secure, HttpOnly i SameSite, datę wygaśnięcia oraz to, czy istnieją zduplikowane pliki cookie o tej samej nazwie w różnych ścieżkach lub domenach. Narzędzia deweloperskie przeglądarki pokazują, czy plik cookie został zapisany, odrzucony lub pominięty przy następnym żądaniu; same logi serwera nie ujawniają tej decyzji.

Omówienie zachowania plików cookie SameSite przygotowane przez OWASP wyjaśnia, jak wartości SameSite kontrolują przekazywanie plików cookie między witrynami. Jeśli uwierzytelnianie przebiega między witrynami lub korzysta z osadzonego przepływu, SameSite=None wymaga również atrybutu Secure; w przypadku prostej aplikacji działającej w tej samej witrynie niepotrzebne rozszerzanie zakresu pliku cookie osłabia projekt.

Po zapisaniu informacji usuń tylko dotknięty problemem plik cookie w profilu kontrolnym, a następnie powtórz logowanie. Jeśli nowy plik cookie działa, podczas gdy zachowany profil nadal zawodzi, porównaj zakres i czas wygaśnięcia; jeśli oba warianty zawodzą, wróć do nagłówków odpowiedzi lub magazynu sesji backendu, zamiast wielokrotnie czyścić stan.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź współdzielony stan sesji i zweryfikuj poprawkę

W przypadku aplikacji wielokontenerowych lub replikowanych potwierdź, że każda instancja używa tego samego sekretu podpisywania sesji, źródła czasu oraz - gdy jest to wymagane - współdzielonego backendu sesji. Proxy przełączające ruch między instancjami może sprawiać wrażenie losowego wylogowywania, gdy jedna instancja nie potrafi zweryfikować pliku cookie wystawionego przez inną.

Omówienie granicy bezpieczeństwa SameSite autorstwa PortSwiggera koncentruje się na bezpieczeństwie, ale wyjaśnia, że SameSite jest granicą egzekwowaną przez przeglądarkę, a nie uniwersalnym przełącznikiem naprawiającym logowanie. Zachowaj ochronę CSRF, dopasowując ją do rzeczywistego pochodzenia aplikacji i przepływu przekierowań.

Zweryfikuj logowanie, wylogowanie, wygaśnięcie bezczynnej sesji, ponowne uruchomienie przeglądarki, zmianę hasła oraz dostęp za pośrednictwem zamierzonych wewnętrznych i zdalnych nazw hostów. Zamknij zgłoszenie dopiero wtedy, gdy stare pliki cookie zawodzą bezpiecznie, nowe sesje przetrwają normalny routing, a żaden nagłówek przekazywania ani atrybut pliku cookie nie został poluzowany bardziej, niż wymaga tego udokumentowana potrzeba.