Security+ Academy · Lekcja

Niesprawne uwierzytelnianie i niebezpieczna deserializacja

Poznają Państwo, jak słabe zarządzanie sesjami, credential stuffing i podatności niebezpiecznej deserializacji umożliwiają atakującym przejmowanie kont i wykonywanie kodu.

Niesprawne uwierzytelnianie i niebezpieczna deserializacja to bezpłatna lekcja Security+ Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Security+ Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Security+ Academy zawiera 4 lekcji w sumie.

Czym jest broken authentication?

Broken authentication oznacza słabości w sposobie, w jaki aplikacja weryfikuje tożsamość użytkownika i zarządza sesjami. Gdy uwierzytelnianie jest wadliwe, atakujący mogą przejąć hasła, klucze lub tokeny sesji i podszyć się pod innych użytkowników. Ta kategoria OWASP Top 10 obejmuje szeroki zakres luk: słabe dane uwierzytelniające, nieprawidłowe zarządzanie sesjami, brak MFA oraz niezabezpieczone przechowywanie danych uwierzytelniających.

Credential stuffing i password spraying

Credential stuffing wykorzystuje duże listy par nazw użytkowników i haseł ujawnionych w wyniku wcześniejszych wycieków danych i sprawdza je w innych witrynach, wykorzystując ponowne używanie haseł. Password spraying opiera się na odwrotnym podejściu: niewielki zestaw popularnych haseł (np. Password1!) jest sprawdzany dla wielu kont, aby uniknąć progów blokowania kont. Oba ataki są skuteczne z powodu słabych zasad dotyczących haseł i braku MFA.

# Password spraying concept (defensive awareness)
# Attacker tries 'Password1!' against 10,000 accounts
# rather than trying 10,000 passwords against 1 account
# This avoids triggering lockout policies (e.g., 5 attempts/account)

# Defense: MFA + adaptive authentication + rate limiting

Słabe zarządzanie sesjami

Sesje łączą uwierzytelnionych użytkowników ze stanem aplikacji. Luki wynikające ze słabego zarządzania sesjami obejmują: przewidywalne wartości tokenów sesji (sekwencyjne identyfikatory, które atakujący może odgadnąć), tokeny, które nigdy nie wygasają, tokeny przesyłane przez HTTP zamiast HTTPS oraz brak unieważniania tokenów po wylogowaniu. Atakujący, który uzyska prawidłowy token sesji, może podszyć się pod użytkownika bez znajomości jego hasła.

# Signs of weak session management:
# /login response sets:
# Set-Cookie: session=1042  (predictable, sequential)
# Missing: Secure; HttpOnly; SameSite flags
# Missing: session expiry / Max-Age
# Logout does NOT invalidate server-side session

Utrwalenie i przejęcie sesji

Session fixation zmusza ofiarę do używania identyfikatora sesji wybranego przez atakującego. Na przykład atakujący wysyła odsyłacz ze wstępnie ustawionym plikiem cookie sesji; po uwierzytelnieniu ofiary używa tego samego identyfikatora sesji, aby uzyskać dostęp do konta. Session hijacking polega na kradzieży istniejącego tokenu sesji za pomocą XSS, nasłuchiwania ruchu sieciowego (w niezaszyfrowanych połączeniach) lub skradzionych plików cookie. Rozwiązanie: generowanie nowych identyfikatorów sesji po zalogowaniu i używanie HTTPS wszędzie.

Niezabezpieczone przechowywanie haseł

Przechowywanie haseł w postaci jawnego tekstu lub z użyciem słabego funkcji skrótu (MD5, SHA-1) jest krytycznym błędem uwierzytelniania. Po włamaniu do bazy danych hasła w postaci jawnego tekstu i słabe skróty można natychmiast wykorzystać. Bezpieczne przechowywanie haseł wymaga adaptacyjnego algorytmu funkcji skrótu przeznaczonego do haseł: bcrypt, Argon2 lub PBKDF2 z losową solą dla każdego użytkownika. Algorytmy te są celowo powolne, co sprawia, że łamanie haseł offline wymaga dużych nakładów obliczeniowych.

# Python example — secure password hashing with bcrypt
import bcrypt

# Hash a password (includes random salt automatically)
password = b'UserSuperSecret123'
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))

# Verify
bcrypt.checkpw(password, hashed)  # returns True

Czym jest niezabezpieczona deserializacja?

Serializacja konwertuje stan obiektu do określonego formatu (JSON, XML, binarnego) w celu jego przechowywania lub przesyłania. Deserializacja odtwarza obiekt na podstawie tego formatu. Niezabezpieczona deserializacja występuje, gdy aplikacja deserializuje dane kontrolowane przez atakującego bez ich walidacji, umożliwiając atakującemu modyfikowanie zserializowanych obiektów w celu manipulowania logiką aplikacji, eskalowania uprawnień lub wykonania dowolnego kodu na serwerze.

Przykład ataku na deserializację

Typowy schemat ataku obejmuje zserializowane obiekty przekazywane w plikach cookie lub parametrach API. Na przykład aplikacja Java używająca ObjectInputStream.readObject() dla niezaufanych danych może doprowadzić do Remote Code Execution (RCE) za pośrednictwem łańcuchów gadgetów w popularnych bibliotekach (Apache Commons Collections). Atakujący tworzy złośliwy zserializowany ładunek, wysyła go do aplikacji, a kod zostaje wykonany podczas deserializacji — często jeszcze przed przeprowadzeniem kontroli uwierzytelniania.

# Insecure deserializing pattern (Python pickle — dangerous)
import pickle

# Attacker-controlled payload
class Exploit:
    def __reduce__(self):
        import os
        return (os.system, ('id',))  # executes 'id' on server

payload = pickle.dumps(Exploit())
pickle.loads(payload)  # RCE! Never deserialize untrusted data with pickle

Zapobieganie niezabezpieczonej deserializacji

Zabezpieczenia przed niezabezpieczoną deserializacją obejmują: nigdy nie deserializować niezaufanych danych przy użyciu niebezpiecznych formatów, takich jak natywna serializacja Java lub Python pickle. Należy preferować formaty zawierające wyłącznie dane (JSON, XML) zamiast serializacji binarnej. Jeśli deserializacja jest konieczna, należy wdrożyć kontrole integralności (podpisywanie zserializowanego obiektu za pomocą HMAC), używać list dozwolonych w celu ograniczenia klas, które mogą być deserializowane, oraz uruchamiać kod deserializacji w odizolowanych środowiskach o niskich uprawnieniach.

# Safe approach: sign serialized data before transmitting
import hmac, hashlib, json

def serialize_safe(data, secret):
    payload = json.dumps(data)  # use JSON, not pickle
    sig = hmac.new(secret.encode(), payload.encode(), hashlib.sha256).hexdigest()
    return payload + '.' + sig

Uwierzytelnianie wieloskładnikowe jako mechanizm kontroli

Multi-Factor Authentication (MFA) to pojedynczy mechanizm kontroli, który zapewnia największą ochronę przed broken authentication. Nawet jeśli dane uwierzytelniające zostaną przejęte w wyniku phishingu, credential stuffing lub wycieku bazy danych, atakujący bez drugiego składnika nie może się uwierzytelnić. Firma Microsoft podaje, że MFA blokuje ponad 99,9% automatycznych prób przejęcia kont. MFA powinno być obowiązkowe dla kont uprzywilejowanych i zalecane wszystkim użytkownikom.

Blokada konta i ograniczanie liczby prób

Zasady blokowania konta tymczasowo wyłączają konto po określonej liczbie nieudanych prób logowania, spowalniając ataki siłowe. Blokady mogą jednak umożliwiać przeprowadzanie ataków typu odmowa usługi przeciwko uprawnionym użytkownikom — osoby atakujące celowo doprowadzają do blokady kont, aby uniemożliwić dostęp. Ograniczanie liczby prób (spowalnianie odpowiedzi po kolejnych nieudanych próbach przy użyciu wykładniczego zwiększania opóźnienia) oraz wyzwania typu CAPTCHA ograniczają skuteczność ataków siłowych przy mniejszym ryzyku DoS.

Wadliwe uwierzytelnianie w OWASP Top 10

OWASP wymienia wadliwe uwierzytelnianie jako krytyczne ryzyko, ponieważ błędy uwierzytelniania są zarówno częste, jak i bardzo poważne w skutkach. Najważniejsze oznaki wadliwego uwierzytelniania to: zezwalanie na zautomatyzowane ataki, takie jak credential stuffing, zezwalanie na ataki siłowe lub inne ataki zautomatyzowane, dopuszczanie haseł domyślnych, słabych lub powszechnie znanych, stosowanie słabych procesów odzyskiwania danych uwierzytelniających, przechowywanie haseł w postaci jawnego tekstu lub przy użyciu słabego algorytmu skrótu oraz brak uwierzytelniania wieloskładnikowego albo jego nieskuteczne działanie.

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że: wadliwe uwierzytelnianie obejmuje słabe mechanizmy sesji, credential stuffing oraz niezabezpieczone przechowywanie haseł, niebezpieczna deserializacja może prowadzić do zdalnego wykonania kodu za pośrednictwem złośliwych obiektów zserializowanych, a MFA, haszowanie haseł za pomocą bcrypt, regenerowanie sesji po zalogowaniu oraz podpisywanie danych zserializowanych to kluczowe mechanizmy ochrony. Następnie omówimy bezpieczny cykl SDLC oraz narzędzia SAST i DAST.

Często zadawane pytania

Czy lekcja „Niesprawne uwierzytelnianie i niebezpieczna deserializacja” jest bezpłatna?

Tak — pełny tekst „Niesprawne uwierzytelnianie i niebezpieczna deserializacja” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Security+ Academy, przejdź na CoddyKit PRO. Kurs Security+ Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Niesprawne uwierzytelnianie i niebezpieczna deserializacja”?

Poznają Państwo, jak słabe zarządzanie sesjami, credential stuffing i podatności niebezpiecznej deserializacji umożliwiają atakującym przejmowanie kont i wykonywanie kodu. Ćwiczysz Security+ Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Security+ Academy?

Nie wymagamy żadnego doświadczenia. Security+ Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Niesprawne uwierzytelnianie i niebezpieczna deserializacja”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Security+ Academy?

Tak. Każda lekcja Security+ Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Wstrzykiwanie SQL i poleceń
Cross-Site Scripting (XSS) i CSRF
Niesprawne uwierzytelnianie i niebezpieczna deserializacja
Bezpieczny cykl wytwarzania oprogramowania, SAST i DAST

← Powrót do Security+ Academy