Badania cyberbezpieczeństwa i testy penetracyjne aplikacji webowych w jednym

Przeprowadzanie testów penetracyjnych aplikacji webowych to bardzo dobry sposób na poprawę bezpieczeństwa aplikacji. Najczęściej stosowanym modelem testów penetracyjnych aplikacji webowych jest model typu black box, w którym zespół testujący ma bardzo ograniczoną wiedzę o docelowej aplikacji. Tego typu testy przypominają scenariusz rzeczywistego ataku. Wadą tego podejścia jest to, że zespół testowy musi zgadywać, a raczej enumerować istniejące ścieżki, parametry, strukturę aplikacji i inne elementy, co zazwyczaj wymaga czasu. Dodatkowo, niektóre podatności znajdują się w bardzo głęboko osadzonych częściach kodu źródłowego, które są wykonywane tylko w specyficznych warunkach. Testy penetracyjne typu black box mają bardzo małe szanse na wykrycie takich podatności.

Test penetracyjny typu White Box to rozwiązanie tej niedogodności. Przed rozpoczęciem testów penetracyjnych aplikacji webowej, testerzy mają dostęp do kodu źródłowego aplikacji, dokumentacji, a bardzo często także do systemów operacyjnych, na których działa aplikacja. Dzięki temu zyskują ogromną przewagę nad testami typu black box. Testerzy penetracyjni mogą ekstrahować istniejące endpointy API, parametry, formaty itp., bez konieczności marnowania czasu na uruchamianie narzędzi, które próbują zgadnąć te parametry. Mogą przeglądać logi aplikacji webowej po przeprowadzeniu ataków, co przyspiesza proces eksploatacji. Mają także możliwość przeanalizowania kodu źródłowego, aby w pełni zrozumieć działanie aplikacji i obejść zaimplementowane zabezpieczenia.

Nie każdy zespół przeprowadzający testy penetracyjne aplikacji webowych może wykonać testy penetracyjne typu white box, ponieważ wymaga to znajomości kodu źródłowego, interakcji pomiędzy serwerem webowym a aplikacją, formatu logów i innych aspektów.

Dodatkowo, aplikacje open-source mogą w pełni skorzystać z testów penetracyjnych typu white box, ponieważ kod źródłowy i środowisko testowe są łatwo kontrolowane przez testerów. Nie ma potrzeby przeprowadzania testów penetracyjnych w środowisku produkcyjnym, co eliminuje ryzyko zakłócenia działalności biznesowej.

W tej serii udostępnimy również narzędzie, które wykrywa podatności w aplikacjach CakePHP w sposób, w jaki nie robią tego popularne skanery podatności. Badania i rozwój tego narzędzia zostały zlecone przez Luksemburskie Siły Zbrojne.

Zostań z nami, aby poznać rozwiązanie dedykowane wykrywaniu podatności w aplikacjach CakePHP!

CakePHP jako cel badań z zakresu cyberbezpieczeństwa

W naszych badaniach z zakresu cyberbezpieczeństwa skupimy się na aplikacjach webowych opartych na frameworku CakePHP. Framework aplikacji webowej to zestaw bibliotek, funkcji, klas i wtyczek, które deweloper może wykorzystać prawie od razu, bez konieczności tworzenia ich od podstaw. Może to obejmować kontrolę dostępu, prezentację wyników w różnych formatach, takich jak HTML, JSON, XML, dostęp do bazy danych, zarządzanie sesjami i wiele innych.

Przykłady innych frameworków aplikacji webowych to:

• Laravel
• Symfony
• Java Spring
• Django
• Flask
• .NET MVC

Z oficjalnej strony CakePHP:

CakePHP to framework open-source do szybkiego tworzenia aplikacji webowych, który sprawia, że budowanie aplikacji webowych jest prostsze, szybsze i wymaga mniej kodu.

Na GitHubie CakePHP jest obserwowany przez 560 osób, jest forkkowany 3500 razy i ma ponad 8600 gwiazdek.

Zgodnie z informacjami Cake Software Foundation (https://cakephp.org/showcase), CakePHP jest używany przez organizacje takie jak BMW, Calzedonia, Hyundai i inne.

Ponadto, niektóre popularne aplikacje open-source, takie jak MISP czy PassBolt, zostały zbudowane na bazie frameworka CakePHP.

Aplikacje webowe oparte na frameworku CakePHP są również interesującym celem ze względu na standardowe mechanizmy zabezpieczeń, takie jak black-holing czy ochrona przed CSRF. Te zabezpieczenia znacznie utrudniają pracę skanerów podatności. Muszą być one specjalnie skonfigurowane, aby skanować określone obszary aplikacji, a bardzo często same skanery są blokowane przez te zabezpieczenia.

Wykrywanie aplikacji webowych opartych na CakePHP w testach penetracyjnych

Nie ma niezawodnej metody wykrywania, czy framework stojący za aplikacją webową to CakePHP z 100% dokładnością, stosując podejście czarnej skrzynki. Najlepszym sposobem jest poszukiwanie ciasteczka CAKEPHP, które jest ustawiane przez aplikację:

Jednym ze wskazań na użycie frameworka CakePHP jest struktura URL. CakePHP jest zbudowany przy użyciu wzorca MVC, co często skutkuje tym, że adresy URL są strukturalnie zbudowane w następujący sposób:

Zauważ następujące części rozdzielone ukośnikiem:

• Kontroler
• Akcja
• opcjonalne parametry

Omówię te kwestie w kolejnym artykule.

Czasami aplikacje pozostawiają ślad po użyciu CakePHP, gdy żąda się nieistniejącego kontrolera lub akcji:

Jeśli masz dostęp do kodu źródłowego, łatwo sprawdzisz, czy aplikacja webowa jest zbudowana na CakePHP, przeglądając plik composer.json (jeśli jest używany) lub szukając katalogu cake lub pliku wykonywalnego.

Poniżej znajduje się zrzut ekranu pliku composer.json z projektu Cerebrates:

CakePHP umożliwia deweloperom wykonywanie różnych czynności, takich jak uruchamianie migracji, debugowanie czy aktualizacja z konsoli przy użyciu skryptu wykonywalnego cake. Możesz poszukać tego skryptu, aby sprawdzić, czy Twoja aplikacja jest oparta na frameworku CakePHP. Na serwerze MISP, szybkie wykonanie polecenia „find” pokazuje ścieżkę app/Console/cake:

Na koniec, katalog cakephp powinien wskazywać na kod źródłowy frameworka CakePHP:

Pamiętaj, że te ścieżki mogą się różnić w zależności od aplikacji webowej opartej na CakePHP.

Zrozumienie CakePHP poprzez przeprowadzanie badań nad bezpieczeństwem

Większość przykładów i wyjaśnień oparta jest na aplikacjach webowych zbudowanych w CakePHP 4. Niemniej jednak wciąż istnieją aplikacje webowe, które wykorzystują starsze wersje frameworka CakePHP. Przykładem takiej aplikacji open-source jest MISP.

MISP to rozwiązanie typu open-source służące do zbierania, przechowywania, dystrybuowania i udostępniania wskaźników i zagrożeń związanych z bezpieczeństwem cybernetycznym, które dotyczą analizy incydentów bezpieczeństwa i analizy złośliwego oprogramowania. MISP zostało zaprojektowane przez analityków incydentów oraz specjalistów ds. bezpieczeństwa i ICT, jak również inżynierów zajmujących się dekompilowaniem złośliwego oprogramowania, aby wspierać ich codzienną pracę w efektywnym dzieleniu się usystematyzowanymi informacjami.

Dodatkowo, MISP jest używane przez wiele międzynarodowych organizacji, w tym NATO Communication and Information Agency, FIRST i inne (https://www.misp-project.org/communities/).

Dlatego również podam przykłady związane z wersją CakePHP 2.

Badania nad bezpieczeństwem CakePHP zaczynają się od zrozumienia architektury

Aby przeprowadzić badania nad bezpieczeństwem, zaczniemy od zrozumienia architektury frameworka CakePHP.

Aplikacje webowe oparte na CakePHP budowane są na architekturze MVC, która oznacza Model-View-Controller.

Poniżej możesz zobaczyć schemat przedstawiający przepływ wykonania:

Ta architektura jest bardzo powszechna w aplikacjach webowych, ponieważ dzieli różne grupy kodu na logicznie powiązane warstwy:

– Model odpowiada za komunikację z bazą danych lub innym typem rejestru. Tutaj wykonywane są zapytania SQL lub żądania do magazynów klucz-wartość, takich jak Redis.

– Widok odpowiada za zapewnienie warstwy prezentacji. Kiedy przeglądasz aplikację i widzisz wygenerowany HTML, aplikacja wykonuje to w warstwie Widoku.

– Kontroler odpowiada za większość logiki aplikacji, przetwarzanie danych wejściowych od użytkownika i inne.

Przedstawiam przykładowy przepływ wykonania aplikacji CakePHP:

– Użytkownik wchodzi w interakcję z warstwą widoku aplikacji. Jest to graficzny interfejs użytkownika (GUI) aplikacji.

– Użytkownik klika w link, aby zobaczyć opis danej strony z wiadomościami. Link jest sformułowany w następujący sposób: /news/show/3

– Żądanie strony z wiadomościami trafia do komponentu routera.

– Na podstawie ścieżki URL i metody żądania, router decyduje, który kontroler powinien obsłużyć to żądanie.

– Akcja „show” kontrolera „news” jest wybrana przez router. Router przekazuje kontrolę nad żądaniem do akcji „show” kontrolera „news”.

– Akcja przetwarza żądanie, w tym dane użytkownika, wyciąga identyfikator strony z wiadomościami do wyświetlenia (3) i wysyła żądanie do warstwy modelu w celu pobrania strony z wiadomościami o id=3 z bazy danych.

– Model łączy się z bazą danych, wyciąga stronę z wiadomościami z bazy danych i wysyła przetworzoną odpowiedź z powrotem do kontrolera.

– Warstwa kontrolera, nadal w ramach akcji „show”, analizuje odpowiedź z bazy danych i przekazuje odpowiednie dane do warstwy widoku.

– Warstwa widoku ładuje odpowiedni szablon dla akcji „show” kontrolera „news”, wypełnia go danymi z kontrolera i wysyła odpowiedź z powrotem do użytkownika.

Framework CakePHP domyślnie implementuje akcje CRUD (tworzenie, odczyt, aktualizacja, usuwanie). Domyślne nazwy tych akcji w kontrolerach to: view, add, edit, delete. Jeśli akcja nie jest wykryta w URL, przyjmuje się domyślną akcję „index”.

Z perspektywy bezpieczeństwa, istnieje kilka kluczowych uwag związanych z tą strukturą. Jeśli szukasz podatności, które celują w front-end aplikacji webowej, skup się na warstwie Widoku aplikacji CakePHP. Mogą to być na przykład podatności XSS.

Jeśli szukasz podatności typu SQL injection, bardziej prawdopodobne jest, że taka podatność znajduje się w warstwie Modelu.

Na końcu, warstwa Kontrolera jest głównym miejscem, w którym aplikacja zaczyna przetwarzać dane wejściowe od użytkownika.

Pamiętaj, że te podatności mogą występować również w innych komponentach. Istnieje możliwość, że znajdziesz podatności SQL injection w Kontrolerze lub innych komponentach.

Katalogi CakePHP, na których powinieneś się skupić podczas testów penetracyjnych aplikacji webowych

Aplikacje napisane w CakePHP zazwyczaj stosują określoną strukturę katalogów. W głównym katalogu aplikacji CakePHP znajdziesz takie foldery jak:

• bin
• config
• logs
• tmp

Większość z tych katalogów nie zawiera istotnych informacji z perspektywy bezpieczeństwa.

Oto kilka konkretnych plików, które mogą być interesujące:

• /config/routes.php – Zawiera zdefiniowane trasy do aplikacji. Trasy odpowiadają ścieżkom URL, które aplikacja może obsługiwać, a czasami wskazują, jaki typ middleware jest powiązany z daną trasą lub grupą tras.
• /logs – Jeśli przeprowadzasz testy penetracyjne typu white box, powinieneś monitorować pliki dzienników w tym katalogu i szukać interesujących błędów lub ostrzeżeń, które mogą wskazywać, że Twoje ataki lub skany uruchomiły podatne fragmenty kodu.
• /plugins – Wtyczki to predefiniowane kontrolery, modele i widoki, które są wykorzystywane przez różne projekty. Wtyczki mogą być opracowane przez ten sam zespół, który rozwija aplikację webową, lub mogą pochodzić z publicznych wtyczek importowanych ze społeczności. Warto zbadać ten katalog w sposób podobny do tego, jak badamy modele, widoki i kontrolery (opisane poniżej).
• /templates – Pliki te stanowią rdzeń warstwy prezentacji aplikacji. Należy je zbadać głównie pod kątem podatności front-endowych, takich jak XSS.
• /webroot – Pliki w tym katalogu są dostępne przez URL. Wyjątkiem są pliki chronione przez serwer WWW, takie jak pliki .htaccess w Apache. Możesz znaleźć tu niektóre pliki statyczne, które warto zbadać, takie jak pliki JavaScript.

Jednakże, rozważając aspekty bezpieczeństwa, należy skupić się na katalogu, który zawiera pliki aplikacji webowej, które prawie zawsze są częścią procesu wykonania aplikacji. W wersjach CakePHP 3 i 4 ten katalog nazywa się src, a w wersji CakePHP 2 – app. Ten katalog i wszystkie jego podkatalogi (z kilkoma wyjątkami) zawierają rdzeń kodu źródłowego aplikacji, który został stworzony specjalnie w celu realizacji funkcji, jakie aplikacja ma pełnić. Oznacza to, że zewnętrzne biblioteki, komponenty lub rozszerzenia napisane przez inne zespoły, dostawców lub konserwatorów zwykle nie znajdują się w katalogu src lub app.

Jeśli chcesz lepiej zrozumieć strukturę katalogów, zapoznaj się z jednym z poniższych zasobów:

• Struktura katalogów CakePHP wersja 4
• Struktura katalogów CakePHP wersja 3
• Struktura katalogów CakePHP wersja 2

Poniżej przedstawiam przykład struktury katalogów dla PassBolt API:

Niektóre z tych katalogów są specyficzne dla danej aplikacji. Możesz ich nie znaleźć w innych aplikacjach CakePHP.

Oto wyjaśnienie katalogów wspólnych dla wszystkich aplikacji CakePHP:

Command	Administratorzy aplikacji CakePHP mogą uruchamiać polecenia Cake na systemie operacyjnym, na którym hostowana jest aplikacja webowa. Przykładem może być wykonanie migracji wymaganych do początkowej konfiguracji bazy danych. Framework CakePHP dostarcza zestaw domyślnych poleceń, ale deweloperzy mogą rozszerzać ten zestaw, dodając własne polecenia. Kod logiki stojącej za tymi poleceniami jest przechowywany w katalogu Command. Ponieważ są one wykonywane tylko z poziomu wiersza poleceń, z perspektywy bezpieczeństwa rzadko budzą zainteresowanie, ponieważ główny wektor ataku przebiega przez aplikację webową.
Console	Zawiera kod związany z procesem instalacji lub konfiguracji aplikacji webowej. Ten kod również jest wykonywany z poziomu wiersza poleceń, dlatego nie jest dla nas interesujący.
Controller	To główna logika aplikacji, w której zachodzi wiele „magii”. Znajdziesz tutaj kilka kontrolerów, z których każdy ma swoje akcje. Para kontroler-akcja odpowiada określonemu ścieżce w aplikacji, na przykład /users/index. W tym przypadku kontroler to users, który odpowiada plikowi UsersController.php, a akcja to index, która odpowiada metodzie index w pliku kontrolera (możesz znaleźć metodę index, wyszukując coś w stylu: public function index()). Niektóre kontrolery będą dziedziczyć akcje od innych. Ten katalog jest zdecydowanie bardzo ważny w kontekście badań bezpieczeństwa lub testów penetracyjnych typu white box aplikacji opartych na CakePHP.
Middleware	Ten katalog zawiera klasy, które są używane w różnych miejscach kodu. Mogą być wykorzystywane przez router CakePHP, niektóre kontrolery, modele lub inne komponenty. Przykładem middleware jest klasa ochrony przed CSRF, która jest w stanie generować nowe tokeny, wyłączać ochronę CSRF dla niektórych żądań, takich jak API, oraz sprawdzać, czy przekazany przez użytkownika token CSRF jest poprawny. Ten katalog jest również interesujący z perspektywy bezpieczeństwa, ponieważ jest używany w kilku miejscach aplikacji. Zwykle nie zawiera dużo kodu, więc analiza kodu w tym katalogu może prowadzić do obejścia wdrożonych ochron.
Model	Ten katalog zawiera kod źródłowy komunikujący się z bazą danych, takie jak definicje schematów, zachowania związane z bazą danych i inne. Warto skupić się na podatnościach związanych z bazą danych, takich jak SQL injection, podczas przeglądania kodu w tym katalogu.
Shell	Są to zazwyczaj wielokrotnego użytku klasy, wykorzystywane przez akcje wiersza poleceń. Ponieważ są one głównie związane z aplikacjami działającymi w konsoli, rzadko stanowią punkt zainteresowania w testach penetracyjnych typu white box.
View	Katalog zawierający klasy warstwy prezentacji. Choć można tam znaleźć pewne podatności związane z front-endem, zazwyczaj pełni on drugorzędną rolę jako „pomocnik” dla front-endu.

CakePHP jest zbudowany zgodnie z zasadą konwencji zamiast konfiguracji. To znacznie ułatwia zrozumienie aplikacji, ponieważ wiele nazw plików, klas, metod itd. jest standaryzowanych i zazwyczaj opisowych.

Badania bezpieczeństwa aplikacji open-source

Chcesz wspierać inicjatywę open-source, poprawiając jej bezpieczeństwo?

Korzystasz z projektu open-source i chcesz zweryfikować jego bezpieczeństwo?

Badania bezpieczeństwa projektu open-source znacząco poprawią jego bezpieczeństwo.