Błędy bezpieczeństwa, które testy penetracyjne aplikacji webowych ujawniają najczęściej

Najczęściej wykrywane błędy bezpieczeństwa w testach penetracyjnych aplikacji webowych obejmują naruszenie kontroli dostępu dotykające około 3,73% testowanych aplikacji, błędy konfiguracji bezpieczeństwa wpływające na 3,00% aplikacji, ataki typu injection wykorzystujące słabości walidacji danych wejściowych oraz błędy kryptograficzne prowadzące do ekspozycji danych przez słabe praktyki szyfrowania.

Artykuł sponsorowany

Te podatności, szeroko udokumentowane w ramach OWASP Top 10:2025, reprezentują krytyczne ryzyka bezpieczeństwa konsekwentnie identyfikowane w różnych aplikacjach webowych. Zrozumienie charakteru, powszechności i technik eksploatacji tych podatności jest niezbędne, aby skutecznie redukować powierzchnię ataku, zanim luki zostaną wykorzystane na szeroką skalę.

Dla szybkiego przeglądu kluczowych klas błędów i ich wpływu warto odnieść się do poniższego zestawienia:

Kategoria	Częstość wykrycia	Typowy wpływ
Naruszenie kontroli dostępu	~3,73%	nieautoryzowany dostęp, eskalacja uprawnień, wyciek danych
Błędy konfiguracji bezpieczeństwa	~3,00%	ekspozycja usług, łatwe obejścia zabezpieczeń, podatność na automatyczne ataki
Ataki typu injection	—	manipulacja danymi, zdalne wykonanie zapytań/komend, pełna kompromitacja
Błędy kryptograficzne	—	ujawnienie danych w tranzycie/spoczynku, osłabienie poufności i integralności

Zobacz: Testy penetracyjne aplikacji webowych na TestPenetracyjny.pl

Naruszenie kontroli dostępu – najpoważniejsza podatność aplikacji webowych

Naruszenie kontroli dostępu utrzymuje pozycję najpoważniejszego ryzyka aplikacji. Błędy autoryzacji mają charakter systemowy—pojedyncze przeoczenie może propagować się przez całą aplikację i dotykać wszystkich użytkowników danej roli.

Pionowa i pozioma eskalacja uprawnień

Pionowa eskalacja uprawnień występuje, gdy użytkownik uzyskuje dostęp do funkcjonalności lub zasobów, do których jego rola nie ma prawa. Przykładowe nadużycia obejmują:

usuwanie kont innych użytkowników,
modyfikację ustawień systemowych,
podgląd wrażliwych danych konfiguracyjnych,
dostęp do interfejsów administracyjnych pominiętych w kontrolach po stronie serwera.

Pozioma eskalacja uprawnień umożliwia dostęp do zasobów należących do innych użytkowników o tym samym poziomie uprawnień. Częstą przyczyną są IDOR, gdzie identyfikatory w URL lub parametrach żądania prowadzą bezpośrednio do zasobów bez weryfikacji uprawnień. Jeśli aplikacja używa przewidywalnych identyfikatorów, np. /user/123 i /user/124, atakujący może inkrementować wartości i przeglądać dane innych użytkowników bez weryfikacji na serwerze.

Niezabezpieczone bezpośrednie odwołania do obiektów i podatności IDOR

Podatności IDOR powstają, gdy aplikacje używają dostarczonych przez użytkownika identyfikatorów do bezpośredniego odwoływania się do obiektów bez poprawnej walidacji autoryzacji. Uporczywa powszechność IDOR wskazuje na brak kontroli autoryzacji na poziomie obiektu.

Przykład w Ruby on Rails: wzorzec podatny @project = Project.find(params[:id]) szuka projektu w całej puli, podczas gdy bezpieczny wzorzec @project = @current_user.projects.find(params[:id]) ogranicza wyniki do zasobów należących do bieżącego użytkownika.

Wymuszone przeglądanie (forced browsing) i ukryte endpointy

Atakujący wywołuje adresy, które nie są linkowane w interfejsie użytkownika, lecz istnieją na serwerze. Brak twardej autoryzacji na ukrytych endpointach tworzy poważną lukę—poleganie na niejawności nie jest kontrolą bezpieczeństwa.

Błędy uwierzytelniania – słabe poświadczenia i niewłaściwe zarządzanie sesją

Błędy uwierzytelniania pozostają krytyczne; mimo standaryzacji w ramach frameworków słabości te wciąż stanowią istotne ryzyko. Obejmują one m.in. następujące obszary:

twardo zakodowane hasła – poświadczenia pozostawione w repozytoriach, plikach konfiguracyjnych lub binariach;
niewystarczające MFA – niespójne egzekwowanie, słabe drugie czynniki, podatne mechanizmy awaryjne;
słabe polityki haseł – krótkie długości, brak złożoności, dopuszczanie haseł z wycieków;
fiksacja sesji – brak regeneracji identyfikatora po zalogowaniu i słabe unieważnianie sesji.

Domyślne i słabe hasła

Wiele systemów jest wdrażanych z niezmienionymi, znanymi domyślnymi poświadczeniami (np. admin/admin, root/root, administrator/password). To otwiera drogę do prostych przejęć kont administracyjnych.

Typowe techniki nadużyć haseł to:

brute force z automatycznym zgadywaniem haseł,
ataki słownikowe z listami popularnych fraz,
credential stuffing z użyciem par z publicznych wycieków.

Słabości wieloskładnikowego uwierzytelniania

Testy często wykrywają implementacje MFA, które można obejść (np. przez pominięcie drugiego kroku lub niespójne egzekwowanie między kanałami WWW/API/mobile). MFA powinno być wymuszane spójnie, z silnymi drugimi czynnikami i bezpiecznymi mechanizmami awaryjnymi.

Podatności w zarządzaniu sesjami

Typowe błędy zarządzania sesją obejmują:

ujawnianie identyfikatorów sesji w URL,
brak unieważnienia sesji po wylogowaniu lub dłuższej bezczynności,
ponowne użycie tego samego identyfikatora po zalogowaniu.

Identyfikatory sesji muszą być kryptograficznie losowe i nieprzewidywalne; pliki cookie powinny mieć ustawione flagi HttpOnly, Secure i atrybut SameSite. Identyfikatory nie powinny nigdy pojawiać się w URL, muszą być unieważniane przy wylogowaniu oraz regenerowane po udanym logowaniu.

Walidacja danych wejściowych i podatności typu injection – fundament ataków na aplikacje webowe

Ataki typu injection, uplasowane na piątym miejscu w OWASP Top 10:2025, wynikają z bezkrytycznego zaufania do danych wejściowych bez odpowiedniej walidacji, sanitizacji i kodowania kontekstowego.

Ataki SQL injection

SQL injection pozwala manipulować zapytaniami w celu uzyskania nieautoryzowanego dostępu, modyfikacji lub usunięcia danych. Przykładowo łączenie danych wejściowych w zapytaniu SELECT * FROM users WHERE username = ' + userInput + ' i wstrzyknięcie ' OR '1'='1 skutkuje warunkiem zawsze prawdziwym.

Zapobieganie wymaga bezwzględnego stosowania zapytań parametryzowanych (prepared statements) oraz ograniczania uprawnień kont bazodanowych do minimum koniecznego.

Podatności cross-site scripting (XSS)

Dla przejrzystości podsumujmy główne odmiany XSS:

reflected XSS,
stored XSS,
DOM-based XSS.

Zapobieganie XSS wymaga kontekstowego kodowania wyjścia (HTML, JavaScript, URL, CSS), polityki Content Security Policy, walidacji danych i bezpiecznych domyślnie szablonów.

Wstrzyknięcia poleceń i wykonywanie komend systemowych

Podatności command injection umożliwiają wykonanie komend systemowych przez niebezpieczne wywołania, np. system("rm " + userSuppliedFile) z wejściem ; malicious_command #. Należy unikać wywołań powłoki i używać bezpiecznych API, a w razie konieczności stosować ścisłe allowlisty oraz parametryzację.

Wstrzyknięcia XML external entity (XXE)

Gdy parsery XML z włączonymi zewnętrznymi encjami przetwarzają niezaufane dokumenty, mogą umożliwić odczyt plików, SSRF lub DoS. Wyłącz przetwarzanie zewnętrznych encji (najlepiej całych DTD) i nie używaj ustawień domyślnych dla niezaufanego XML.

Błędy konfiguracji bezpieczeństwa – cichy sprzymierzeniec kompromitacji

Błędy konfiguracji bezpieczeństwa zajmują drugie miejsce w OWASP Top 10:2025 i odzwierciedlają rosnącą złożoność środowisk oraz trudność w systematycznym hardeningu.

Domyślne poświadczenia i domyślne konfiguracje

W praktyce często spotykane są następujące słabości ustawień startowych:

otwarte, zbędne porty i usługi,
tryby debug w środowisku produkcyjnym,
gadatliwe komunikaty błędów i banery wersji,
permisywne listy ACL i brak segmentacji.

Systemy należy twardo konfigurować: wyłączać zbędne usługi, włączać funkcje bezpieczeństwa, zmieniać domyślne hasła i egzekwować restrykcyjne kontrole dostępu.

Niezałatane i przestarzałe oprogramowanie

Odwlekanie aktualizacji pozostawia znane luki bez łatek (biblioteki front‑end, CMS, serwery WWW). Niezbędne jest systematyczne zarządzanie poprawkami, priorytetyzacja krytycznych luk i utrzymywanie wspieranych wersji.

Błędnie skonfigurowane kontrole dostępu i nadmierne uprawnienia

Najczęściej wykrywane przykłady nadmiernych uprawnień to:

publiczne bucket‑y w chmurze (np. S3/Blob Storage),
API bez uwierzytelniania lub autoryzacji,
udziały sieciowe z odczytem dla „everyone”,
konta bazodanowe z rolami administracyjnymi bez potrzeby.

Zasada najmniejszych uprawnień wymaga przydzielania wyłącznie niezbędnych ról, ich dokumentowania i regularnych przeglądów.

Niezabezpieczona konfiguracja sieci i użycie protokołów

Aby ograniczyć ryzyko wynikające z niezaszyfrowanej komunikacji, zamień niebezpieczne protokoły na bezpieczne odpowiedniki:

HTTP → HTTPS – szyfrowanie i integralność komunikacji klient–serwer;
Telnet → SSH – bezpieczny, szyfrowany dostęp administracyjny;
FTP → SFTP/FTPS – poufność i integralność transferu plików;
SNMP v1/v2 → SNMP v3 – uwierzytelnianie i szyfrowanie zarządzania siecią.

Błędy kryptograficzne i ekspozycja danych wrażliwych – ochrona w spoczynku i w tranzycie

Błędy kryptograficzne dotyczą niewłaściwej ochrony danych przez błędne wdrożenia szyfrowania lub użycie przestarzałych algorytmów i protokołów. Używaj wyłącznie nowoczesnych standardów i wyłącz stare pakiety szyfrów.

Słabe algorytmy szyfrowania i przestarzałe protokoły kryptograficzne

Zamiast historycznych i podatnych rozwiązań (MD5, SHA‑1, RC4, DES, SSL 3.0, TLS 1.0/1.1) preferuj:

TLS 1.3 – najnowszy protokół z bezpiecznymi pakietami szyfrów;
AES‑256‑GCM – wydajne i bezpieczne szyfrowanie symetryczne z uwierzytelnianiem;
SHA‑256/512 – odporne funkcje skrótu do podpisów i HMAC;
ECDHE/ECDSA – nowoczesna wymiana kluczy i podpisy o wysokiej wydajności;
RSA‑2048/3072 – minimalne zalecane długości kluczy dla kompatybilności.

Niewystarczające zarządzanie kluczami

Jedno słabe ogniwo w cyklu życia klucza unieważnia nawet silne algorytmy. Zadbaj o następujące obszary:

generowanie – kryptograficznie silne źródła entropii i właściwe długości kluczy;
przechowywanie – dedykowane KMS/HSM, ścisłe ACL i audyt dostępu;
dystrybucja – wyłącznie kanały szyfrowane i kontrolowane;
rotacja – cykliczna lub po incydencie/podejrzeniu kompromitacji;
separacja – różne klucze per środowisko, system i zastosowanie.

Przechowywanie informacji wrażliwych w postaci jawnej

Najczęściej narażone kategorie danych to:

hasła – zawsze z unikatową solą i odpornymi funkcjami KDF (np. Argon2, bcrypt);
klucze API – przechowywane wyłącznie szyfrowane i rotowane;
poświadczenia DB – trzymane poza repozytorium kodu, z minimalnymi uprawnieniami;
tajemnice kryptograficzne – oddzielone od danych, objęte kontrolą dostępu;
dane osobowe (PII) / dane kart (PCI) – szyfrowanie, minimalizacja zakresu i retencji.

Podatności logiki biznesowej i zaawansowane techniki eksploatacji

Poza błędami implementacji technicznej często ujawniają się luki logiki: nieuwzględnione stany brzegowe, błędne założenia reguł, brak synchronizacji operacji. Są trudne do automatycznego skanowania i wymagają zrozumienia domeny.

Warunki wyścigu i ataki oparte na czasie

Równoległe przetwarzanie bez właściwej synchronizacji narusza spójność i bezpieczeństwo danych (np. token resetu hasła użyty krzyżowo, podwójne wykorzystanie kuponu, częściowe transakcje finansowe).

Fałszowanie żądań po stronie serwera (SSRF)

SSRF umożliwia serwerowi wykonywanie żądań do sieci wewnętrznej, usług metadanych lub systemów zapleczowych. Szczególnie niebezpieczne są ataki na usługi metadanych chmury pod adresem 169.254.169.254, które mogą ujawnić poświadczenia instancji.

Zanieczyszczenie prototypu

W aplikacjach JavaScript (Node.js, SPA) modyfikacja prototypów obiektów, np. wejściem {"__proto__": {"polluted": "value"}}, może globalnie wpływać na logikę i stać się wektorem łączonym z innymi lukami (template injection, DOM XSS).

Wstrzyknięcie szablonu po stronie serwera (SSTI)

SSTI występuje, gdy dane użytkownika są łączone z kodem szablonu. Przykład: twig->render("Hello " . $_GET['name']) zamiast twig->render("Hello {{name}}", ['name' => $_GET['name']]) pozwala na ocenę wyrażeń (name={{7*7}} → Hello 49). Zawsze przekazuj dane jako zmienne szablonu i unikaj konkatenacji.

Niewystarczające logowanie, monitorowanie i obsługa błędów

W OWASP Top 10:2025 kategorie Security Logging & Alerting Failures oraz Mishandling of Exceptional Conditions podkreślają wagę pełnego logowania i reagowania na incydenty. Bez wiarygodnych logów nie wykryjesz ani nie zrozumiesz incydentu.

Niewystarczające logowanie zdarzeń bezpieczeństwa

Minimalny zakres logowania powinien obejmować:

próby i wyniki logowań oraz resetów haseł,
nieudane autoryzacje i dostępy do wrażliwych zasobów,
akcje uprzywilejowane i operacje administracyjne,
zmiany uprawnień i konfiguracji bezpieczeństwa,
masowe operacje na danych (eksporty, hurtowe odczyty).

Logi muszą zawierać tożsamość, znacznik czasu, akcję, zasób i status, być odporne na manipulację (WORM, zewnętrzne SIEM) i przechowywane odpowiednio długo.

Niewystarczające alertowanie i monitorowanie

Warto generować alerty dla następujących wzorców ataków:

wielokrotne nieudane logowania z jednego IP/konta,
nietypowe lokalizacje geograficzne i pory aktywności,
eskalacje uprawnień wykonywane przez nietypowych użytkowników,
masowe odczyty/eksporty danych,
powtarzalne błędy wskazujące próby eksploatacji (np. 401/403/5xx).

Ujawnianie informacji w komunikatach o błędach

Aplikacje nie powinny ujawniać detali (zapytania SQL, wersje serwerów, ścieżki systemowe). Obsługa błędów powinna być scentralizowana—użytkownik widzi komunikaty ogólne, a detale trafiają do bezpiecznych logów.

Nieograniczone zużycie zasobów i podatności na odmowę usługi

Brak limitów zapytań i kontroli rozmiaru ładunków pozwala atakującym wyczerpywać zasoby serwera, co prowadzi do DoS, nadużyć i niehamowanych ataków na logowanie. Zalecane nastawy obejmują:

logowanie – ostre limity prób, opóźnienia, CAPTCHA po przekroczeniu progów;
upload – limity rozmiaru i typu plików, skanowanie AV, przetwarzanie asynchroniczne;
zapytania do DB – paginacja, limity zakresu, time‑outy i limity złożoności zapytań.

Błędy bezpieczeństwa, które testy penetracyjne aplikacji webowych ujawniają najczęściej