Źródła ryzyka

Klasyfikacja według źródeł ryzyk to podejście polegające na grupowaniu zagrożeń w oparciu o warstwę architektury. Podejście to ułatwia odpowiedź na pytanie: „co należy testować?”. Określenie potencjalnych wektorów ataku oraz komponentów o podwyższonym ryzyku umożliwia opracowanie specyfikacji testów ukierunkowanych na konkretne elementy systemu. Taki podział nie tylko wspiera efektywne zarządzanie ryzykiem, ale także pozwala lepiej priorytetyzować działania testowe.

Example

Ryzyka związane z logiką aplikacji (Application Logic Risks)
Logika aplikacji stanowi jeden z najbardziej złożonych i trudnych do zabezpieczenia obszarów systemu. Błędy w tym zakresie rzadko wynikają z podatności technicznych — ich przyczyną są najczęściej niewłaściwie zaprojektowane przepływy i reguły biznesowe, które umożliwiają użytkownikowi wykonanie nieautoryzowanych operacji. Choć ryzyka tego typu mogą dotyczyć także innych warstw systemu (np. interfejsu użytkownika, systemu plików czy warstwy sieciowej), to ich źródłem jest zawsze logika aplikacji, czyli sposób, w jaki system przetwarza dane i kontroluje stany.


Typowe przykłady ryzyk związanych z logiką aplikacji:

  • Błędy w przepływie danych i kontroli dostępu — użytkownik może ominąć mechanizmy uwierzytelniania lub autoryzacji.
  • Niewłaściwe przetwarzanie wyjątków — komunikaty błędów ujawniają szczegóły techniczne, takie jak nazwy klas, ścieżki do plików czy logi debugowania.
  • Brak walidacji stanów aplikacji — brak kontroli nad sekwencją operacji (np. w procesie płatności) może umożliwiać manipulacje, takie jak powielanie zamówień lub modyfikację wartości transakcji.
  • Ominięcie mechanizmów uwierzytelniania — błędy w logice sesji lub alternatywnych ścieżkach logowania mogą pozwolić na nieautoryzowany dostęp.

Application Logic Risks to warstwa nadrzędna, która definiuje błędy w projektowaniu logiki systemu, a podkategorie techniczne (UI, File System, OS, Third-Party, Network) to obszary, w których te błędy się manifestują lub eskalują do realnych podatności.

Podkategorie techniczne (warstwy architektury)

  1. Ryzyka związane z interfejsem użytkownika (UI Risks)
    Interfejs użytkownika to punkt styku pomiędzy użytkownikiem a systemem. Ryzyka związane z UI wynikają najczęściej z błędów projektowych, nieprawidłowej implementacji lub niewystarczającego testowania tej warstwy. Takie błędy mogą prowadzić do luk bezpieczeństwa, umożliwiających np. nieautoryzowany dostęp lub manipulację danymi. Jednym z najczęstszych problemów jest brak odpowiedniej walidacji danych wejściowych. Gdy dane wprowadzane przez użytkownika nie są prawidłowo weryfikowane, aplikacja może być podatna na ataki typu SQL Injection lub Cross-Site Scripting (XSS), umożliwiające manipulację danymi lub przejęcie kontroli nad aplikacją. Kolejnym zagrożeniem są nieprawidłowo zaprojektowane mechanizmy autoryzacji i uwierzytelniania, które mogą prowadzić do ataków brute force, przejęcia sesji lub innych form nieuprawnionego dostępu. Dodatkowo, UI może ujawniać nadmiarowe informacje w komunikatach błędów lub debugujących elementach interfejsu — dane te mogą posłużyć atakującym do rozpoznania struktury systemu. W konsekwencji mogą stanowić cenne wskazówki dla potencjalnych ataków. Istotnym, często pomijanym zagrożeniem jest także brak zabezpieczenia przed tzw. „clickjackingiem”. Atakujący może manipulować interfejsem użytkownika za pomocą np. ramki iframe — nakładając przezroczystą warstwę z własnym przyciskiem na elementy prawdziwego interfejsu. Przykładowo: użytkownik widzi przycisk „Potwierdź transakcję” na stronie banku, ale faktycznie klika w niewidoczny przycisk złośliwego interfejsu, uruchamiając działania na korzyść atakującego. Dobrą ilustracją powyższych zagrożeń jest luka oznaczona identyfikatorem CVE-2018-0296, występu- jąca w urządzeniach Cisco ASA (Adaptive Security Appliance). Umożliwiała atakującemu ominięcie mechanizmu uwierzytelniania przez manipulację ścieżką URL w interfejsie webowym. W efekcie nieautoryzowany użytkownik mógł uzyskać dostęp do zasobów chronionych, bez posiadania odpowiednich uprawnień


    Podsumowanie ryzyk związanych z interfejsem użytkownika (UI):

    • Brak walidacji danych wejściowych (np. SQL Injection, Cross-Site Scripting — XSS).
    • Błędne lub niewystarczające mechanizmy uwierzytelniania i autoryzacji.
    • Wycieki informacji przez komunikaty błędów lub elementy debugujące.
    • Clickjacking (manipulacja interfejsem poprzez nakładanie niewidocznych elementów).

  2. Ryzyka związane z systemem plików (File System Risks)
    System plików odpowiada za przechowywanie danych aplikacji oraz użytkowników. Niewłaściwe zarządzanie tą warstwą może prowadzić do utraty danych, nieautoryzowanego dostępu lub eskalacji uprawnień. Jednym z typowych problemów jest przechowywanie haseł, tokenów lub kluczy dostępowych w plikach konfiguracyjnych w postaci niezaszyfrowanej. Takie dane, jeśli zostaną przypadkowo udostępnione — na przykład poprzez dodanie do publicznego repozytorium — stają się łatwym celem dla atakujących. Równie istotnym zagrożeniem jest brak odpowiednich zabezpieczeń dostępu do plików. Jeżeli prawa dostępu są źle skonfigurowane, osoby nieuprawnione mogą uzyskać wgląd do danych wrażliwych, co narusza poufność oraz integralność systemu. Innym krytycznym zagrożeniem jest manipulacja ścieżkami plików, znana jako path traversal. Ata- kujący może wykorzystać tę technikę, aby uzyskać dostęp do plików poza zamierzonym katalogiem aplikacji — prowadząc do ujawnienia informacji, a nawet przejęcia kontroli nad systemem. Nie można również pominąć ryzyka związanego z niewłaściwym zarządzaniem logami. Zbyt szcze- gółowe dzienniki mogą zawierać dane wrażliwe, takie jak hasła, tokeny lub informacje osobowe. Ich przypadkowe ujawnienie — np. przez logowanie pełnych treści żądań lub błędów — stanowi poważne zagrożenie bezpieczeństwa.


    Podsumowanie ryzyk związanych z systemem plików:

    • Przechowywanie wrażliwych danych (np. haseł, tokenów) w postaci niezaszyfrowanej.
    • Niewłaściwie skonfigurowane prawa dostępu do plików.
    • Możliwość przeprowadzenia ataku typu path traversal.
    • Nadmiarowo szczegółowe logi zawierające dane wrażliwe.

  3. Ryzyka związane z systemem operacyjnym (Operating System Risks)
    System operacyjny (OS) pełni rolę pośrednika między sprzętem a oprogramowaniem. Błędy konfiguracyjne, brak aktualizacji lub nieodpowiednie zarządzanie tym środowiskiem mogą otworzyć drogę do różnorodnych ataków. Źródłem ryzyk są najczęściej nieprawidłowe ustawienia konfiguracyjne lub przestarzałe zabezpieczenia systemu. Problemy te mogą wynikać z braku regularnych aktualizacji systemu operacyjnego bądź wykorzystywanych przez niego bibliotek. Starsze wersje systemów zawierają często znane podatności, które zostały już załatane w nowszych wydaniach — pod warunkiem, że użytkownik zadba o ich wdrożenie. Jednym z najbardziej znanych przykładów zagrożenia tego typu był globalny atak ransomware WannaCry z 2017 roku. Wykorzystano w nim lukę w obsłudze protokołu SMBv1 (CVE-2017-0144) w systemach Windows, co umożliwiało zdalne wykonanie kodu na podatnych komputerach. Atak dotknął głównie te systemy, które nie zostały odpowiednio zaktualizowane, mimo że poprawka bezpieczeństwa była dostępna już wcześniej


    Podsumowanie ryzyk związanych z systemem operacyjnym:

    • Brak aktualizacji i łat bezpieczeństwa dla znanych podatności.
    • Niewłaściwa konfiguracja systemu (np. słabe polityki haseł, brak ochrony konta root).
    • Możliwość wycieku wrażliwych danych z pamięci systemowej podczas awarii.

  4. Ryzyka związane z zewnętrznym oprogramowaniem (Third-Party Software Risks)
    Zewnętrzne oprogramowanie — takie jak biblioteki, narzędzia lub komponenty firm trzecich — jest powszechnie wykorzystywane w systemach informatycznych w celu przyspieszenia prac rozwojowych. Choć rozwiązania te często zwiększają efektywność i skracają czas wdrożeń, jednocześnie wprowadzają nowe źródła ryzyka. Ryzyka te mogą wynikać zarówno z bezpośredniej integracji z oprogramowaniem zewnętrznym, jak i z jego obecności w kodzie projektu. Przykładem zagrożenia związanym z komponentami zewnętrznymi była podatność w protokole LDAP (Lightweight Directory Access Protocol), załatana w systemie Windows w grudniu 2024 roku. Microsoft opublikował poprawkę usuwającą lukę oznaczoną jako CVE-2024-49112, która umożliwiała nieuwierzytelnionemu, zdalnemu napastnikowi wykonanie poleceń w kontekście usługi LDAP. Atak polegał na przesłaniu specjalnie spreparowanego żądania RPC (Remote Procedure Call) do podatnego serwera, co mogło skutkować pełnym przejęciem kontroli nad systemem. Współczesne aplikacje coraz częściej opierają się na bibliotekach open source — które, choć wygodne i popularne, mogą stanowić potencjalne wektory ataku, jeśli nie są regularnie audytowane ani aktualizowane. Szczególnie niebezpieczne są ataki na łańcuch dostaw (ang. supply chain attacks), polegające na wstrzyknięciu złośliwego kodu do zaufanych zależności. Przykładami takich incydentów są atak na SolarWinds163, w którym złośliwe oprogramowanie trafiło do oficjalnej aktualizacji systemu, czy też słynna podatność Log4Shell (CVE-2021-44228) w bibliotece Log4j.


    Podsumowanie ryzyk związanych z oprogramowaniem zewnętrznym:

    • Używanie bibliotek open source bez audytu lub aktualizacji (np. Log4j – CVE-2021-44228).
    • Podatności wynikające z błędów w integracjach między systemami.
    • Ataki na łańcuch dostaw oprogramowania (supply chain), np. złośliwe aktualizacje.

  5. Ryzyka związane z siecią (Network Risks)
    Testowanie bezpieczeństwa sieci wymaga znajomości protokołów komunikacyjnych, konfiguracji oraz mechanizmów ochronnych, które zabezpieczają transmisję danych. W tej warstwie szczególnie istotne jest wykrywanie luk, które mogą prowadzić do przechwycenia, modyfikacji lub zablokowania komunikacji. Typowe zagrożenia to: Brak szyfrowania transmisji danych (np. brak HTTPS/TLS) — dane przesyłane w postaci niezaszyfro- wanej mogą zostać łatwo przechwycone przez atakujących, np. z wykorzystaniem narzędzi takich jak Wireshark. James Whittaker podkreśla, że brak zabezpieczeń warstwy transportowej (TLS) skutkuje wyciekiem poufnych informacji, takich jak hasła, dane logowania czy dane osobowe. Ataki typu MITM (Man-in-the-Middle) — atakujący, który znajduje się pomiędzy dwoma stronami komunikacji (np. klientem i serwerem), może podsłuchiwać, przechwytywać, a nawet modyfikować przesyłane dane. W książce How to Break Software Security opisano testy takich podatności — m.in. poprzez manipulację certyfikatami SSL lub fałszowanie wpisów DNS. Błędna konfiguracja serwerów lub firewalli — niewłaściwe reguły zapory sieciowej lub brak ograniczeń dostępu do otwartych portów mogą umożliwić atakującym dostęp do wewnętrznych zasobów systemu. Autorzy zalecają weryfikację konfiguracji z wykorzystaniem narzędzi takich jak Nmap. Ataki na protokoły sieciowe (np. SMB, LDAP, RPC) — podatności w implementacjach popularnych protokołów sieciowych mogą umożliwiać atakującym wykonanie złośliwego kodu lub uzyskanie nieau- toryzowanego dostępu. Przykładem jest nadużycie błędów w protokole RPC (Remote Procedure Call). Ataki DDoS (Distributed Denial of Service) — Whittaker zwraca uwagę na ryzyko przeciążenia systemu przez zalewanie serwera dużą liczbą równoczesnych żądań. Odporność na takie ataki można testować, symulując obciążenie i analizując zachowanie systemu pod presją.

References