Laboratorium 3

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i integralności informacji. Bezpieczeństwo serwerów WWW.

Celem zadania jest zaprojektowanie, wdrożenie i przetestowanie zaawansowanej konfiguracji utwardzonego serwera WWW Nginx obsługującego krytyczny portal korporacyjny. Studenci poznają zasady eliminacji wycieków informacji o infrastrukturze (Server Token Hiding), bezpiecznego zarządzania buforami w celu zapobiegania atakom odmowy usługi (Slowloris / Buffer Overflow) oraz implementacji kompletu nowoczesnych nagłówków bezpieczeństwa HTTP. Projekt obejmuje konfigurację nagłówków: HSTS (HTTP Strict Transport Security) z preloadem, Content-Security-Policy (CSP Level 3), X-Frame-Options, X-Content-Type-Options, Referrer-Policy oraz Permissions-Policy.

W części analitycznej studenci badają podatności na ataki typu Clickjacking, MIME-Sniffing oraz wycieki danych wrażliwych w nagłówku Referer. W części praktycznej przeprowadzają audyt poprawności wdrożenia nagłówków za pomocą narzędzi cURL, testssl.sh oraz serwisu securityheaders.com, dążąc do uzyskania najwyższej oceny bezpieczeństwa A+.

Regionalny Portal Obsługi Klienta EnigmaEnergy S.A. obsługuje e-faktury, płatności online oraz zawieranie umów na dostawę energii elektrycznej dla ponad 200 000 odbiorców. Podczas rutynowego audytu zgodności z normą ISO/IEC 27001 wykazano, że serwer produkcyjny Nginx wysyłał pełne nagłówki wersji (Server: nginx/1.14.2 (Ubuntu)), co ułatwiało automatycznym botom dobór celowanych exploitów.

Ponadto aplikacja nie posiadała skonfigurowanego nagłówka HSTS, co umożliwiło audytorom przeprowadzenie demonstracyjnego ataku SSL Stripping w otwartej sieci Wi-Fi i zredukowanie połączenia klienta do nieszyfrowanego protokołu HTTP. Brak nagłówka X-Frame-Options pozwolił na osadzenie panelu logowania EnigmaEnergy wewnątrz niewidocznej ramki <iframe> na fałszywej stronie internetowej i przeprowadzenie ataku Clickjacking, w którym użytkownicy nieświadomie zatwierdzali zgodę na zmianę taryfy.

Zarząd spółki nakazał natychmiastowe utwardzenie konfiguracji serwerów brzegowych oraz zablokowanie wszelkich potencjalnych wektorów ataków po stronie przeglądarki klienta. Nowy standard musi uniemożliwić jakiekolwiek osadzanie portalu w ramkach, wymusić szyfrowanie HTTPS z preloadem na 2 lata oraz zablokować dostęp przeglądarki do kamery, mikrofonu i geolokalizacji za pośrednictwem nagłówka Permissions-Policy.

Grupa laboratoryjna przyjmuje zadanie administratorów bezpieczeństwa WWW. Studenci muszą przygotować produkcyjny plik konfiguracyjny Nginx, wyłączyć zbędne moduły, skonfigurować restrykcyjne nagłówki bezpieczeństwa oraz przetestować odporność serwera za pomocą zapytań cURL i zewnętrznych audytorów nagłówków.

Sprawozdanie musi zawierać dokładną analizę wpływu każdego nagłówka na zachowanie przeglądarki, zrzuty odpowiedzi HTTP przed i po utwardzeniu oraz potwierdzenie uzyskania ratingu A+ w audycie bezpieczeństwa nagłówków.

• Serwer WWW Nginx w środowisku Linux Debian / Ubuntu
• Narzędzie cURL do precyzyjnej inspekcji nagłówków HTTP odpowiedzi
• Przeglądarka internetowa z narzędziami deweloperskimi DevTools (Network / Headers)
• Analizator online securityheaders.com / darmowy skrypt shcheck.py
• Narzędzie OpenSSL do weryfikacji certyfikatu i nagłówków TLS

1. Zbadanie domyślnej konfiguracji serwera Nginx w pliku /etc/nginx/nginx.conf pod kątem wycieków wersji.
2. Wyłączenie rozgłaszania wersji serwera: dyrektywa server_tokens off; w bloku http.
3. Ograniczenie dopuszczalnych metod HTTP w konfiguracji lokalizacji: allow GET; allow POST; allow HEAD; deny all;.
4. Konfiguracja nagłówka HTTP Strict Transport Security: Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;.
5. Wdrożenie ochrony przed Clickjackingiem: add_header X-Frame-Options "DENY" always;.
6. Zablokowanie mechanizmu zgadywania typów MIME (MIME-Sniffing): add_header X-Content-Type-Options "nosniff" always;.
7. Konfiguracja polityki przekazywania nagłówka Referer: add_header Referrer-Policy "strict-origin-when-cross-origin" always;.
8. Konfiguracja nagłówka restrykcji interfejsów sprzętowych: add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;.
9. Zaprojektowanie polityki Content-Security-Policy (CSP) blokującej nieautoryzowane skrypty i osadzanie obiektów.
10. Ustawienie limitów buforów zapobiegających atakom odmowy usługi: client_body_buffer_size 128k, client_header_buffer_size 1k.
11. Wyłączenie obsługi starych metod HTTP (TRACE, TRACK, OPTIONS, DELETE) w konfiguracji vhosta.
12. Przetestowanie poprawności składni konfiguracji poleceniem nginx -t i przeładowanie usługi.
13. Wysłanie żądania cURL z opcją -I (head) w celu sprawdzenia obecności wszystkich nagłówków bezpieczeństwa.
14. Przeprowadzenie testu podatności na Clickjacking za pomocą lokalnego pliku test_frame.html zawierającego tag <iframe>.
15. Sprawdzenie raportu w serwisie securityheaders.com (weryfikacja oceny A+).
16. Zaprojektowanie centralnego pliku dołączanego security_headers.conf współdzielonego przez wszystkie wirtualne hosty.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z listingiem konfiguracji i zrzutami nagłówków.

Pamiętajcie, że w serwerze Nginx dodanie dyrektywy `add_header` w bloku podrzędnym (np. wewnątrz `location`) powoduje całkowite wyczyszczenie i nadpisanie wszystkich nagłówków `add_header` zdefiniowanych w blokach nadrzędnych (`server` lub `http`). Aby tego uniknąć, najlepszą praktyką inżynierską jest stworzenie osobnego pliku (np. `/etc/nginx/snippets/security-headers.conf`) i dołączanie go dyrektywą `include` we wszystkich wymaganych lokalizacjach.

Poniżej przedstawiono kompletny, produkcyjny plik nagłówków bezpieczeństwa dla serwera Nginx oraz weryfikację za pomocą cURL:

Weryfikacja odpowiedzi serwera za pomocą polecenia cURL z poziomu konsoli audytora:

Próba osadzenia serwera w ramce <iframe> na obcej stronie kończy się zablokowaniem w przeglądarce:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza podatności serwerów WWW na ataki typu MIME-sniffing, clickjacking oraz cross-site scripting (XSS) wynikające z braku restrykcyjnych nagłówków HTTP.
2. Konfiguracja polityki Content Security Policy (CSP) poziomu 3 w oparciu o kryptograficzne wartości jednorazowe (nonce) i mechanizm strict-dynamic.
3. Rola nagłówka HTTP Strict Transport Security (HSTS) z parametrami max-age=63072000; includeSubDomains; preload w eliminacji ataków typu SSL Stripping.
4. Wyłączenie ujawniania sygnatury oprogramowania (server_tokens off) oraz restrykcje nagłówka Permissions-Policy dla sensorów sprzętowych.
5. Ochrona interfejsu przed osadzaniem w ramkach obcych domen za pomocą nagłówka X-Frame-Options: DENY oraz dyrektywy CSP frame-ancestors.
6. Metodyka weryfikacji i ciągłego audytu poziomu utwardzenia serwera z wykorzystaniem skanerów SecurityHeaders oraz Mozilla Observatory.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie kompleksowego zestawu nagłówków bezpieczeństwa w konfiguracji serwera Nginx pozwoliło na podniesienie oceny w audycie Mozilla Observatory ze skrajnie niebezpiecznego poziomu F do maksymalnej noty A+. Zastosowanie polityki Content Security Policy opartej na kryptograficznych tokenach jednorazowych skutecznie zablokowało wykonywanie wstrzykiwanych skryptów XSS bez zakłócania działania zaufanych bibliotek aplikacji. Wprowadzenie dyrektywy HSTS z okresem ważności dwóch lat oraz flagami includeSubDomains i preload trwale zabezpieczyło użytkowników przed atakami obniżenia wersji protokołu. Wyłączenie ujawniania wersji serwera oraz zablokowanie osadzania strony w obcych ramkach za pomocą dyrektywy frame-ancestors wyeliminowało ryzyko precyzyjnego profilowania podatności i ataków Clickjacking. Wdrożona konfiguracja stanowi wzorcową realizację zaleceń OWASP Secure Headers Project i spełnia wymogi bezpieczeństwa transmisji danych określone w normie ISO/IEC 27001.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia integralności i poufności informacji. Zapory aplikacji internetowych (WAF).

Celem zadania jest zaprojektowanie, instalacja, konfiguracja i dokładne dostrojenie (Tuning) zapory aplikacji internetowych (Web Application Firewall - WAF) ModSecurity v3 z oficjalnym zestawem reguł OWASP Core Rule Set (CRS v3.3/v4.0). Studenci badają zasady inspekcji ruchu HTTP w modelu odwrotnego proxy (Reverse Proxy WAF), analizując działanie reguł wykrywających ataki SQL Injection, Cross-Site Scripting (XSS), Local/Remote File Inclusion (LFI/RFI), zdalne wykonywanie kodu (RCE) oraz skanery podatności.

Kluczowym elementem ćwiczenia jest rozwiązanie powszechnego problemu fałszywych alarmów (False Positives), które w środowiskach produkcyjnych mogą blokować legalnych użytkowników. Studenci uczą się analizować dzienniki audytowe (ModSecurity Audit Log), modyfikować progi anomalii (Anomaly Scoring Mode) oraz tworzyć precyzyjne reguły wykluczające (Rule Exclusions) dla specyficznych endpointów aplikacji.

Platforma przetargowa ZamowieniaPubliczne24 Sp. z o.o. obsługuje elektroniczne składanie ofert handlowych dla urzędów miast i gmin. W ostatnim kwartale portal stał się celem zmasowanych ataków przeprowadzanych przez botnety, obejmujących próby wstrzykiwania zapytań SQL, przesyłanie powłok webowych (Web Shell) oraz skanowanie w poszukiwaniu luk w oprogramowaniu WordPress i modułach PHP.

Zarząd spółki podjął decyzję o zainstalowaniu zapory WAF ModSecurity przed klastrem serwerów aplikacji. Jednakże bezpośrednio po włączeniu domyślnej konfiguracji OWASP CRS w trybie blokowania doszło do paraliżu systemu: WAF zaczął masowo odrzucać legalne oferty przetargowe przesyłane w formacie XML/JSON, błędnie klasyfikując fragmenty opisów technicznych jako próby ataków XSS lub LFI (fałszywe alarmy).

Dyrektor IT wstrzymał działanie WAF i nakazał przeprowadzenie profesjonalnego procesu strojenia w trybie monitorowania (DetectionOnly), zidentyfikowanie przyczyn fałszywych alarmów oraz napisanie reguł wykluczeń przed ponownym przełączeniem w tryb aktywnego blokowania (On).

Grupa laboratoryjna przyjmuje rolę inżynierów bezpieczeństwa aplikacji. Zadaniem zespołu jest wdrożenie silnika ModSecurity zintegrowanego z serwerem Nginx/Apache, załadowanie zestawu reguł OWASP CRS, skonfigurowanie progów punktacji anomalii (Inbound Anomaly Score Threshold), zasymulowanie realnych ataków oraz legalnego ruchu generującego błędy, a następnie stworzenie precyzyjnych reguł wykluczeń eliminujących fałszywe alarmy.

Sprawozdanie musi zawierać konfigurację wstępną, analizę wpisów z dziennika audytowego modsec_audit.log, reguły wykluczające oraz dowody skutecznego blokowania ataków z jednoczesnym przepuszczaniem legalnego ruchu biznesowego.

• Linux z serwerem Nginx lub Apache2 i modułem libmodsecurity3 / mod_security2
• Oficjalny zestaw reguł OWASP ModSecurity Core Rule Set (CRS) v3.3 lub v4.0
• Narzędzie Nikto / sqlmap do generowania kontrolowanego ruchu atakującego
• Narzędzie cURL do precyzyjnego generowania zapytań testowych
• Skrypt modsec-audit-log-collector / jq do parsowania dzienników w formacie JSON

1. Kompilacja lub instalacja modułu ModSecurity w środowisku serwera Nginx/Apache.
2. Pobranie i weryfikacja integralności oficjalnego archiwum OWASP Core Rule Set (CRS).
3. Skonfigurowanie pliku modsecurity.conf: ustawienie SecRuleEngine DetectionOnly na czas wstępnego strojenia.
4. Włączenie szczegółowego logowania audytowego: SecAuditLogParts ABIJDEFHZ, SecAuditLogFormat JSON.
5. Załadowanie reguł bazowych OWASP CRS: REQUEST-901-INITIALIZATION do REQUEST-949-BLOCKING-EVALUATION.
6. Zbadanie modelu punktacji anomalii (Anomaly Scoring Mode) i zdefiniowanie progów: critical=5, error=4, warning=3, notice=2.
7. Przeprowadzenie serii testowych ataków za pomocą cURL: wstrzyknięcie SQLi (' OR 1=1--), XSS (<script>) oraz path traversal (../../etc/passwd).
8. Analiza dziennika modsec_audit.log: odczytanie identyfikatorów reguł (Rule ID), które zarejestrowały naruszenie.
9. Symulacja legalnego ruchu biznesowego generującego fałszywy alarm (np. pole opisu zamówienia zawierające słowa 'select' lub 'union').
10. Identyfikacja reguły wywołującej fałszywy alarm (np. Rule ID 942100 w pliku REQUEST-942-APPLICATION-ATTACK-SQLI.conf).
11. Zaprojektowanie bezpiecznej reguły wykluczenia (Rule Exclusion) zawężonej wyłącznie do konkretnego parametru i ścieżki URL: SecRuleUpdateTargetById 942100 !ARGS:opis_oferty.
12. Zastosowanie wykluczenia w pliku REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.
13. Przetestowanie poprawności: potwierdzenie, że legalne zapytanie przechodzi bez punktów anomalii, a atak na inne parametry jest nadal wykrywany.
14. Przełączenie silnika ModSecurity w tryb aktywnej ochrony: SecRuleEngine On.
15. Weryfikacja odpowiedzi serwera dla prawdziwego ataku (kod HTTP 403 Forbidden).
16. Zaprojektowanie monitorowania liczby odrzuconych zapytań w czasie rzeczywistym.
17. Podsumowanie wdrożenia w sprawozdaniu z listingami reguł strojeniowych i wycinkami logów.

Nigdy nie wyłączaj całej reguły CRS (np. `SecRuleRemoveById 942100`), jeśli powoduje ona fałszywy alarm w jednym formularzu. Wyłączenie całej reguły otwiera lukę w bezpieczeństwie w całej aplikacji. Prawidłową techniką jest wykluczenie sprawdzania konkretnego parametru (np. `SecRuleUpdateTargetById 942100 "!ARGS:tresc_ogloszenia"`), co zachowuje pełną ochronę pozostałych parametrów.

Poniżej przedstawiono przykładową konfigurację wykluczeń reguł w ModSecurity eliminującą fałszywe alarmy dla panelu ofert:

Inspekcja wpisu w dzienniku audytowym ModSecurity w formacie JSON dokumentującego zablokowanie prawdziwego ataku RCE:

Weryfikacja działania WAF po przełączeniu w tryb blokowania za pomocą polecenia cURL:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Architektura działania zapory aplikacji webowych (WAF) w trybie odwrotnego proxy i silnika reguł ModSecurity v3 z OWASP Core Rule Set (CRS).
2. Metodyka detekcji ataków w oparciu o model punktacji anomalii (Anomaly Scoring Model) w porównaniu do modelu tradycyjnego blokowania reaktywnego.
3. Procedura strojenia WAF (Tuning i False Positive Elimination) w celu dostosowania reguł do specyfiki legalnych żądań aplikacji webowej.
4. Skuteczność neutralizacji wektorów ataków z OWASP Top 10, w szczególności SQL Injection, Remote Code Execution oraz Path Traversal.
5. Wpływ głębokiej inspekcji pakietów HTTP/HTTPS na opóźnienia sieciowe (Latency Overhead) i narzut na moc obliczeniową serwera proxy.
6. Zgodność z wymogiem 6.4 standardu PCI DSS v4.0 nakazującym ciągłe monitorowanie i aktywną ochronę aplikacji internetowych przetwarzających dane kartowe.

Przykładowe wnioski (wzór do sprawozdania): Integracja silnika ModSecurity v3 z oficjalnym zestawem reguł OWASP Core Rule Set zapewniła skuteczną ochronę warstwy aplikacyjnej przed zautomatyzowanymi wektorami ataków z listy OWASP Top 10. Przeprowadzone testy penetracyjne wykazały, że model oceny anomalii natychmiast blokuje zaawansowane ładunki SQL Injection i próby trawersowania ścieżek z kodem błędu HTTP 403 Forbidden. Kluczowym etapem wdrożenia okazało się wykluczenie reguł powodujących fałszywe alarmy w formularzach edycji bogatego tekstu CMS, co osiągnięto za pomocą precyzyjnych dyrektyw SecRuleRemoveById. Pomiar narzutu wydajnościowego wykazał wzrost opóźnienia odpowiedzi średnio o zaledwie 3,8 ms, co stanowi w pełni akceptowalny koszt w zamian za uzyskaną warstwę obrony w głąb. Wdrożenie zapory WAF pozwoliło organizacji na spełnienie krytycznego wymogu 6.4.1 standardu bezpieczeństwa płatności kartowych PCI DSS v4.0.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. Protokół TLS i kryptografia asymetryczna.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie zaawansowanej, bezpiecznej konfiguracji warstwy kryptograficznej TLS (Transport Layer Security) w serwerze Apache HTTP Server, spełniającej współczesne wytyczne NIST SP 800-52 Rev. 2 oraz profil Mozilla Modern TLS. Studenci analizują architekturę protokołu TLS 1.3 w zestawieniu z TLS 1.2, poznając zalety eliminacji przestarzałych mechanizmów (usunięcie podatnych szyfrów blokowych CBC, wymiany kluczy RSA bez utajniania w przód, negocjacji kompresji podatnej na ataki CRIME).

Projekt obejmuje wdrożenie kryptografii opartej na krzywych eliptycznych (ECDHE z krzywymi X25519 i secp256r1), konfigurację certyfikatów z podpisami ECDSA/RSA, włączenie mechanizmu OCSP Stapling (zszywanie odpowiedzi statusu unieważnienia certyfikatu) oraz eliminację ataków typu Downgrade Attack. Zwieńczeniem zadania jest audyt serwera za pomocą narzędzi testssl.sh oraz uzyskanie najwyższego ratingu A+ w teście Qualys SSL Labs.

Dom Maklerski Bessa & Hossa S.A. obsługuje internetową platformę transakcyjną do handlu akcjami i obligacjami na Giełdzie Papierów Wartościowych. Klienci logują się za pośrednictwem przeglądarek internetowych i aplikacji webowej Apache. Podczas audytu technicznego zleconego przez Komisję Nadzoru Finansowego (KNF) stwierdzono, że serwery transakcyjne nadal dopuszczały negocjację przestarzałych protokołów TLS 1.0 i TLS 1.1 oraz akceptowały zestawy szyfrów z algorytmem 3DES i trybem CBC, podatne na ataki kryptoanalityczne BEAST oraz Sweet32.

Ponadto weryfikacja unieważnienia certyfikatów opierała się na klasycznym odpytywaniu serwerów OCSP przez przeglądarkę klienta, co powodowało opóźnienia w nawiązywaniu połączeń oraz naruszało prywatność użytkowników (ujawnianie adresu IP klienta operatorowi urzędu certyfikacji CA). Serwer nie korzystał z mechanizmu Perfect Forward Secrecy dla części połączeń, co stwarzało ryzyko odszyfrowania historycznego ruchu w przypadku przyszłego wycieku klucza prywatnego.

KNF wyznaczyła 14-dniowy termin na wyeliminowanie podatności kryptograficznych pod rygorem nałożenia kary administracyjnej i wstrzymania działalności maklerskiej. Zarząd spółki polecił administratorom natychmiastowe przejście na standard TLS 1.3 i TLS 1.2 z wyłącznym wsparciem dla bezpiecznych szyfrów AEAD.

Zespół studentów ma za zadanie zrekonfigurować moduł mod_ssl w serwerze Apache, wyłączyć wszystkie protokoły poniżej TLS 1.2, skonfigurować preferencję szyfrów ECDHE-ECDSA/RSA z algorytmami AES-GCM i ChaCha20-Poly1305, uruchomić lokalne buforowanie i zszywanie odpowiedzi OCSP (OCSP Stapling) oraz przetestować konfigurację narzędziem testssl.sh.

Sprawozdanie musi zawierać pełne listingi konfiguracji ssl.conf, analizę matematyczną wybranych krzywych eliptycznych oraz zrzut z audytu testssl.sh wykazujący brak jakichkolwiek podatności na znane ataki kryptograficzne (Heartbleed, POODLE, DROWN, ROBOT, Logjam).

• Serwer Apache HTTP Server 2.4.x z aktywnym modułem mod_ssl i mod_socache_shmcb
• OpenSSL 1.1.1 lub 3.x z obsługą TLS 1.3 i krzywych Curve25519
• Narzędzie audytorskie testssl.sh (darmowy skaner konfiguracji TLS)
• Przeglądarka internetowa z narzędziem Security Panel w DevTools
• Lokalny urząd certyfikacji lub darmowy certyfikat Let's Encrypt / self-signed z rozszerzeniem OCSP

1. Zbadanie dotychczasowej konfiguracji modułu mod_ssl w pliku /etc/apache2/mods-enabled/ssl.conf.
2. Wyłączenie przestarzałych protokołów SSLv3, TLS 1.0 oraz TLS 1.1: SSLProtocol -all +TLSv1.2 +TLSv1.3.
3. Zdefiniowanie bezpiecznych zestawów szyfrów dla TLS 1.2 (ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305).
4. Konfiguracja zestawów szyfrów TLS 1.3: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256.
5. Włączenie wymuszania kolejności szyfrów serwera: SSLHonorCipherOrder on.
6. Konfiguracja parametrów wymiany kluczy na krzywych eliptycznych: SSLOpenSSLConfCmd Curves X25519:secp256r1:secp384r1.
7. Wdrożenie własności Perfect Forward Secrecy (PFS) wykluczającej ataki z deszyfrowaniem wstecznym.
8. Włączenie bufora pamięci podręcznej sesji TLS: SSLSessionCache shmcb:/run/apache2/ssl_scache(512000).
9. Wyłączenie biletów sesyjnych TLS (Session Tickets) lub wdrożenie ich częstej rotacji w celu ochrony PFS.
10. Konfiguracja mechanizmu OCSP Stapling: SSLUseStapling on, SSLStaplingCache shmcb:/run/apache2/ocsp_cache(128000).
11. Ustawienie timeoutów i weryfikacji odpowiedzi OCSP: SSLStaplingResponderTimeout 5, SSLStaplingReturnUntrusted off.
12. Wyłączenie kompresji TLS w celu ochrony przed atakami CRIME: SSLCompression off.
13. Przetestowanie poprawności konfiguracji poleceniem apache2ctl configtest i restart usługi.
14. Weryfikacja obsługi TLS 1.3 za pomocą polecenia openssl s_client -connect target:443 -tls1_3.
15. Uruchomienie pełnego audytu bezpieczeństwa za pomocą narzędzia testssl.sh --fast target.local.
16. Weryfikacja obecności zszytej odpowiedzi OCSP (OCSP Response Status: successful).
17. Skompilowanie raportu laboratoryjnego z podsumowaniem wyników audytu kryptograficznego.

W protokole TLS 1.3 architektura negocjacji szyfrów uległa fundamentalnej zmianie. Zestawy szyfrów (Cipher Suites) w TLS 1.3 definiują wyłącznie algorytm szyfrowania symetrycznego (np. AES-256-GCM) oraz funkcję skrótu dla HKDF (np. SHA384). Algorytm wymiany klucza nie jest już częścią nazwy szyfru, ponieważ TLS 1.3 dopuszcza wyłącznie bezpieczną wymianę kluczy opartą na efemerycznym protokole Diffie-Hellmana (DHE / ECDHE), co gwarantuje Perfect Forward Secrecy z definicji.

Poniżej przedstawiono przykładową, utwardzoną konfigurację Apache HTTP Server (mod_ssl) zgodną ze standardem Mozilla Modern:

Weryfikacja nawiązania bezpiecznej sesji TLS 1.3 za pomocą konsoli OpenSSL s_client:

Weryfikacja obecności zszytej odpowiedzi OCSP (OCSP Staple) chroniącej prywatność użytkowników:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Różnice architektoniczne i kryptograficzne pomiędzy protokołami TLS 1.2 i TLS 1.3, w tym usunięcie podatnych szyfrów i skrócenie handshake do 1-RTT.
2. Implementacja kryptografii na krzywych eliptycznych (klucze ECDSA z krzywą secp384r1 oraz wymiana kluczy X25519) w serwerze Apache HTTP Server.
3. Eliminacja podatności na ataki kryptograficzne (SWEET32, POODLE, BEAST) poprzez całkowite wycofanie protokołów SSLv3/TLS 1.0/TLS 1.1 oraz szyfrów CBC i RC4.
4. Konfiguracja mechanizmu OCSP Stapling (RFC 6066) w celu przyspieszenia nawiązywania połączenia i ochrony prywatności klientów przed serwerami urzędu certyfikacji.
5. Zapewnienie właściwości doskonałego utajniania w przód (Perfect Forward Secrecy – PFS) z wykorzystaniem algorytmu ECDHE.
6. Metodyka weryfikacji konfiguracji kryptograficznej za pomocą narzędzia testssl.sh oraz audytu SSL Labs z celem uzyskania oceny A+.

Przykładowe wnioski (wzór do sprawozdania): Restrykcyjna rekonfiguracja modułu SSL serwera Apache pozwoliła na wyeliminowanie przestarzałych protokołów TLS 1.0/1.1 i szyfrów podatnych na ataki kryptoanalityczne, osiągając maksymalną ocenę A+ w audycie Qualys SSL Labs. Ograniczenie dopuszczalnych zestawów szyfrów do nowoczesnych algorytmów TLS 1.3 zagwarantowało bezwzględne zachowanie właściwości doskonałego utajniania w przód (Perfect Forward Secrecy). Zastosowanie certyfikatów z kluczami na krzywych eliptycznych (ECDSA secp384r1) znacząco zredukowało obciążenie procesora podczas negocjacji połączenia w porównaniu z tradycyjnymi kluczami RSA. Wdrożenie technologii OCSP Stapling wyeliminowało opóźnienia związane z zewnętrznymi zapytaniami klientów do serwerów CA oraz usunęło ryzyko ujawnienia historii przeglądania użytkowników dostawcom certyfikatów. Zoptymalizowany handshake 1-RTT przyniósł wymierny zysk wydajnościowy, podnosząc komfort korzystania z portalu bankowego przy zachowaniu najwyższych rygorów bezpieczeństwa.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Zarządzanie stanem i sesją w protokole HTTP.

Celem zadania jest zbadanie mechanizmów kontroli stanu i zarządzania sesją w bezstanowym protokole HTTP oraz zaprojektowanie rygorystycznej polityki bezpieczeństwa sesji dla bankowej aplikacji internetowej. Studenci poznają anatomię ataków na sesję użytkownika: fiksacji sesji (Session Fixation), przejęcia aktywnego tokena sesyjnego (Session Hijacking), fałszowania żądań międzywitrynowych (CSRF) oraz podsłuchu w nieszyfrowanym kanale. Projekt analizuje krytyczne znaczenie atrybutów ciasteczek: HttpOnly, Secure oraz SameSite (None, Lax, Strict).

W części programistyczno-konfiguracyjnej studenci implementują mechanizm natychmiastowej rotacji identyfikatora sesji (Session ID Regeneration) po pomyślnym uwierzytelnieniu, bezwzględne unieważnianie sesji po wylogowaniu po stronie serwera, mechanizm automatycznego wygaszania bezczynnej sesji (Idle Timeout = 15 minut) oraz maksymalnego czasu życia sesji (Absolute Timeout). Zadanie uczy również wiązania sesji z fingerprintem klienta.

Spółdzielcza Kasa Oszczędnościowo-Kredytowa 'Skarbiec' uruchomiła nową wersję serwisu bankowości elektronicznej dla klientów indywidualnych. Aplikacja została zaimplementowana w technologii PHP z domyślnym mechanizmem obsługi sesji PHPSESSID. Podczas audytu bezpieczeństwa przeprowadzonego przez zespół Ethical Hackerów zidentyfikowano szereg krytycznych błędów w architekturze sesyjnej.

Po pierwsze, aplikacja akceptowała identyfikator sesji przekazany bezpośrednio w parametrze adresu URL (np. https://bank.skarbiec.pl/logowanie?PHPSESSID=123456). Pozwalało to napastnikowi na wysłanie ofierze spreparowanego linku, a po zalogowaniu się ofiary identyfikator sesji nie ulegał zmianie (Session Fixation). Napastnik, znając z góry ustalony identyfikator, uzyskiwał natychmiastowy dostęp do rachunku bankowego ofiary.

Po drugie, ciasteczko sesyjne nie posiadało atrybutu HttpOnly ani SameSite, co w połączeniu z drobną luką XSS umożliwiało kradzież poświadczeń. Po trzecie, kliknięcie przycisku 'Wyloguj' powodowało jedynie usunięcie ciasteczka w przeglądarce klienta, podczas gdy po stronie serwera plik sesji pozostawał w pełni aktywny i ważny przez kolejne 24 godziny.

Zarząd SKOK podjął decyzję o natychmiastowym wstrzymaniu dostępu do nowego systemu do czasu usunięcia wszystkich wad projektowych. Zlecono zespołowi audytorów (grupie laboratoryjnej) opracowanie nowej, pancernej procedury zarządzania sesjami.

Studenci muszą odtworzyć podatność fiksacji sesji w środowisku laboratoryjnym, zaimplementować bezpieczną konfigurację php.ini / serwera aplikacyjnego, wdrożyć funkcję session_regenerate_id(true) przy każdej zmianie kontekstu uprawnień, skonfigurować ciasteczka z prefiksem __Host- oraz zaprojektować procedurę czyszczenia sesji w pamięci Redis/bazy danych po wylogowaniu.

• Środowisko PHP 8.x / Python Flask / Node.js z obsługą sesji
• Burp Suite Community Edition do manipulacji ciasteczkami sesyjnymi
• Przeglądarka internetowa z narzędziami deweloperskimi DevTools (Storage -> Cookies)
• Narzędzie cURL do badania nagłówka Set-Cookie
• Baza danych Redis / memcached do bezpiecznego przechowywania danych sesji

1. Analiza domyślnych parametrów obsługi sesji w pliku konfiguracyjnym /etc/php/8.x/apache2/php.ini.
2. Wymuszenie korzystania wyłącznie z ciasteczek do przekazywania identyfikatora: session.use_only_cookies = 1 oraz session.use_trans_sid = 0.
3. Włączenie automatycznego generowania bezpiecznych, losowych identyfikatorów sesji o wysokiej entropii: session.sid_length = 48, session.sid_bits_per_character = 6.
4. Konfiguracja atrybutów ciasteczka sesyjnego: session.cookie_httponly = 1 (ochrona przed odczytem z JavaScript/XSS).
5. Wymuszenie przesyłania ciasteczka wyłącznie przez szyfrowany kanał HTTPS: session.cookie_secure = 1.
6. Konfiguracja restrykcyjnego atrybutu izolacji międzywitrynowej: session.cookie_samesite = Strict (ochrona przed CSRF).
7. Zastosowanie bezpiecznego prefiksu nazwy ciasteczka: __Host-SessionId (gwarancja bezpiecznego pochodzenia i braku poddomen).
8. Zaimplementowanie funkcji session_regenerate_id(true) w kodzie logowania, usuwającej stary identyfikator sesji i tworzącej nowy.
9. Zaprojektowanie mechanizmu Idle Session Timeout: automatyczne unieważnienie sesji po 15 minutach braku aktywności użytkownika.
10. Zaimplementowanie Absolute Session Timeout: bezwzględne zakończenie sesji po 4 godzinach od momentu zalogowania niezależnie od aktywności.
11. Opracowanie bezpiecznej procedury wylogowania niszczącej dane sesji po stronie serwera (session_destroy() i unieważnienie tokena w Redis).
12. Zademonstrowanie nieskuteczności ataku Session Fixation w zabezpieczonym środowisku.
13. Weryfikacja nagłówka Set-Cookie w odpowiedzi HTTP za pomocą polecenia cURL.
14. Zbadanie odporności aplikacji na ataki brute-force na identyfikatory sesji (analiza przestrzeni 2^288 możliwych kombinacji).
15. Zaprojektowanie mechanizmu powiązania sesji (Session Binding) z adresem IP i nagłówkiem User-Agent w celu wykrywania anomalii.
16. Opracowanie procedury bezpiecznego powiadamiania użytkownika o logowaniu z nowego urządzenia/adresu IP.
17. Sformułowanie wniosków i sporządzenie sprawozdania laboratoryjnego z kodem bezpiecznego modułu sesji.

Stosowanie prefiksu `__Host-` w nazwie ciasteczka (np. `__Host-SID`) jest nowoczesnym mechanizmem obronnym wspieranym przez wszystkie współczesne przeglądarki. Ciasteczko z tym prefiksem zostanie zaakceptowane przez przeglądarkę wyłącznie wtedy, gdy: 1) pochodzi z bezpiecznego połączenia HTTPS, 2) posiada atrybut `Secure`, 3) nie zawiera atrybutu `Domain` (jest przypisane ściśle do bieżącego hosta, co chroni przed atakami z poziomu podatnych poddomen), oraz 4) posiada ścieżkę `Path=/`.

Poniżej przedstawiono przykładową implementację bezpiecznej inicjalizacji i rotacji sesji w języku PHP:

Weryfikacja nagłówka Set-Cookie zwróconego po zalogowaniu za pomocą polecenia cURL:

Próba odczytania ciasteczka sesyjnego przez złośliwy skrypt JavaScript kończy się fiaskiem:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Mechanizmy ataku przejęcia sesji (Session Hijacking) oraz utrwalenia sesji (Session Fixation) w dynamicznych aplikacjach internetowych.
2. Rola i restrykcyjne wymuszanie atrybutów ciasteczek sesyjnych: HttpOnly (ochrona przed XSS), Secure (tylko TLS) oraz SameSite=Strict (ochrona przed CSRF).
3. Implementacja procedury bezpiecznej rotacji identyfikatora sesji w momencie uwierzytelnienia użytkownika oraz zmiany uprawnień w systemie.
4. Zastosowanie prefiksów ciasteczek bezpieczeństwa (__Host- oraz __Secure-) w celu uniemożliwienia nadpisywania ciasteczek przez subdomeny.
5. Konfiguracja bezwzględnych i relatywnych limitów czasu życia sesji (Absolute Timeout vs Idle Inactivity Timeout) oraz unieważniania danych sesyjnych po stronie serwera.
6. Odporność mechanizmu sesyjnego na ataki typu Man-in-the-Middle i wyciek tokenów zgodnie z wytycznymi OWASP Session Management Cheat Sheet.

Przykładowe wnioski (wzór do sprawozdania): Eksperymentalne badanie podatności mechanizmu sesyjnego wykazało, że brak regeneracji tokena po poprawnym logowaniu umożliwia bezproblemowe przejęcie tożsamości użytkownika za pomocą techniki Session Fixation. Zaimplementowanie natychmiastowej rotacji identyfikatora sesji wraz z unieważnieniem poprzedniego deskryptora całkowicie zneutralizowało ten groźny wektor zagrożenia. Opatrzenie ciasteczka sesyjnego atrybutami HttpOnly, Secure oraz SameSite=Strict wyeliminowało możliwość kradzieży tokena przez złośliwe skrypty JavaScript i zapobiegło jego dołączaniu do żądań międzywitrynowych. Dodatkowe zastosowanie prefiksu __Host-SessionID zabezpieczyło aplikację przed atakami polegającymi na wstrzykiwaniu spreparowanych ciasteczek ze słabiej zabezpieczonych subdomen organizacji. Wdrożenie sztywnego limitu bezczynności na poziomie 15 minut oraz maksymalnego czasu trwania sesji równego 8 godzin spełniło rygorystyczne wymagania KNF dla bankowości elektronicznej.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Ochrona przed atakami słownikowymi.

Celem zadania jest zaprojektowanie, przetestowanie i wdrożenie wielopoziomowej architektury ochrony interfejsów uwierzytelniania aplikacji webowej przed zautomatyzowanymi atakami siłowymi (Brute-Force), atakami słownikowymi oraz atakami wykorzystującymi wycieki baz danych (Credential Stuffing). Studenci analizują wektory ataków rozproszonych przeprowadzanych przez botnety rotujące adresy IP, badają wpływ ataków na obciążenie procesora i bazy danych oraz poznają metody odróżniania pomyłek legalnych użytkowników od aktywności złośliwych skryptów.

W części technicznej zadanie obejmuje konfigurację limitowania przepustowości żądań HTTP na poziomie serwera WWW Nginx (moduł ngx_http_limit_req_module z algorytmem Leaky Bucket), wdrożenie mechanizmu dynamicznego blokowania adresów IP na poziomie zapory jądra za pomocą demona Fail2ban, analizę kodów odpowiedzi HTTP (429 Too Many Requests) oraz implementację opóźnień progresywnych (Tarpitting / Exponential Backoff).

Portal pracowniczy i platforma e-learningowa Uczelni Medycznej MedEdu gromadzi konta ponad 15 000 studentów, wykładowców i pracowników administracji. Panel logowania (/auth/login) stał się celem zmasowanego ataku typu Credential Stuffing: przestępcy weszli w posiadanie bazy milionów haseł z ostatnich wycieków publicznych i uruchomili wielowątkowe boty sprawdzające, którzy użytkownicy MedEdu użyli takiego samego hasła w uczelnianym systemie.

Serwer Nginx oraz baza danych PostgreSQL zostały przeciążone setkami równoległych zapytań POST na sekundę, co doprowadziło do paraliżu platformy w trakcie trwania sesji egzaminacyjnej. Ponieważ serwer nie posiadał żadnych limitów częstotliwości zapytań ani mechanizmów blokady adresów IP, napastnicy zdołali przejąć dostęp do 87 kont studenckich i wykładowczych.

Rektor uczelni powołał zespół kryzysowy w celu natychmiastowego zabezpieczenia panelu logowania przed jakimikolwiek zautomatyzowanymi atakami masowymi, bez utrudniania pracy legalnym użytkownikom.

Zadaniem grupy laboratoryjnej jest wdrożenie dwuetapowej tarczy obronnej: 1) Warstwa serwera WWW: konfiguracja strefy limit_req_zone w Nginx ograniczającej liczbę zapytań do endpointu logowania do maksymalnie 5 na minutę z dopuszczalnym krótkim buforem (burst), 2) Warstwa systemowa: wdrożenie narzędzia Fail2ban analizującego dziennik access.log serwera Nginx i automatycznie wprowadzającego reguły blokujące na zaporze iptables/nftables po wykryciu 5 nieudanych prób logowania w ciągu 10 minut.

Sprawozdanie musi zawierać konfigurację Nginx i filtrów Fail2ban, symulację ataku za pomocą narzędzia Hydra / skryptu w Pythonie przed i po wdrożeniu zabezpieczeń oraz dowody automatycznego nakładania blokad IP.

• Serwer Nginx z wbudowanym modułem ngx_http_limit_req_module
• Narzędzie Fail2ban zintegrowane z iptables / nftables w systemie Linux
• Narzędzie hydra / medusa / ffuf do generowania ataków brute-force na formularz HTTP POST
• Skrypt Python (moduł requests) do symulacji rozproszonych zapytań logowania
• Narzędzie fail2ban-client do inspekcji stanu więzień (jail status)

1. Zbadanie podatności formularza logowania aplikacji na wielowątkowe zapytania za pomocą narzędzia Hydra.
2. Skonfigurowanie strefy pamięci współdzielonej dla limitowania żądań w Nginx: limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;.
3. Przypisanie limitu do lokalizacji logowania w bloku vhosta: limit_req zone=login_limit burst=3 nodelay;.
4. Zdefiniowanie kodu odpowiedzi serwera przy przekroczeniu limitu: limit_req_status 429;.
5. Przetestowanie działania limitowania Nginx za pomocą szybkiego skryptu w Pythonie i zaobserwowanie odpowiedzi HTTP 429 Too Many Requests.
6. Instalacja pakietu fail2ban w środowisku Linux.
7. Utworzenie dedykowanego filtru regex w pliku /etc/fail2ban/filter.d/nginx-login.conf dopasowującego nieudane próby logowania (kody HTTP 401 Unauthorized / HTTP 200 z komunikatem błędu).
8. Konfiguracja więzienia (jail) w pliku /etc/fail2ban/jail.d/nginx-login.local.
9. Zdefiniowanie parametrów ochrony: maxretry = 5, findtime = 600 (10 minut), bantime = 3600 (1 godzina blokady).
10. Skonfigurowanie akcji blokującej: automatyczne dodawanie adresu IP atakującego do łańcucha f2b-nginx-login w zapory iptables/nftables.
11. Uruchomienie usługi Fail2ban i weryfikacja jej działania za pomocą polecenia fail2ban-client status nginx-login.
12. Przeprowadzenie kontrolowanego ataku słownikowego z poziomu maszyny audytora.
13. Zaobserwowanie momentu nałożenia blokady po 5 nieudanych próbach (zerwanie połączeń TCP przez zaporę).
14. Sprawdzenie listy zablokowanych adresów IP poleceniem fail2ban-client get nginx-login banned.
15. Przetestowanie procedury ręcznego odblokowywania adresu IP (unban) w przypadku omyłkowego zablokowania pracownika.
16. Wdrożenie logowania zdarzeń blokowania do dedykowanego pliku /var/log/fail2ban.log.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z analizą logów i wykresami skuteczności obrony.

Pamiętajcie o poprawnym zrozumieniu parametru `burst` w module `limit_req` Nginx. Parametr `rate=5r/m` pozwala średnio na jedno zapytanie co 12 sekund. Jeśli użytkownik szybko kliknie przycisk logowania dwukrotnie, bez parametru `burst` drugie kliknięcie zostałoby natychmiast odrzucone kodem 429. Parametr `burst=3 nodelay` pozwala na natychmiastowe obsłużenie do 3 zapytań z rzędu, a odrzuca dopiero kolejne próby, co zapewnia idealną równowagę pomiędzy wygodą użytkownika a bezpieczeństwem.

Poniżej przedstawiono konfigurację limitowania zapytań w Nginx oraz reguły więzienia Fail2ban:

Konfiguracja filtra i więzienia w pliku /etc/fail2ban/jail.d/nginx-login.local:

Weryfikacja nałożenia blokady po przeprowadzeniu testowego ataku za pomocą fail2ban-client:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza charakterystyki i wolumenu zautomatyzowanych ataków brute-force, ataków słownikowych oraz credential stuffing na punkty końcowe logowania.
2. Konfiguracja modułu ngx_http_limit_req_module w Nginx z wykorzystaniem algorytmu przeciekającego wiadra (Leaky Bucket) i stref pamięci dzielonej.
3. Strojenie parametrów rate, burst i nodelay w celu skutecznej ochrony API logowania bez blokowania legalnych użytkowników za wspólnym adresem NAT.
4. Integracja serwera Nginx z demonem Fail2ban: parsowanie logów błędów HTTP 401/429 i dynamiczne blokowanie adresów IP na poziomie reguł iptables/nftables.
5. Strategie obronne przed atakami rozproszonymi z botnetów: mechanizmy CAPTCHA, progresywne spowalnianie odpowiedzi (tarpitting) oraz monitoring anomalii.
6. Analiza logów zdarzeń bezpieczeństwa i spełnienie wymogów normy ISO/IEC 27001 w obszarze monitorowania i rejestracji nieautoryzowanych prób dostępu.

Przykładowe wnioski (wzór do sprawozdania): Zastosowanie dwupoziomowej ochrony interfejsu uwierzytelniania opartej na module Nginx limit_req oraz usłudze Fail2ban skutecznie odparło zmasowany atak Credential Stuffing symulowany narzędziem Hydra. Skonfigurowanie dedykowanej strefy limitowania z limitem 5 żądań na minutę i parametrem 'burst=3 nodelay' natychmiast ograniczyło przepustowość złośliwych zapytań z kodem błędu HTTP 429 Too Many Requests. Filtr Fail2ban po wykryciu 5 nieudanych prób logowania w oknie 60 sekund dynamicznie wstrzyknął regułę blokującą w podsystemie nftables, odcinając ruch napastnika na poziomie jądra systemu operacyjnego. Zaimplementowanie mechanizmu zróżnicowanych reguł dla pojedynczych adresów IP zapobiegło przypadkowemu zablokowaniu całych podsieci korporacyjnych korzystających z bramek translacji adresów NAT. Połączenie limitowania aplikacyjnego z blokadą firewall zredukowało zużycie zasobów procesora i bazy danych o 94% podczas trwania symulacji ataku.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Standardy tokenów tożsamościowych.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie bezpiecznego mechanizmu uwierzytelniania i autoryzacji użytkowników opartego na standardzie JSON Web Token (JWT, RFC 7519) w architekturze mikroserwisowej. Studenci analizują typowe błędy implementacyjne i podatności tokenów JWT: atak degradacji algorytmu (Alg: None Attack), atak zamiany klucza (Key Confusion Attack - próba weryfikacji tokena RS256 za pomocą klucza publicznego traktowanego jako symetryczny sekret HMAC), brak weryfikacji daty ważności (claim exp) oraz fałszowanie claims (roli, uprawnień, tożsamości).

W części praktycznej studenci implementują asymetryczny schemat podpisywania tokenów (RS256 lub ES256) z wykorzystaniem pary kluczy asymetrycznych (klucz prywatny w posiadaniu serwera autoryzacji, klucz publiczny dystrybuowany do serwisów weryfikujących), konfigurują bezpieczny model podwójnego tokena (krótkotrwały Access Token o czasie życia 15 minut + bezpieczny Refresh Token przechowywany w ciasteczku HttpOnly) oraz mechanizm unieważniania tokenów (Token Revocation List / Blacklist w Redis).

Firma z branży IoT SmartHome Polska S.A. oferuje platformę do zdalnego sterowania urządzeniami automatyki domowej (kamery, zamki do drzwi, termostaty). Do autoryzacji żądań z aplikacji mobilnych wykorzystywano tokeny JWT generowane przez serwer autoryzacyjny i weryfikowane przez kilkanaście rozproszonych mikroserwisów.

W trakcie audytu bezpieczeństwa wykazano, że biblioteka parsująca tokeny w mikroserwisie sterowania zamkami smart-lock akceptowała tokeny z nagłówkiem "alg": "none" bez weryfikacji sygnatury. Umożliwiło to audytorom wygenerowanie sfałszowanego tokena z rolą "admin" i otworzenie zamków w dowolnym mieszkaniu klienta bez znajomości jakiegokolwiek hasła.

Dodatkowo w pozostałych serwisach stosowano algorytm symetryczny HS256, a sekret HMAC był zakodowany na stałe w kodzie źródłowym aplikacji (Hardcoded Secret), do którego dostęp mieli wszyscy programiści i stażyści. Tokeny miały ustawiony czas ważności na 365 dni i nie istniał żaden mechanizm ich unieważnienia w przypadku kradzieży smartfona.

Zarząd SmartHome Polska nakazał natychmiastową przebudowę całego systemu autoryzacji zgodnie z najlepszymi praktykami OWASP i RFC 8725 (JSON Web Token Best Current Practices).

Grupa laboratoryjna musi zaimplementować bezpieczny serwer uwierzytelniający: wygenerować 2048-bitową parę kluczy RSA, wdrożyć podpisywanie algorytmem RS256, zablokować możliwość użycia algorytmu 'none' i nieautoryzowanych kluczy, wprowadzić rozdzielenie na Access Token (15 min) i Refresh Token (7 dni) oraz stworzyć mechanizm czarnej listy unieważnionych tokenów w bazie Redis.

• Środowisko Node.js z biblioteką jsonwebtoken / Python z biblioteką PyJWT
• OpenSSL 3.x do generowania asymetrycznych par kluczy RSA/ECDSA
• Narzędzie Burp Suite / jwt_tool do testowania podatności tokenów JWT
• Baza danych Redis w kontenerze Docker do obsługi unieważniania tokenów
• Narzędzie online/CLI jwt.io do inspekcji nagłówków i ładunków

1. Zbadanie struktury tokena JWT: podział na Header (nagłówek), Payload (ładunek) i Signature (podpis cyfrowy).
2. Wygenerowanie bezpiecznej asymetrycznej pary kluczy RSA (2048 bitów) za pomocą OpenSSL: private.key oraz public.key.
3. Zaimplementowanie w kodzie backendowym podpisywania tokenów algorytmem RS256 z użyciem klucza prywatnego.
4. Skonfigurowanie mikroserwisów do weryfikacji tokenów wyłącznie przy użyciu klucza publicznego z jawnie zdefiniowaną białą listą algorytmów: algorithms: ['RS256'].
5. Zdefiniowanie obowiązkowych claims w ładunku tokena: sub (identyfikator), exp (czas wygaśnięcia), iat (czas wydania), iss (wystawca), aud (odbiorca).
6. Zademonstrowanie nieskuteczności ataku 'Alg: None' (weryfikacja odrzucenia tokena z algorytmem none przez bibliotekę).
7. Zademonstrowanie nieskuteczności ataku Key Confusion (próba podpisania tokena kluczem publicznym jako sekretem HMAC).
8. Zaimplementowanie architektury podwójnego tokena: Access Token (krótki czas życia: 15 minut) oraz Refresh Token (ważny 7 dni).
9. Zabezpieczenie Refresh Tokena: przechowywanie wyłącznie w ciasteczku z atrybutami HttpOnly, Secure, SameSite=Strict z przypisaniem do ścieżki /api/auth/refresh.
10. Wdrożenie mechanizmu rotacji Refresh Tokena (Refresh Token Rotation): każde użycie tokena odświeżającego unieważnia go i generuje nową parę.
11. Zaimplementowanie mechanizmu natychmiastowego unieważniania tokenów (Revocation) w pamięci podręcznej Redis (Token Blacklisting).
12. Sprawdzenie obecności tokena na czarnej liście w middleware autoryzacyjnym przed przetworzeniem żądania biznesowego.
13. Przetestowanie automatycznego wygasania tokena po upływie czasu określonego w polu exp.
14. Przetestowanie aplikacji za pomocą dedykowanego narzędzia audytorskiego jwt_tool.
15. Zaprojektowanie procedury awaryjnej rotacji kluczy asymetrycznych w przypadku podejrzenia kompromitacji klucza prywatnego.
16. Opracowanie instrukcji bezpiecznej integracji klientów mobilnych z nowym API autoryzacyjnym.
17. Podsumowanie wdrożenia w sprawozdaniu z listingami kodu źródłowego i zrzutami z weryfikacji tokenów.

Najważniejszą zasadą bezpiecznej weryfikacji tokenów JWT jest bezwzględne wymuszenie dozwolonych algorytmów w parametrach biblioteki weryfikującej (np. `algorithms=['RS256']`). Nigdy nie pozwalaj bibliotece na dynamiczne decydowanie o użytym algorytmie na podstawie pola `alg` znajdującego się w nagłówku tokena przysłanego przez klienta, gdyż to właśnie ten mechanizm był źródłem słynnych podatności 'Alg: None' oraz 'HMAC Key Confusion'.

Poniżej przedstawiono implementację bezpiecznego podpisywania i weryfikacji tokena JWT w języku Python za pomocą biblioteki PyJWT:

Próba sfałszowania uprawnień przez napastnika narzędziem jwt_tool kończy się błędem weryfikacji sygnatury:

Sprawdzenie unieważnienia tokena na czarnej liście w bazie Redis za pomocą redis-cli:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza struktury tokenów JWT (Header, Payload, Signature) i podatności algorytmu symetrycznego HS256 na ataki siłowe oraz błędy implementacyjne 'alg: none'.
2. Zalety stosowania podpisów asymetrycznych RS256 i ES256 w architekturze mikroserwisowej: separacja klucza prywatnego (Identity Provider) od publicznego (Resource Servers).
3. Rygorystyczna weryfikacja standardowych oświadczeń (claims): exp (czas wygaśnięcia), nbf (czas aktywacji), iss (wystawca) oraz aud (odbiorca tokena).
4. Bezpieczna architektura wymiany tokenów: krótkotrwałe tokeny dostępu (Short-lived Access Tokens) oraz tokeny odświeżające z mechanizmem rotacji i wykrywania ponownego użycia.
5. Przechowywanie kluczy publicznych i dystrybucja metadanych tożsamości za pośrednictwem bezpiecznych punktów końcowych JWKS (RFC 7517).
6. Zapobieganie atakom typu Key Confusion (zamiana klucza publicznego RSA na klucz symetryczny HMAC) w bibliotekach weryfikujących podpisy tokenów.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzone testy dowiodły, że zastąpienie symetrycznego algorytmu HS256 podpisem asymetrycznym RS256/ES256 eliminuje ryzyko kompromitacji całej infrastruktury mikroserwisowej w przypadku przejęcia jednego z serwerów zasobów. Klucz prywatny niezbędny do wystawiania tokenów pozostaje ściśle odizolowany w usłudze Identity Providera, podczas gdy serwisy brzegowe pobierają wyłącznie klucz publiczny w formacie JWKS. Weryfikacja oświadczeń czasowych 'exp' oraz tożsamości odbiorcy 'aud' skutecznie zabezpieczyła interfejs API przed atakami powtórzeniowymi i użyciem tokenów w nieautoryzowanych kontekstach aplikacyjnych. Wprowadzenie krótkiego czasu życia tokena dostępu (15 minut) powiązanego z rotacją tokenów odświeżających uniemożliwiło długotrwałe nadużycie przechwyconych poświadczeń. Wyeliminowanie możliwości negocjacji algorytmu 'none' oraz blokada zamiany kluczy uczyniły implementację w pełni zgodną ze standardem RFC 8725.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia autentyczności i nienaruszalności informacji. Ochrona przed fałszowaniem żądań.

Celem zadania jest zbadanie mechanizmu ataku fałszowania żądań międzywitrynowych (Cross-Site Request Forgery - CSRF) oraz zaprojektowanie i wdrożenie wielowarstwowej architektury obronnej dla bankowego panelu przelewów internetowych. Studenci analizują, w jaki sposób złośliwa witryna internetowa odwiedzana przez zalogowanego użytkownika może wykorzystać automatyczne dołączanie ciasteczek sesyjnych przez przeglądarkę do wymuszenia wykonania nieautoryzowanej transakcji finansowej lub zmiany hasła.

W części programistycznej studenci implementują i porównują dwa wiodące wzorce obronne: wzorzec tokena synchronizującego (Synchronizer Token Pattern / Anti-CSRF Token) generowanego po stronie serwera i wstrzykiwanego do formularzy HTML oraz wzorzec podwójnego składania ciasteczek (Double Submit Cookie Pattern) dedykowany dla nowoczesnych aplikacji typu Single Page Application (SPA). Zadanie obejmuje również konfigurację atrybutu ciasteczka SameSite oraz weryfikację nagłówków Origin i Referer.

Spółdzielczy Bank Rolny w Grójcu udostępnia rolnikom i lokalnym przedsiębiorcom portal bankowości elektronicznej. W panelu zlecania przelewów zastosowano formularz wysyłający żądanie POST pod adres /transakcje/przelew z parametrami: numer_konta oraz kwota. Serwer weryfikował tożsamość klienta wyłącznie na podstawie ciasteczka sesyjnego przesłanego w nagłówku Cookie.

Podczas kampanii phishingowej przestępcy rozesłali do klientów banku maile z linkiem do fałszywej strony z rzekomymi dopłatami rolniczymi. Złośliwa strona zawierała ukryty formularz HTML z kodem JavaScript automatycznie wysyłającym żądanie POST do serwera banku (atak CSRF): document.forms[0].submit(). Gdy rolnik zalogowany w sąsiedniej karcie do banku otworzył złośliwy link, przeglądarka automatycznie dołączyła aktywne ciasteczko sesyjne, a bank bez wiedzy użytkownika zrealizował przelew na kwotę 10 000 zł na rachunek przestępcy.

Incydent doprowadził do utraty środków przez kilkunastu rolników i wywołał kryzys wizerunkowy banku. Audyt zlecony przez KNF wykazał brak jakichkolwiek tokenów zabezpieczających formularze przed CSRF oraz brak konfiguracji atrybutu SameSite.

Zarząd banku powołał grupę laboratoryjną w celu natychmiastowego zaprojektowania i wdrożenia zabezpieczeń eliminujących ataki CSRF we wszystkich formularzach i endpointach API platformy.

Zadaniem studentów jest odtworzenie ataku CSRF w środowisku testowym (stworzenie złośliwej strony wymuszającej przelew), wdrożenie mechanizmu losowych kryptograficznie tokenów Anti-CSRF powiązanych z sesją użytkownika, wdrożenie ciasteczek SameSite=Strict oraz zaimplementowanie middleware sprawdzającego nagłówki Origin i Referer.

• Środowisko podatne: DVWA / bWAPP lub aplikacja Node.js/PHP
• Narzędzie Burp Suite Community Edition z funkcją CSRF PoC Generator
• Lokalny serwer WWW (Python http.server) do serwowania złośliwej strony atakującej
• Przeglądarka internetowa z narzędziami DevTools (inspekcja nagłówków Origin/Referer)
• Biblioteka csurf / csurf-alternative dla aplikacji webowych

1. Zbadanie podatnego formularza przelewu bankowego pod kątem obecności unikalnych tokenów jednorazowych.
2. Przechwycenie poprawnego żądania POST wykonania przelewu za pomocą Burp Suite.
3. Wygenerowanie złośliwej strony HTML z ukrytym formularzem i automatycznym wywołaniem submit() w JavaScript.
4. Uruchomienie lokalnego serwera na obcej domenie (np. http://zlosliwa-strona.local:8000) serwującego stronę CSRF.
5. Zalogowanie się do aplikacji bankowej w przeglądarce, a następnie otwarcie w sąsiedniej karcie złośliwej strony.
6. Zaobserwowanie wykonania nieautoryzowanego przelewu w tle (sukces ataku CSRF).
7. Analiza przyczyn podatności: automatyczne dołączanie ciasteczek przez przeglądarkę w żądaniach międzywitrynowych.
8. Zaprojektowanie mechanizmu Synchronizer Token Pattern: generowanie kryptograficznego tokena CSRF przy tworzeniu sesji.
9. Osadzenie tokena w ukrytym polu formularza: <input type="hidden" name="csrf_token" value="...">.
10. Zaimplementowanie walidacji tokena po stronie serwera przed wykonaniem operacji zmiany stanu (POST/PUT/DELETE).
11. Zbadanie i wdrożenie wzorca Double Submit Cookie Pattern z nagłówkiem X-CSRF-Token dla żądań AJAX / REST API.
12. Skonfigurowanie atrybutu SameSite=Strict na ciasteczkach sesyjnych, zakazującego ich dołączania przy przekierowaniach z obcych domen.
13. Zaimplementowanie weryfikacji nagłówków Origin oraz Referer w warstwie filtrów serwera WWW.
14. Ponowne uruchomienie złośliwej strony CSRF i weryfikacja zablokowania żądania przez serwer (błąd HTTP 403 Forbidden / Invalid CSRF Token).
15. Zbadanie odporności rozwiązania na ataki polegające na kradzieży tokena CSRF za pomocą XSS (Defense in Depth).
16. Opracowanie wytycznych dla deweloperów dotyczących bezpiecznego stosowania metod idempotentnych (GET nie może zmieniać stanu).
17. Sporządzenie sprawozdania laboratoryjnego z kodem złośliwej strony PoC oraz implementacją zabezpieczeń.

Warto pamiętać, że chociaż atrybut `SameSite=Strict` na ciasteczkach stanowi potężną pierwszą linię obrony przed CSRF, to sam w sobie nie zastępuje klasycznych tokenów Anti-CSRF. W architekturze bezpieczeństwa bankowego obowiązuje zasada obrony w głąb (Defense in Depth): aplikacja musi stosować kryptograficzne tokeny CSRF (Synchronizer Token Pattern) dla każdej operacji modyfikującej stan oraz dodatkowo zabezpieczać ciasteczka atrybutem `SameSite`.

Poniżej przedstawiono implementację ochrony przed CSRF z generowaniem i weryfikacją kryptograficznego tokena w języku PHP:

Złośliwy kod strony atakującej (PoC CSRF) wykorzystujący automatyczne zatwierdzenie formularza w JavaScript:

Odpowiedź serwera bankowego po wdrożeniu ochrony CSRF Token Guard:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Anatomia ataku Cross-Site Request Forgery (CSRF) i wykorzystanie mechanizmu automatycznego dołączania poświadczeń sesyjnych przez przeglądarkę internetową.
2. Porównanie mechanizmu tokenów synchronizujących (Synchronizer Token Pattern) z wzorcem ciasteczek podwójnego składania (Double Submit Cookie Pattern).
3. Wymagania kryptograficzne stawiane tokenom anty-CSRF: wysoka entropia, nieprzewidywalność, powiązanie z unikalną sesją użytkownika i generowanie przez CSPRNG.
4. Rola nagłówka SameSite=Strict oraz SameSite=Lax jako pierwszej linii obrony przeglądarki przed żądaniami pochodzącymi z obcych domen.
5. Weryfikacja nagłówków pochodzenia żądania (Origin oraz Referer) na poziomie serwera aplikacji jako mechanizm obrony głębokiej (Defense in Depth).
6. Integracja tokenów CSRF z asynchronicznymi zapytaniami AJAX/Fetch w architekturze nowoczesnych aplikacji jednostronicowych (Single Page Applications – SPA).

Przykładowe wnioski (wzór do sprawozdania): Symulacja ataku CSRF wykazała, że sama obecność autoryzacyjnych ciasteczek sesyjnych w przeglądarce ofiary pozwala obcej witrynie na potajemne wywołanie nieautoryzowanego przelewu środków. Zaimplementowanie wzorca Synchronizer Token Pattern powiązanego z kryptograficznie bezpieczną sesją użytkownika całkowicie zneutralizowało podatność formularza transakcyjnego. Każde żądanie modyfikujące stan aplikacji zostało uwarunkowane obecnością unikalnego tokenu generowanego z użyciem CSPRNG, którego złośliwa domena nie jest w stanie odczytać z uwagi na politykę Same-Origin Policy. W aplikacjach SPA wdrożenie ciasteczka z flagą SameSite=Strict w połączeniu z automatyczną weryfikacją nagłówka Origin stworzyło wielowarstwową barierę ochronną. Przeprowadzone testy potwierdziły pełną zgodność zrealizowanego zabezpieczenia z wytycznymi OWASP Cross-Site Request Forgery Prevention Cheat Sheet.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia integralności i dostępności informacji. Bezpieczeństwo uploadu plików.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie kompleksowego potoku bezpiecznego przesyłania plików przez użytkowników (Secure File Upload Pipeline) w portalu internetowym. Studenci badają mechanizmy powstawania i eksploatacji krytycznych podatności związanych z przesyłaniem niebezpiecznych plików (Unrestricted File Upload), umożliwiających wgranie skryptu powłoki webowej (Web Shell w PHP/JSP) i uzyskanie zdalnego wykonania kodu na serwerze (Remote Code Execution - RCE).

W ramach ćwiczenia studenci wdrażają wielowarstwowe mechanizmy obronne: rygorystyczną białą listę rozszerzeń (Whitelist), weryfikację nagłówków MIME, inspekcję magicznych bajtów pliku (Magic Bytes / File Signatures), losową zmianę nazwy pliku na identyfikator UUID v4, skanowanie antywirusowe w locie za pomocą darmowego silnika ClamAV, a także przechowywanie przesłanych plików całkowicie poza katalogiem publicznym serwera WWW (Webroot) z blokadą wykonywania skryptów.

Internetowe Biuro Karier Uczelni 'TalentHunter' umożliwia studentom i absolwentom rejestrację profilu zawodowego oraz przesyłanie dokumentów aplikacyjnych (CV, certyfikaty, listy motywacyjne) w formatach PDF i DOCX. W formularzu przesyłania plików zastosowano jedynie prostą weryfikację rozszerzenia po stronie klienta w języku JavaScript oraz sprawdzanie nagłówka Content-Type przesłanego przez przeglądarkę.

Podczas audytu bezpieczeństwa testerzy przechwycili żądanie przesyłania pliku w programie Burp Suite, zmodyfikowali nazwę pliku z cv.pdf na webshell.php, a w treści wstrzyknęli prosty skrypt powłoki <?php system($_GET['cmd']); ?>. Serwer zapisał plik bezpośrednio w publicznym katalogu /var/www/html/uploads/webshell.php. Testerzy, odpytując adres URL https://biurokarier.local/uploads/webshell.php?cmd=id, uzyskali pełny dostęp do powłoki systemu operacyjnego z uprawnieniami konta www-data.

Co więcej, napastnik mógł za pośrednictwem Web Shella odczytać pliki konfiguracyjne bazy danych, pobrać dane osobowe tysięcy studentów oraz wykorzystać serwer jako platformę do rozsyłania spamu i ataków na inne jednostki uczelni.

Władze uczelni nakazały natychmiastowe zablokowanie modułu uploadu i stworzenie od podstaw bezpiecznego mechanizmu obsługi przesyłanych plików, wykluczającego możliwość wgrania i wykonania jakiegokolwiek złośliwego kodu.

Zadaniem grupy laboratoryjnej jest zaimplementowanie bezpiecznego potoku uploadu: usunięcie publicznego dostępu do katalogu uploads, weryfikacja magicznych bajtów plików (File Signature), integracja z demonem antywirusowym ClamAV (clamdscan), losowa zmiana nazwy każdego pliku oraz konfiguracja serwera Nginx blokująca wykonywanie skryptów w katalogach statycznych.

• Serwer WWW Nginx / Apache z modułem PHP / Python
• Skaner antywirusowy ClamAV z demonem clamd w środowisku Linux
• Narzędzie file / libmagic do inspekcji sygnatur binarnych plików
• Burp Suite Community Edition do manipulacji nagłówkami i parametrami uploadu
• Narzędzie hexdump / xxd do analizy i modyfikacji magicznych bajtów plików

1. Zbadanie podatnego formularza uploadu plików i zademonstrowanie ominięcia walidacji JavaScript.
2. Stworzenie nieszkodliwego pliku testowego Web Shell w PHP i pomyślne wgranie go na serwer podatny.
3. Wykonanie polecenia systemowego (Proof of Concept RCE) za pośrednictwem wgranego skryptu.
4. Analiza luk architektonicznych: przechowywanie plików w webroot, wykonywanie kodu PHP w katalogu uploads, poleganie na nagłówku Content-Type.
5. Zaprojektowanie bezpiecznej lokalizacji składowania plików całkowicie poza katalogiem publicznym: /var/storage/uploads/.
6. Wdrożenie rygorystycznej białej listy rozszerzeń (.pdf, .docx, .odt) – odrzucenie wszelkich innych formatów.
7. Zaimplementowanie weryfikacji sygnatury binarnej (Magic Bytes): sprawdzenie czy plik PDF zaczyna się od bajtów %PDF (0x25 0x50 0x44 0x46).
8. Wykorzystanie biblioteki fileinfo / libmagic do głębokiej analizy typu pliku niezależnie od rozszerzenia.
9. Zaimplementowanie losowej zmiany nazwy pliku na unikalny identyfikator UUID v4 (np. a1b2c3d4-e5f6-....pdf) z usunięciem oryginalnej nazwy.
10. Instalacja i konfiguracja demona antywirusowego ClamAV (clamd) w systemie Linux.
11. Zintegrowanie skanowania antywirusowego w locie: każdy przesłany plik jest skanowany przez clamdscan przed zapisem na dysk.
12. Skonfigurowanie serwera Nginx: całkowity zakaz wykonywania jakichkolwiek skryptów w lokalizacjach statycznych (fastcgi_pass zablokowany).
13. Zaimplementowanie bezpiecznego serwowania plików użytkownikom za pośrednictwem skryptu pośredniczącego z nagłówkiem Content-Disposition: attachment.
14. Przetestowanie odporności systemu za pomocą pliku testowego EICAR Standard Anti-Virus Test File.
15. Zweryfikowanie zablokowania pliku EICAR i zarejestrowania zdarzenia przez silnik ClamAV.
16. Przetestowanie prób ominięcia filtrów za pomocą podwójnych rozszerzeń (cv.php.pdf) oraz bajtu zerowego (cv.php%00.pdf).
17. Sporządzenie sprawozdania laboratoryjnego z kompletnym kodem bezpiecznego modułu uploadu i logami skanowania.

Nigdy nie pozwalaj na bezpośredni dostęp przeglądarek do katalogu, w którym zapisywane są pliki przesyłane przez użytkowników. Pliki powinny znajdować się poza strukturą dokumentów serwera WWW (`outside webroot`), a ich pobieranie powinno odbywać się wyłącznie przez dedykowany skrypt pośredniczący, który wymusza pobranie pliku jako załącznik (`Content-Disposition: attachment`), co uniemożliwia przeglądarce wykonanie złośliwego kodu HTML lub SVG w kontekście domeny.

Poniżej przedstawiono bezpieczną procedurę weryfikacji magicznych bajtów i skanowania ClamAV w języku PHP:

Wykrycie złośliwego pliku testowego EICAR przez silnik ClamAV z poziomu wiersza poleceń:

Konfiguracja Nginx gwarantująca brak możliwości wykonania kodu PHP w katalogu pobierania:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Wektory zagrożeń związane z niekontrolowanym przesyłaniem plików przez użytkowników (Remote Code Execution, Web Shell, fałszowanie MIME, SVG XSS, Zip Slip).
2. Wielopoziomowa walidacja plików: weryfikacja nagłówka Content-Type, rozszerzenia z białej listy oraz sygnatury binarnej (Magic Numbers).
3. Izolacja przestrzeni dyskowej: przechowywanie przesłanych plików poza drzewem dokumentów serwera WWW (poza Webroot) lub w obiektowej pamięci masowej.
4. Deterministyczna zmiana nazw plików na losowe identyfikatory UUIDv4 z usunięciem oryginalnych nazw oraz niebezpiecznych metadanych EXIF.
5. Integracja potoku przesyłania plików z silnikiem antywirusowym ClamAV / ClamDaemon w celu automatycznego skanowania w locie przed zapisem.
6. Konfiguracja serwera WWW: wymuszenie nagłówka Content-Disposition: attachment, wyłączenie wykonywania skryptów w katalogu uploadu oraz limit rozmiaru żądania.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna analiza podatności modułu uploadu wykazała, że poleganie wyłącznie na rozszerzeniu pliku lub nagłówku Content-Type pozwala na łatwe umieszczenie skryptu PHP Web Shell pod postacią rzekomego pliku JPEG. Wdrożenie inspekcji sygnatury binarnej (Magic Numbers) w połączeniu z rygorystyczną białą listą dozwolonych typów MIME skutecznie udaremniło próby oszukania walidatora. Przeniesienie docelowego katalogu składowania plików całkowicie poza katalog Document Root oraz wyłączenie praw do wykonywania kodu uniemożliwiło bezpośrednie wywołanie przesłanego kodu przez przeglądarkę. Każdy plik przed trwałym zapisem został poddany inspekcji antywirusowej przez demona ClamAV, a jego nazwa zastąpiona losowym ciągiem UUIDv4 pozbawionym metadanych EXIF. Wdrożony potok stanowi wzorcową realizację zaleceń OWASP File Upload Security i całkowicie eliminuje ryzyko wrogiego przejęcia serwera.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. Wirtualizacja i konteneryzacja.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie zaawansowanej architektury utwardzonej konteneryzacji serwisu internetowego w środowisku Docker, minimalizującej ryzyko ucieczki z kontenera (Container Breakout) do systemu gospodarza (Host OS). Studenci badają mechanizmy izolacji jądra systemu Linux stanowiące fundament kontenerów: przestrzenie nazw (Namespaces), grupy kontrolne (Cgroups), filtry wywołań systemowych (Seccomp) oraz obowiązkową kontrolę dostępu (AppArmor / SELinux).

W części praktycznej studenci konfigurują demona Docker w trybie bezuprawnieniowym (Rootless Mode), tworzą utwardzone obrazy kontenerów bazujące na dystrybucji minimalnej (Distroless / Alpine), wymuszają system plików tylko do odczytu (Read-Only Root Filesystem), blokują eskalację uprawnień (no-new-privileges) oraz odrzucają wszystkie zbędne zdolności jądra (Drop All Capabilities). Zadanie uczy również audytowania obrazów pod kątem podatności CVE za pomocą narzędzia Trivy.

Firma fintechowa PayGate Polska Sp. z o.o. przetwarza transakcje płatnicze za pośrednictwem mikrousług uruchomionych w kontenerach Docker. W trakcie audytu bezpieczeństwa wykazano, że wszystkie kontenery działały z domyślną konfiguracją Dockera: proces serwera aplikacji wewnątrz kontenera działał z uprawnieniami użytkownika root (uid=0), system plików kontenera był w pełni zapisywalny, a kontener posiadał zamontowany socket Dockera (/var/run/docker.sock) w celu automatyzacji wdrożeń.

Audytorzy zademonstrowali krytyczny atak ucieczki z kontenera: wykorzystując drobną podatność w aplikacji webowej, uzyskali dostęp do powłoki w kontenerze, a następnie za pośrednictwem otwartego gniazda /var/run/docker.sock wydali polecenie uruchomienia nowego kontenera uprzywilejowanego z zamontowanym głównym systemem plików hosta (docker run -v /:/host). W niespełna minutę audytorzy uzyskali pełną kontrolę nad fizycznym serwerem dedykowanym w centrum danych.

Incydent ten uświadomił zarządowi, że domyślny Docker nie zapewnia wystarczającej izolacji dla krytycznych systemów finansowych podlegających wymogom standardu PCI DSS v4.0.

Zarząd powierzył grupie laboratoryjnej zadanie całkowitego utwardzenia infrastruktury konteneryzacji. Należy wdrożyć środowisko Docker Rootless, przepisać pliki Dockerfile w celu wyeliminowania konta root na rzecz użytkownika nieuprzywilejowanego (UID 10001), zablokować możliwość modyfikacji systemu plików kontenera w czasie działania oraz zastosować rygorystyczne profile seccomp i AppArmor.

Sprawozdanie musi zawierać zoptymalizowany plik Dockerfile, konfigurację docker-compose.yml z parametrami bezpieczeństwa, raport ze skanera Trivy oraz dowody zablokowania prób modyfikacji plików i wywołań systemowych wewnątrz kontenera.

• Środowisko Docker Engine 24.x+ w systemie Linux Ubuntu / Debian
• Narzędzie audytorskie i skaner podatności obrazów: Trivy
• Narzędzie do inspekcji profili seccomp i AppArmor (aa-status, seccomp-tools)
• Narzędzie Docker Bench for Security (darmowy skaner zgodności z CIS Benchmark)
• Minimalne obrazy bazowe: cgr.dev/chainguard/static, alpine, distroless

1. Przeprowadzenie audytu bezpieczeństwa bieżącej instalacji Dockera za pomocą narzędzia Docker Bench for Security.
2. Analiza wektorów ucieczki z kontenera: niebezpieczeństwo montowania gniazda /var/run/docker.sock oraz flagi --privileged.
3. Konfiguracja środowiska Docker w trybie Rootless (demon Dockera uruchamiany w przestrzeni użytkownika bez uprawnień root hosta).
4. Przygotowanie wieloetapowego pliku Dockerfile (Multi-stage Build) redukującego rozmiar obrazu i eliminującego narzędzia deweloperskie (kompilatory, curl).
5. Utworzenie i zdefiniowanie dedykowanego użytkownika nieuprzywilejowanego w Dockerfile: USER appuser (UID 10001).
6. Skanowanie zbudowanego obrazu kontenera pod kątem podatności CVE za pomocą narzędzia Trivy (trivy image myapp:latest).
7. Konfiguracja uruchomienia kontenera z systemem plików tylko do odczytu: flaga --read-only.
8. Wydzielenie tymczasowych katalogów do zapisu w pamięci RAM za pomocą montowania tmpfs: --tmpfs /tmp:rw,noexec,nosuid,size=64m.
9. Odebranie kontenerowi wszystkich zdolności jądra Linux: --cap-drop=ALL i dodanie wyłącznie niezbędnych (np. --cap-add=NET_BIND_SERVICE).
10. Wdrożenie zabezpieczenia przed eskalacją uprawnień wewnątrz kontenera: --security-opt=no-new-privileges:true.
11. Zastosowanie restrykcyjnego profilu seccomp blokującego zbędne wywołania systemowe jądra: --security-opt seccomp=/path/to/profile.json.
12. Włączenie i przypisanie profilu AppArmor dla kontenera: --security-opt apparmor=docker-default.
13. Ograniczenie zasobów sprzętowych kontenera w celu ochrony przed atakami DoS: --memory=512m --cpus=1.0.
14. Przetestowanie odporności kontenera: próba utworzenia pliku w katalogu głównym (touch /test) kończąca się błędem Read-only file system.
15. Próba wywołania zakazanego wywołania systemowego (np. ptrace) kończąca się zablokowaniem przez profil seccomp.
16. Opracowanie pliku docker-compose.yml integrującego wszystkie utwardzone parametry uruchomieniowe.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z wynikami audytu przed i po utwardzeniu.

Wdrożenie flagi `--read-only` na kontenerze jest jednym z najskuteczniejszych środków ochrony przed atakami typu Web Shell i złośliwym oprogramowaniem. Nawet jeśli napastnik znajdzie lukę w kodzie aplikacji i spróbuje pobrać narzędzie exploitujące lub zmodyfikować kod serwera, jądro systemu natychmiast zablokuje operację zapisu błędem `Read-only file system`. Aplikacja powinna zapisywać dane wyłącznie do dedykowanych wolumenów lub do pamięci tymczasowej `tmpfs`.

Poniżej przedstawiono wzorcowy, utwardzony plik `docker-compose.yml` spełniający wytyczne CIS Benchmark:

Próba zapisu pliku wewnątrz uruchomionego kontenera kończy się błędem jądra:

Wynik skanowania bezpieczeństwa obrazu kontenera narzędziem Trivy:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza wektorów ucieczki z kontenera (Container Breakout) wynikających z uruchamiania procesów jako domyślny root (UID 0) oraz montowania gniazda docker.sock.
2. Konfiguracja środowiska Docker w trybie bezuprawnieniowym (Rootless Mode) oraz tworzenie dedykowanych użytkowników nieuprzywilejowanych w plikach Dockerfile.
3. Wymuszenie niemutowalności środowiska uruchomieniowego za pomocą flagi --read-only z montowaniem pamięci tymczasowej tmpfs dla katalogów roboczych.
4. Redukcja uprawnień jądra systemu Linux poprzez odrzucenie wszystkich zdolności (--cap-drop=ALL) i selektywne dodanie wyłącznie niezbędnych uprawnień.
5. Ograniczanie powierzchni ataku na jądro gospodarza za pomocą profili Seccomp (blokowanie zbędnych syscalli) oraz polityk AppArmor/SELinux.
6. Automatyzacja audytu bezpieczeństwa obrazów kontenerowych w potokach CI/CD za pomocą skanera podatności Trivy pod kątem znanych luk CVE.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie utwardzonej konfiguracji konteneryzacji całkowicie wyeliminowało ryzyko ucieczki do systemu gospodarza (Host Breakout) po potencjalnej kompromitacji serwisu WWW. Zastąpienie domyślnego użytkownika root kontem nieuprzywilejowanym o UID 10001 uniemożliwiło wykonywanie operacji administracyjnych i przejęcie kontroli nad demonem kontenera. Zastosowanie flagi read-only w połączeniu z odrzuceniem wszystkich zdolności jądra (--cap-drop=ALL) skutecznie zablokowało próby pobrania i uruchomienia narzędzi exploitujących na systemie plików kontenera. Ograniczenie wywołań systemowych profilem Seccomp oraz precyzyjna polityka AppArmor odcięły napastnikowi dostęp do krytycznych zasobów jądra Linux. Automatyczne skanowanie obrazów za pomocą narzędzia Trivy pozwoliło na wyeliminowanie podatności CVE w bibliotekach bazowych, spełniając wymogi CIS Docker Benchmark.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i integralności informacji. Metodyka audytu oprogramowania.

Celem zadania jest przeprowadzenie całościowego, metodycznego audytu bezpieczeństwa aplikacji webowej przy użyciu darmowego, otwartoźródłowego narzędzia OWASP Zed Attack Proxy (OWASP ZAP), stanowiącego standard branżowy w automatycznym i półautomatycznym testowaniu aplikacji internetowych (DAST - Dynamic Application Security Testing). Studenci poznają dwa komplementarne podejścia audytorskie: pasywne skanowanie ruchu (Passive Scanning) analizujące nagłówki i odpowiedzi serwera bez generowania nowych pakietów oraz aktywne skanowanie podatności (Active Scanning) symulujące realne ataki.

W ramach laboratorium studenci konfigurują mechanizmy uwierzytelniania w ZAP (Session Management / Form-based Authentication), mapują strukturę aplikacji za pomocą tradycyjnego spidera i Ajax Spidera (dla aplikacji SPA renderowanych w JavaScript), analizują wykryte podatności według standardu CWE i OWASP Top 10, eliminują fałszywe alarmy (False Positives) oraz generują profesjonalny, techniczny raport audytorski spełniający wymogi formalne odbioru systemów informatycznych.

Wojewódzki Urząd Pracy w Rzeszowie wdraża nowy portal elektronicznych wniosków dotacyjnych dla przedsiębiorców 'DotacjePodkarpacie'. Zgodnie z zapisami umowy o dofinansowanie ze środków Unii Europejskiej, przed oficjalnym uruchomieniem produkcyjnym system musi przejść niezależny audyt bezpieczeństwa DAST poświadczony raportem z darmowego narzędzia audytorskiego akredytowanego przez społeczność Open Source.

Dotychczasowe testy manualne przeprowadzone przez firmę programistyczną nie wykazały krytycznych błędów, jednakże wstępne podłączenie skanera OWASP ZAP w trybie pasywnym ujawniło brak podstawowych nagłówków ochronnych, przesyłanie wrażliwych tokenów w parametrach GET oraz podatność na ataki typu Open Redirect w module logowania przez Profil Zaufany.

Kierownik projektu ze strony urzędu wstrzymał odbiór końcowy systemu do czasu dostarczenia formalnego raportu z pełnego skanowania podatności (obejmującego strefy dostępne po zalogowaniu wnioskodawcy) oraz wykazania, że wszystkie podatności o poziomie High i Medium zostały całkowicie wyeliminowane lub opatrzone akceptacją ryzyka.

Grupa laboratoryjna przyjmuje rolę niezależnego zespołu audytorów bezpieczeństwa. Zadaniem studentów jest skonfigurowanie środowiska OWASP ZAP, przeprowadzenie pełnego rekonesansu aplikacji testowej (tradycyjny spider + Ajax Spider z przeglądarką headless), skonfigurowanie uwierzytelniania sesyjnego, wykonanie skanowania aktywnego z dostrojonymi regułami, weryfikacja wykrytych alertów oraz wygenerowanie formalnego raportu audytowego.

Sprawozdanie musi zawierać profil konfiguracji ZAP, omówienie zidentyfikowanych podatności z podaniem ich identyfikatorów CWE i WASC, analizę przynajmniej jednego potwierdzonego błędu (wraz z wektorem żądania i odpowiedzi HTTP) oraz zredagowane rekomendacje naprawcze dla programistów.

• Narzędzie OWASP Zed Attack Proxy (ZAP) v2.14+ (interfejs GUI oraz wersja CLI/Docker zap2docker)
• Aplikacja testowa podatna: OWASP Juice Shop / DVWA / bWAPP w kontenerze Docker
• Przeglądarka internetowa zintegrowana z OWASP ZAP (HUD - Heads Up Display)
• Narzędzie zap-cli do automatyzacji skanowania w potoku CI/CD
• Edytor raportów HTML / Markdown do analizy wyników audytu

1. Instalacja i pierwsze uruchomienie narzędzia OWASP ZAP z konfiguracją certyfikatu Root CA w przeglądarce.
2. Zdefiniowanie zakresu audytu (Context & Scope): określenie dozwolonych adresów URL i wykluczenie ścieżek wylogowania (/logout).
3. Uruchomienie skanowania pasywnego: ręczne przejście kluczowych ścieżek aplikacji i analiza alertów w panelu Alerts.
4. Uruchomienie modułu ZAP Traditional Spider w celu automatycznego zmapowania statycznych linków i formularzy.
5. Uruchomienie modułu ZAP Ajax Spider z silnikiem Chromium Headless w celu zindeksowania dynamicznych komponentów JavaScript.
6. Skonfigurowanie uwierzytelniania formularzowego (Form-based Authentication) w ZAP z loginem i hasłem konta audytorskiego.
7. Zdefiniowanie wskaźnika zalogowania (Logged-in Indicator regex) umożliwiającego ZAP-owi automatyczne odnawianie wygasłej sesji.
8. Dostosowanie polityki skanowania aktywnego (Active Scan Policy): włączenie reguł SQLi, XSS, Path Traversal, Command Injection.
9. Uruchomienie skanowania aktywnego (Active Scan) na zdefiniowanym kontekście aplikacji.
10. Monitorowanie postępu skanowania i liczby wysyłanych zapytań w panelu Active Scan.
11. Weryfikacja wykrytych podatności: manualne sprawdzenie każdego alertu o statusie High i Medium w celu wyeliminowania False Positives.
12. Zbadanie podatności Open Redirect za pomocą modułu ZAP Manual Request Editor.
13. Wygenerowanie formalnego raportu z audytu w formacie HTML oraz JSON (Generate Report -> Traditional HTML Report).
14. Przeanalizowanie raportu pod kątem zgodności z OWASP Top 10 2021 oraz klasyfikacją słabości CWE.
15. Sformułowanie matrycy zaleceń naprawczych z przypisaniem priorytetów (Krytyczny, Wysoki, Średni, Niski).
16. Uruchomienie skróconego skanowania ZAP Baseline Scan z poziomu kontenera Docker (automatyzacja CI/CD).
17. Sporządzenie sprawozdania laboratoryjnego z podsumowaniem audytu i zrzutami ekranu z konsoli ZAP.

Podczas przeprowadzania skanowania aktywnego za pomocą narzędzia OWASP ZAP krytycznie ważne jest zdefiniowanie w kontekście adresu wylogowania (`/logout`) jako adresu wykluczonego ze skanowania (`Exclude from Context`). W przeciwnym razie skaner, testując parametry na stronie wylogowania, natychmiast zakończy sesję uwierzytelnioną i całe dalsze skanowanie stref chronionych hasłem będzie bezużyteczne (będzie skanować wyłącznie stronę logowania).

Poniżej przedstawiono przykładowe uruchomienie zautomatyzowanego skanowania OWASP ZAP Baseline Scan za pomocą oficjalnego kontenera Docker:

Weryfikacja podatności Open Redirect wykrytej przez ZAP w konsoli cURL:

Inspekcja podsumowania alertów bezpieczeństwa w raporcie JSON wygenerowanym przez OWASP ZAP:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Rola testów dynamicznych DAST (Dynamic Application Security Testing) w cyklu życia bezpiecznego oprogramowania w porównaniu do analizy statycznej SAST.
2. Metodyka skanowania pasywnego (analiza nagłówków, ciasteczek, wycieków informacji) oraz skanowania aktywnego (wstrzykiwanie ładunków testowych i fuzzing).
3. Konfiguracja uwierzytelniania opartego na formularzach (Form-based Authentication) i zarządzania sesją w OWASP ZAP w celu audytu chronionych stref portalu.
4. Wykorzystanie tradycyjnego pająka oraz Ajax Spidera z przeglądarką headless do pełnego zmapowania zasobów nowoczesnych aplikacji jednostronicowych (SPA).
5. Procedura weryfikacji alertów, kategoryzacji podatności według standardów CWE/OWASP oraz eliminacji fałszywych alarmów (False Positives).
6. Opracowanie formalnego, technicznego raportu audytowego z priorytetyzacją ryzyk i rekomendacjami naprawczymi dla zespołów programistycznych.

Przykładowe wnioski (wzór do sprawozdania): Kompleksowy audyt bezpieczeństwa przeprowadzony za pomocą narzędzia OWASP ZAP pozwolił na zidentyfikowanie krytycznych podatności aplikacyjnych przed oficjalnym wdrożeniem produkcyjnym portalu. Połączenie tradycyjnego pająka z mechanizmem Ajax Spider umożliwiło pełne zindeksowanie dynamicznych tras w aplikacji jednostronicowej oraz zmapowanie chronionych punktów końcowych API po uwierzytelnieniu sesyjnym. Skanowanie aktywne wykazało podatność na otwarte przekierowania (Open Redirect, CWE-601) w module logowania oraz brak nagłówków chroniących przed atakami Clickjacking. Szczegółowa analiza każdego alertu pozwoliła na wyeliminowanie fałszywych trafień w skanerze podatności SQLi i precyzyjne sformułowanie zaleceń naprawczych w oparciu o taksonomię OWASP Top 10. Wygenerowany raport techniczny stanowił formalną podstawę do wdrożenia poprawek w kodzie źródłowym i pomyślnego odbioru systemu przez zamawiającego.