POPULARNE APLIKACJE

Wykrycie luki w zabezpieczeniach aplikacji webowej pozwala na próby jej wykorzystania często bez konieczności uzyskiwania dodatkowego uwierzytelnienia. Aplikacja pracująca w strefie DMZ bez ochrony WAF czy IPS jest obecnie podobna do kaczki na polu pełnym myśliwych. Jeżeli kaczek jest więcej, może mieć szczęście i nic złego się nie wydarzy. Jednak w środowisku tak nieprzyjaznym jak Internet nie liczyłbym tylko na szczęście. Aplikacje webowe są tego dowodem również ze względu na dynamiczny rozwój właśnie tego rodzaju rozwiązań opartych o obsługę za pomocą przeglądarki WWW.

W celu zwiększenia bezpieczeństwa aplikacji webowych opracowano metody ich tworzenia oraz testowania. Open Web Application Security Project (OWASP) jest najbardziej rozpoznawalnym standardem w zakresie bezpieczeństwa aplikacji webowych. Metodologia pomaga ograniczyć podatności w aplikacjach, a najbardziej znana jest z publikacji OWASP Top 10. To standardowy dokument informacyjny dla programistów i testerów bezpieczeństwa aplikacji internetowych. Top 10 Web Application Security Risks zawiera informacje o najważniejszych kategoriach ryzyka oznaczonych w obecnej wersji od A01:2021 do A10:2021.

TOP 10 OWASP

  • A01:2021 – Broken Access Control. Kontrola dostępu wymusza zasady, dzięki którym użytkownicy nie mogą działać poza zamierzonymi uprawnieniami. Błędy zazwyczaj prowadzą do nieuprawnionego ujawnienia informacji, modyfikacji lub zniszczenia wszystkich danych lub wykonywania funkcji poza ograniczeniami nakładanymi na użytkownika.
  • A02:2021 – Cryptographic Failures. Pierwszą rzeczą jest określenie potrzeb w zakresie ochrony danych w tranzycie i w spoczynku. Na przykład hasła, numery kart kredytowych, dokumentacja medyczna, dane osobowe i tajemnice handlowe wymagają dodatkowej ochrony, głównie jeśli dane te podlegają przepisom dotyczącym prywatności.
  • A03:2021 – Injection. Aplikacja jest podatna na atak, gdy np. dane dostarczone przez użytkownika nie są sprawdzane, filtrowane ani oczyszczane przez aplikację.
  • A04:2021 – Insecure Design. To szeroka kategoria reprezentująca różne słabości, wyrażona jako „brakujący lub nieskuteczny projekt zabezpieczeń”. Rozróżniamy wady projektowe i wady wdrożenia, mają one różne przyczyny źródłowe i środki zaradcze. Bezpieczny projekt może nadal mieć wady implementacji prowadzące do luk, które można wykorzystać.
  • A05:2021 – Security Misconfiguration. Problem występuje gdy aplikacja np. posiada nieprawidłowo skonfigurowane uprawnienia w usługach w chmurze lub ma włączone lub zainstalowane niepotrzebne funkcje (np. niepotrzebne porty, usługi, strony, konta lub uprawnienia).
  • A06:2021 – Vulnerable and Outdated Components. Podatność występuje gdy np. nie znamy wersji wszystkich używanych składników (zarówno po stronie klienta, jak i po stronie serwera) lub jeśli oprogramowanie jest podatne na ataki, nieobsługiwane lub nieaktualne.
  • A07:2021 – Identification and Authentication Failures. Potwierdzenie tożsamości użytkownika, uwierzytelnianie i zarządzanie sesjami ma kluczowe znaczenie dla ochrony przed atakami związanymi z uwierzytelnianiem.
  • A08:2021 – Software and Data Integrity Failures. Przykładem jest sytuacja, w której aplikacja opiera się na wtyczkach, bibliotekach lub modułach z niezaufanych źródeł, repozytoriów i sieci dostarczania treści. Niezabezpieczony CI/CD może stwarzać ryzyko nieautoryzowanego dostępu, złośliwego kodu lub naruszenia bezpieczeństwa systemu.
  • A09:2021 – Security Logging and Monitoring Failures. Wykrywanie, eskalacja i reagowania na aktywne naruszenia. Bez logowania i monitorowania nie można wykryć naruszeń.
  • 10:2021 – Server-Side Request Forgery. Tego typu błędy występują, gdy aplikacja internetowa pobiera dane ze zdalnego zasobu bez sprawdzania poprawności adresu URL podanego przez użytkownika. Umożliwia atakującemu zmuszenie aplikacji do wysłania spreparowanego żądania do nieoczekiwanego miejsca docelowego.

Na stronie https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools można zapoznać się z wieloma narzędziami, które wspierają tworzenie i testowania bezpiecznego oprogramowania. Publikowane na stronach OWASP narzędzia wspierają testowanie SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing) jak i IAST (Interactive Application Security Testing). Wykorzystanie tych narzędzi w metodologii OWASP może nie tylko zidentyfikować podatności często występujące w aplikacjach internetowych i mobilnych, ale także skomplikowane błędy logiczne, które wynikają z niebezpiecznych praktyk programistycznych. Zaktualizowany przewodnik zawiera kompleksowe wytyczne dla każdej metody testowania penetracyjnego z łącznie ponad 66 kryteriami pozwalającymi na  ocenę bezpieczeństwa. Szeroka gama funkcji występujących obecnie w nowoczesnych aplikacjach oraz kryteria oceny OWASP pozwalają testerom zidentyfikować luki w bezpieczeństwie i ocenić ich powagę. Dzięki tej metodologii można minimalizować ryzyko występowania typowych błędów, które mogą mieć potencjalnie krytyczny wpływ na działanie aplikacji. OWASP zaleca organizacjom chcących tworzyć nowe aplikacje internetowe i mobilne stosowanie takiego standardu na etapie tworzenia oprogramowania w celu unikania typowych podatności w zabezpieczeniach aplikacji. Stosowanie standardu OWASP do oceny bezpieczeństwa aplikacji zapewnia minimalizację ryzyka występowania podatności w aplikacjach, a testerom pozwala ocenić poziom bezpieczeństwa i możliwości realizacji ataku przy wykorzystaniu wykrytej podatności.

ŁATANIE SYSTEMÓW

Proces zarządzania podatnościami powinien uwzględniać odniesienie do środowiska, w którym funkcjonuje zasób obarczony podatnością oraz różnice pomiędzy wynikami otrzymywanymi z wykorzystaniem skali CVSS 2.0 a CVSS 3.1. Należy również uwzględnić konieczność szybkiego uzyskania prawidłowych wyników niezbędnych do ustalenia priorytetów dla wykrytych podatności. Do tego celu używamy odpowiednich narzędzi służących do skanowania, jednak równie ważne jest uzyskiwanie informacji o podatnościach z innych źródeł. Jednym z nich jest baza NVD CVE czy MITRE CWE, a kolejnym producenci sprzętu i oprogramowania. W odniesieniu do zarządzanego środowiska IT najczęściej jednak stosujemy tzw. patch management, czyli zarządzanie wydawanymi przez vendorów poprawkami i ulepszeniami.

Zarządzanie poprawkami to proces używany do aktualizowania oprogramowania, systemów operacyjnych i aplikacji. Celem systemu zarządzania poprawkami jest wyróżnianie, klasyfikacja i priorytetyzacja brakujących poprawek w zasobach środowiska IT. Patche są aktualizacjami od dostawcy, a mogą zawierać wszystko – od poprawek bezpieczeństwa po nowe funkcje. Dostawca ustala zasady dotyczące tego, co może znajdować się w poprawce, a także powinien dokumentować wszystkie zmiany i dodatki. Nie wszystkie patche zawierają poprawki zabezpieczeń i nie wszystkie poprawki rozwiązują problemy dotyczące zabezpieczeń. Zarządzanie podatnościami to proces, który wykrywa zasoby w sieci, kategoryzuje system operacyjny i aplikacje w zasobach oraz raportuje luki w zabezpieczeniach systemów docelowych. Narzędzia do zarządzania lukami w zabezpieczeniach skanują zasób i zgłaszają znane wykryte luki wraz ze wskazaniem działań naprawczych.

TESTOWANIE ZABEZPIECZEŃ

Biorąc pod uwagę liczbę luk w aplikacjach i problemów z konfiguracją, proces testowania zabezpieczeń nabiera na znaczeniu. Właściwe zarządzanie podatnościami i regularne potwierdzanie szczelności zabezpieczeń za pomocą testów powinny stać się praktyką wykonywaną równie regularnie jak np. przeglądanie logów.

Testowanie zabezpieczeń dzielimy na takie etapy jak zbieranie informacji o testowanych celach, a następnie skanowanie i rozpoznanie celu oraz stosowanej ochrony. Kolejnym krokiem jest skanowanie w celu wykrycia możliwych do wykorzystania podatności. Dalsze kroki są zazwyczaj bardziej inwazyjne. Znając podatności aplikacji i słabości systemu zabezpieczeń, możemy próbować włamać się do systemu postępując podobnie jak potencjalny intruz. Taka metoda potwierdzająca możliwość przeprowadzenia ataku na środowisko IT najlepiej wskazuje jaki może być jego zasięg i wpływ na organizację.

Testowanie systemów przechowujących i chroniących dane jest obecnie nie tylko dobrą praktyką, ale wymogiem stawianym skutecznym systemom bezpieczeństwa. Stosowana infrastruktura sieciowa jest tak różnorodna, że podczas testów powinny zostać zidentyfikowane elementy, które powinny zostać dodatkowo uruchomione lub ich konfiguracja powinna być poprawiona. Często okazuje się, że organizacja korzysta już z wielu zabezpieczeń, które do tej pory nie były właściwie wykorzystywane.

Autor: Artur Cieślik