Testowanie bezpieczeństwa aplikacji: OWASP Top 10, SAST, DAST i SCA - Plan Szkolenia

A01:2025 – Niszczenie kontroli dostępu (Broken Access Control)

Kontrola dostępu wymusza polityki, dzięki którym użytkownicy nie mogą działać poza swoimi zamierzonymi uprawnieniami. Awaryfikacja tej kontroli zazwyczaj prowadzi do nieautoryzowanej ujawnienia informacji, modyfikacji lub zniszczenia danych, a także do wykonywania funkcji biznesowych poza limitami użytkownika.

Aspekty praktyczne

• Praktyczne przykłady naruszeń kontroli dostępu

• Bezpieczna kontrola dostępu i dobre praktyki

A02:2025 – Nieprawidłowe skonfigurowanie bezpieczeństwa (Security Misconfiguration)

Nieprawidłowe skonfigurowanie bezpieczeństwa polega na tym, że system, aplikacja lub usługa chmurowa jest skonfigurowana niepoprawnie z perspektywy bezpieczeństwa, co tworzy luki.

Aspekty praktyczne

• Przykłady z realnego świata dotyczące błędnej konfiguracji

• Kroki do zapobiegania błędnym konfiguracjom, w tym zarządzanie konfiguracją i narzędzia do automatyzacji

A03:2025 – Awaryfikacja łańcucha dostaw oprogramowania (Software Supply Chain Failures)

Awarefikacje łańcucha dostaw oprogramowania to zakłócenia lub inne kompromitacje w procesie budowania, dystrybuowania lub aktualizowania oprogramowania. Często są powodowane przez luki lub złośliwe zmiany w kodzie stron trzecich, narzędziach lub innych zależnościach, na których opiera się system.

A04:2025 – Awaryfikacja kryptograficzna (Cryptographic Failures)

Co do zasady, wszystkie dane w ruchu powinny być szyfrowane na warstwie transportowej (warstwa 4 modelu OSI). Poprzednie przeszkody, takie jak wydajność CPU oraz zarządzanie kluczami prywatnymi/certifikatami, są obecnie obsługiwane przez procesory posiadające instrukcje przyspieszające szyfrowanie (np. wsparcie AES) oraz przez uproszczenie zarządzania kluczami prywatnymi i certyfikatami dzięki usługom takim jak LetsEncrypt.org, a także przez dużych dostawców chmurowych oferujących ściśle zintegrowane usługi zarządzania certyfikatami dla swoich platform.

Ponadto zabezpieczeniu warstwy transportowej, ważne jest określenie, które dane wymagają szyfrowania w spoczynku, a które wymagają dodatkowego szyfrowania w ruchu (na warstwie aplikacyjnej, warstwa 7 modelu OSI).

Np. hasła, numery kart kredytowych, rekordy medyczne, informacje osobiste i tajemnice biznesowe wymagają dodatkowej ochrony, zwłaszcza jeśli dane te podlegają prawom o prywatności, np. Ogólnemu Rozporządzeniu o Ochronie Danych (RODO) w UE, lub regulacjom takim jak PCI Data Security Standard (PCI DSS).

Aspekty praktyczne

• Szczegółowa analiza awaryfikacji kryptograficznych, takich jak słabe algorytmy szyfrowania lub niewłaściwe zarządzanie kluczami

• Znaczenie silnych mechanizmów kryptograficznych, bezpiecznych protokołów (SSL/TLS) oraz przykłady nowoczesnej kryptografii w bezpieczeństwie webowym

A05:2025 – Iniekcja (Injection)

Luka iniekcji to wada systemu, która pozwala napastnikowi wstawić złośliwy kod lub polecenia (takie jak kod SQL lub shell) do pól wejściowych programu, wywołując do systemu do wykonania tego kodu lub poleceń, jakby były częścią systemu. Może to prowadzić do naprawdę poważnych konsekwencji.

Aspekty praktyczne

• Szczegółowy podział iniekcji SQL, NoSQL, OS i LDAP

• Techniki mitygacji za pomocą zapytań przygotowanych, zapytań parametryzowanych i ucieczek (escaping) z wejściem

A06:2025 – Niesiećny projekt (Insecure Design)

Niesiećny projekt to szeroka kategoria reprezentująca różne słabości, wyrażone jako „brak lub nieskuteczna kontrola projektu”.

Niesiećny projekt nie jest źródłem wszystkich innych kategorii ryzyka z listy Top Ten. Należy zauważyć, że istnieje różnica między niesiećnym projektem a niebezpieczną implementacją. Rozróżniamy wady projektu i wady implementacji, ponieważ mają one różne przyczyny, występują w różnych momentach procesu rozwoju i wymagają różnych napraw.

Bezpieczny projekt może wciąż zawierać wady implementacji prowadzące do luk, które mogą zostać wykorzystane. Niesiećny projekt nie może zostać naprawiony przez idealną implementację, ponieważ wymagane kontrole bezpieczeństwa nigdy nie zostały stworzone do obrony przed konkretnymi atakami.

Jednym z czynników przyczyniających się do niesiećnego projektu jest brak profilowania ryzyka biznesowego inherentnego w rozwijanym oprogramowaniu lub systemie, a tym samym nieustalenie, jakiego poziomu bezpieczeństwa projektu wymaga.

Aspekty praktyczne

• Zbadamy wady projektu, które mogą prowadzić do luk, takie jak niewłaściwa walidacja wejściu

• Zbadamy strategie bezpiecznej architektury i zasady bezpiecznego projektowania

A07:2025 – Awaryfikacja uwierzytelnienia (Authentication Failures)

Gdy napastnik jest w stanie oszukać system tak, aby uznał nieważnego lub błędnego użytkownika za legalnego, występuje ta luka.

Aspekty praktyczne

• Powszechne problemy z uwierzytelnianiem

• Strategie bezpiecznego uwierzytelniania, takie jak uwierzytelnianie wieloskładnikowe i prawidłowe obsługiwanie sesji

A08:2025 – Awaryfikacja integralności oprogramowania lub danych (Software or Data Integrity Failures)

Awarefikacje integralności oprogramowania i danych odnoszą się do kodu i infrastruktury, które nie chronią przed traktowaniem nieważnego lub niezaufanego kodu lub danych jako zaufanych i ważnych.

Przykładem tego jest sytuacja, w której aplikacja opiera się na wtyczkach, bibliotekach lub modułach pochodzących z niezaufanych źródeł, repozytoriów i sieci dystrybucji treści (CDN).

Niesiećny pipeline CI/CD bez konsumentów i dostawców kontroli integralności oprogramowania może wprowadzić potencjał nieautoryzowanego dostępu, niebezpiecznego lub złośliwego kodu lub kompromitacji systemu.

Innym przykładem jest CI/CD, który pobiera kod lub artefakty z niezaufanych miejsc i/lub nie weryfikuje ich przed użyciem (np. sprawdzając podpis lub podobny mechanizm).

Aspekty praktyczne

• Szukamy problemów, takich jak niezaufane aktualizacje oprogramowania i fałszowanie danych

• Bezpieczne mechanizmy aktualizacji i kontrole integralności danych

A09:2025 – Awaryfikacja logowania i alertów bezpieczeństwa (Security Logging and Alerting Failures)

Bez logowania i monitorowania ataki i naruszenia nie mogą zostać wykryte, a bez alertowania bardzo trudne jest szybkie i skuteczne reagowanie podczas incydentu bezpieczeństwa.

Niewystarczające logowanie, ciągłe monitorowanie, wykrywanie i alertowanie, aby rozpocząć aktywne reakcje, ma miejsce zawsze.

Aspekty praktyczne

• Znaczenie logowania informacji istotnych dla bezpieczeństwa i monitorowania podejrzanych aktywności

• Narzędzia i praktyki do właściwego logowania i monitorowania w czasie rzeczywistym, aby wykryć naruszenia we wczesnym stadium

A10:2025 – Niewłaściwe obsłużenie warunków wyjątkowych (Mishandling of Exceptional Conditions)

Niewłaściwe obsłużenie warunków wyjątkowych w oprogramowaniu ma miejsce, gdy programy nie zapobiegają, nie wykrywają i nie reagują na niezwykłe i nieprzewidywalne sytuacje, co prowadzi do awarii, nieoczekiwanego zachowania, a czasem do luk bezpieczeństwa.

Może to obejmować jeden lub więcej z następujących trzech braków:

• Aplikacja nie zapobiega występowaniu niezwykłej sytuacji

• Nie identyfikuje sytuacji, gdy się ona dzieje

• Reaguje źle lub wcale na sytuację po fakcie

SAST – Statyczne Testowanie Bezpieczeństwa Aplikacji

1. Czym jest analiza statystyczna i kiedy ją uruchamiać w SDLC (shift left)

2. Typy luk wykrywalnych przez SAST, niebezpieczny kod vs bezpieczny kod

3. Przegląd narzędzi SAST (np. Semgrep, SonarQube, Checkmarx, w zależności od stosu technologicznego klienta)

4. Ćwiczenie praktyczne: uruchomienie skanu SAST na repozytorium z celowo wprowadzonymi lukami, interpretacja wyników, kategoryzacja fałszywych alarmów vs rzeczywistych luk

DAST – Dynamiczne Testowanie Bezpieczeństwa Aplikacji

1. Różnica między SAST a DAST, testowanie czarnego pudła na działającej aplikacji

2. Przepływ skanu DAST, pełzanie (crawling), fuzzing, analiza odpowiedzi

3. Przegląd narzędzi DAST (np. OWASP ZAP, Burp Suite)

4. Ćwiczenie praktyczne: uruchomienie skanu DAST na podatnej aplikacji testowej (np. OWASP Juice Shop), identyfikacja i walidacja wyników

SCA – Analiza Składników Oprogramowania

1. Ryzyko zależności i bibliotek stron trzecich, dziedziczone luki

2. SBOM (Software Bill of Materials), czym jest i dlaczego jest ważny

3. Przegląd narzędzi SCA (np. Dependency Check, Snyk, GitHub Dependabot)

4. Ćwiczenie praktyczne: uruchomienie skanu SCA na realnym projekcie, identyfikacja podatnych zależności i stworzenie planu naprawczego (aktualizacja, łatka, mitygacja)