Jak testować logowanie, wylogowanie i reset hasła?

Napis „Wylogowano” wygląda przekonująco. Dopiero otwarcie prywatnego panelu pokazuje, czy dostęp rzeczywiście zniknął. Podobnie komunikat „Hasło zmienione” nie dowodzi, że stary sekret przestał działać albo że link resetu można wykorzystać tylko raz. Testowanie tych funkcji polega na porównaniu kilku stanów i przejść między nimi, a nie tylko na sprawdzeniu formularzy.

W tej lekcji przygotujesz próby poprawnych i błędnych danych, sprawdzisz wygaśnięcie dostępu oraz wykonasz reset z ponownym użyciem kodu. Materiał jest dla początkujących testerów, którzy znają formularze i potrafią uruchomić lokalną stronę. Nie wymaga programowania. Pracujemy na demonstracji: konto tester oraz jawne klucze demo-start, demo-nowy, demo-drugi są syntetycznymi rekwizytami. Nie wpisuj prawdziwego hasła, adresu poczty ani danych klienta.

1. Oddziel wymaganie od implementacji demonstracyjnej

Uwierzytelnianie to weryfikacja tożsamości, a autoryzacja to decyzja, do czego dana tożsamość ma dostęp. Poprawne zalogowanie nie oznacza automatycznie prawa do wszystkich zasobów. Sesja pozwala aplikacji utrzymywać kontekst kolejnych działań. Pojęcia te porządkuje OWASP Authentication Cheat Sheet. W produkcie decyzje o dostępie muszą być egzekwowane po stronie zaufanego systemu, zwykle serwera.

Nasze laboratorium ma inny cel: pozwala zobaczyć stany bez zakładania kont i wysyłania poczty. Cała logika działa w JavaScript. „Panel prywatny” jest tekstem na stronie, a jego dostępność wynika z lokalnego cookie. Użytkownik może zmienić kod i pamięć przeglądarki. Cookie nie ma HttpOnly, klucze są jawne, a generator kodu nie jest mechanizmem kryptograficznym. To nie jest bezpieczna implementacja logowania ani wzorzec do skopiowania do produktu.

Przed testem zapisz specyfikację demo v1.0:

• tester i demo-start pozwalają wejść do panelu. Wielkość liter klucza ma znaczenie.
• Niepoprawna nazwa lub klucz daje wspólny komunikat „Niepoprawne dane demo”.
• Dostęp trwa 120 sekund od loginu. Wylogowanie ma go odebrać i usunąć cookie, również po odświeżeniu.
• Reset dla każdej nazwy pokazuje ten sam komunikat. Jawna skrzynka testowa zawiera kod tylko dla konta tester.
• Kod jest ważny 60 sekund i jednorazowy. Zmiana klucza odbiera dostęp i wymaga ponownego loginu.
• Po zmianie działa nowy klucz; stary jest odrzucany. Reset ćwiczenia przywraca początkowy klucz.

Podane czasy są regułą ćwiczenia, a nie zaleceniem dla każdej aplikacji. W produkcie ustal z zespołem m.in. czas bezczynności, maksymalny czas sesji, zachowanie po zmianie hasła i zakres wylogowania. Bez tego tester nie potrafi ocenić, czy druga karta powinna zostać wylogowana, czy funkcja dotyczy wszystkich urządzeń.

2. Przygotuj powtarzalny punkt startowy

W katalogu projektu uruchom node tools/serwer-lekcji.cjs. Jeśli proces już działa na porcie 8787, użyj go. Otwórz http://127.0.0.1:8787/content/cwiczenia/sesja-demo/lab.html. Szczegóły znajdziesz w instrukcji laboratorium. Serwer dostarcza tutaj wyłącznie plik HTML; kliknięcia nie wywołują API logowania. Filtr Fetch/XHR w Network nie pokaże więc żądań uwierzytelniania.

Kliknij „Resetuj ćwiczenie”. Sprawdź klucz demo-start, pustą skrzynkę oraz przesunięcie zegara 0 s. Zanotuj wersję przeglądarki, datę i wersję demo. Odświeżenie nie zastępuje resetu: zachowuje cookie i dane magazynów, ale zeruje testowe przesunięcie czasu i usuwa kod trzymany tylko w zmiennej tej strony. Mieszanie tych operacji daje nieczytelne wyniki.

Otwórz DevTools, następnie Application → Storage → Cookies dla lokalnej witryny. Cookie po loginie nazywa się qa_session_demo_session. Możesz też korzystać z przycisku „Odśwież podgląd pamięci” na stronie. Podgląd przedstawia dane demo; nie jest niezależnym dowodem serwerowej sesji. Nie usuwaj całej pamięci originu między krokami, jeśli właśnie badasz jej zachowanie po wylogowaniu.

Testuj przejście oraz stan końcowy. Ukrycie panelu nie dowodzi odebrania dostępu.

3. Sprawdź dane w izolowanych próbach

Zacznij od poprawnego loginu. Wpisz tester oraz demo-start, kliknij „Zaloguj”, potem „Otwórz panel prywatny”. Oczekujesz napisu „Panel demo: dostęp przyznany.” i cookie z nazwą użytkownika oraz polem until. Pole zawiera termin przyjęty przez kod demonstracji. Nie jest atrybutem Expires cookie i nie powoduje jego automatycznego usunięcia przez przeglądarkę.

Następnie resetuj ćwiczenie przed każdą niezależną próbą:

W obecnej wersji próba DEMO-START daje dostęp. To pierwszy celowy defekt. Formularz porównuje klucze po sprowadzeniu ich do małych liter, mimo że wymaganie rozróżnia wielkość liter. Zapisz konkretne dane i wynik. Nie zgłaszaj ogólnie „słaba polityka haseł”: test dotyczy jednej reguły porównania w demonstracji.

Wspólny komunikat błędu ma ograniczać ujawnianie, które konto istnieje. W realnym produkcie jednak identyczny tekst to tylko jeden element kontroli; różne statusy HTTP, treść odpowiedzi lub powtarzalna różnica czasu mogą nadal ujawniać informacje. Takie obserwacje wymagają uprawnionego środowiska i ustalonego zakresu testów. Nie wyciągaj wniosku o odporności na zgadywanie haseł z kilku ręcznych prób na lokalnym JavaScript.

4. Zweryfikuj wylogowanie działaniem

Zresetuj ćwiczenie i zaloguj się poprawnie. Kliknij „Wyloguj”. Strona pokaże „Brak dostępu” i komunikat wylogowania. Teraz odśwież ją oraz kliknij „Otwórz panel prywatny”, zanim minie 120 sekund. Panel ponownie przyznaje dostęp. Cookie pozostało w pamięci. To drugi celowy defekt: aplikacja zmieniła interfejs, ale nie stan decydujący o dostępie.

Najważniejszym dowodem jest możliwość ponownego wejścia, a cookie pomaga wyjaśnić przyczynę w tej symulacji. W prawdziwej aplikacji sam wpis cookie nie dowodzi aktywnej sesji: serwer mógł już ją unieważnić. I odwrotnie, usunięcie cookie z przeglądarki nie potwierdza unieważnienia po stronie serwera. Kontrolę rzeczywistego zakończenia sesji opisuje OWASP Session Management Cheat Sheet.

Przykładowy raport ma tytuł: „Po wylogowaniu odświeżenie przywraca dostęp do panelu demo”. Dodaj środowisko, reset jako warunek startowy, poprawny login, logout, reload i otwarcie panelu. Oczekiwany wynik: odmowa i usunięte cookie. Rzeczywisty: dostęp oraz zachowane cookie przed końcem ważności. Wpływ opisz jako błędne przejście stanu w ćwiczeniu; demonstracja nie zawiera rzeczywistych prywatnych danych.

Unikaj testu polegającego wyłącznie na przycisku Wstecz. Przeglądarka może pokazać poprzednio wyrenderowaną stronę. Taki ekran jest obserwacją historii lub cache, a nie dowodem, że nowa operacja na chronionym zasobie się powiedzie. Potwierdź zachowanie aktualnym działaniem wymagającym dostępu.

5. Sprawdź czas bez długiego czekania

Po resecie zaloguj się ponownie. Kliknij „Przesuń czas o 121 s”, a następnie „Otwórz panel prywatny”. Oczekujesz odmowy. Ten scenariusz działa poprawnie w v1.0: lokalna funkcja porównuje termin zapisany w cookie z przesuniętym zegarem. UI nie aktualizuje panelu automatycznie w chwili upływu czasu; sprawdzenie następuje przy wybranej akcji.

Nie odświeżaj strony między przesunięciem czasu a sprawdzeniem. Odświeżenie zeruje przesunięcie, choć cookie może pozostać, więc porównujesz inny stan. Zanotuj sekwencję przycisków. Sprawdzenie 121 sekund potwierdza próbkę po granicy 120 sekund; nie jest pomiarem zachowania dokładnie na granicy ani testem zegara serwera.

W produkcie oddziel czas bezczynności od maksymalnego czasu sesji. Aktywność może wydłużać pierwszy, a nie powinna automatycznie znosić drugiego, jeśli tak stanowi specyfikacja. Do takich testów przydaje się kontrolowany zegar środowiska testowego. Nie zmieniaj przypadkowo daty całego systemu: wpływa to również na certyfikaty i inne aplikacje.

6. Zbadaj reset jako sekwencję, nie jeden formularz

Zresetuj stan. W części resetu zostaw tester i kliknij „Poproś o kod”. Skopiuj kod z jawnej skrzynki. Wybierz demo-nowy, wklej kod i kliknij „Zmień klucz”. Teraz sprawdź kolejno: brak dostępu bez loginu, odrzucenie demo-start oraz przyjęcie demo-nowy. Poprawna zmiana ma skutki w kilku miejscach; sam napis o sukcesie nie wystarczy.

Powtórz próbę po resecie, ale przed zatwierdzeniem wpisz kod KOD-BLAD. Powinieneś otrzymać „Kod nieważny lub wygasły.”, a początkowy klucz nadal powinien działać. W kolejnej izolowanej próbie pobierz prawdziwy kod demo, przesuń czas o 121 sekund i spróbuj go użyć. Oczekujesz takiej samej odmowy. Oba scenariusze przechodzą poprawnie.

Osobno sprawdź komunikat prośby dla tester i dla brak. Tekst formularza jest identyczny. Skrzynka demo celowo ujawnia kod tylko dla istniejącego konta: to jawna pomoc testowa, nie produkcyjna odpowiedź użytkownika ani wysłana wiadomość. Prawdziwy reset wymaga osobnego kanału i kontroli dostarczenia wiadomości; tych etapów laboratorium nie modeluje.

OWASP Forgot Password Cheat Sheet wskazuje m.in. ograniczoną ważność i jednorazowość kodów oraz spójny komunikat dla istniejących i nieistniejących kont. Wymagania demo wybierają te reguły do ćwiczenia. Nie obejmują jakości losowości, limitów prób, przechowywania haseł, ochrony przed równoległym użyciem ani dostarczania poczty.

7. Zadanie: udowodnij jednorazowość

Zaprojektuj test, który odpowie, czy kod resetu można wykorzystać po udanej zmianie. Przygotuj warunek startowy, dwie różne wartości nowego klucza i potwierdzenie końcowego stanu. Nie odświeżaj strony i nie pobieraj drugiego kodu. Zachowaj limit 60 sekund albo zacznij od resetu, gdy czas upłynął.

Rozwiązanie: po resecie poproś o kod dla tester. Wybierz demo-nowy i zatwierdź ten kod. Następnie wybierz demo-drugi, pozostaw ten sam kod i zatwierdź ponownie przed upływem 60 sekund. W v1.0 druga zmiana przechodzi. Zaloguj się demo-drugi: dostęp zostaje przyznany. Wymaganie oczekuje odmowy drugiej zmiany i zachowania pierwszego nowego klucza. To trzeci celowy defekt: kod nie został zużyty po pierwszym zatwierdzeniu.

Naprawa lokalnej demonstracji wymaga unieważnienia zmiennej kodu. W produkcie dwa żądania mogą przyjść niemal jednocześnie, dlatego użycie tokenu i zmiana danych wymagają spójnej kontroli po stronie serwera. Ręczna sekwencja wykryła ponowne użycie, ale nie sprawdziła wyścigu żądań. Nie dopisuj takiego wyniku do raportu.

8. Uzupełnij plan dla prawdziwego produktu

Zanim przeniesiesz checklistę do aplikacji zespołu, zapytaj, co dzieje się z istniejącymi sesjami po zmianie hasła. Wylogowanie jednej przeglądarki i wylogowanie wszystkich urządzeń to różne funkcje. Przygotuj dwa uprawnione konta testowe albo dwie sesje jednego konta, zgodnie z wymaganiem, i sprawdź dostęp przed zmianą oraz po niej. Nie traktuj wyniku naszego demo jako odpowiedzi na politykę produkcyjną.

Uwzględnij też porzucony proces resetu: użytkownik prosi o wiadomość, ale nie kończy zmiany. Samo zamówienie resetu nie powinno być mylone ze zmianą danych. W demo prośba tworzy tylko kod, więc klucz pozostaje aktywny do zatwierdzenia. W produkcie sprawdź również adres docelowy, treść wiadomości bez ujawnionego hasła i zachowanie starszego linku po wydaniu kolejnego. To dodatkowe przypadki do uzgodnienia, nie wykonane tu testy.

Gdy żądanie w realnej aplikacji kończy się błędem sieci, rozdziel brak odpowiedzi od odmowy uwierzytelnienia. Zapisz operację i stan po ponowieniu. Użytkownik powinien otrzymać zrozumiałą informację, a tester dowód, czy dane zostały zmienione. To pozwala uniknąć raportu o złym haśle, gdy przyczyną była niedostępna usługa.

9. Dowody i dalsza praktyka

Pobierz checklistę do wydruku (PDF).

Laboratorium sprawdzono 2 października 2026 w headless Chromium 151.0.7922.34 przez Playwright. Odtworzono trzy defekty i poprawne kontrole: błędne dane, wygaśnięcie sesji i kodu, odrzucenie starego klucza oraz przyjęcie nowego. Wyniki oraz ograniczenia zapisano w instrukcji. Automatyzacja nie stanowi audytu bezpieczeństwa ani recenzji eksperta.

Użyj checklisty logowania i resetu, aby uporządkować kolejne próby. W następnej lekcji Cookies i pamięć przeglądarki zobaczysz, które stany przeżywają reload i jak porównać dwie karty. Jeśli przygotowujesz raport, skorzystaj także z lekcji Jak opisać błąd.

Źródła pierwotne odczytane 2 października 2026: OWASP Authentication, OWASP Forgot Password, OWASP Session Management. Reguły konta, czasy i obserwowane defekty pochodzą z własnego laboratorium v1.0.