Podatności Balbooa Forms

W rozszerzeniu Joomla Balbooa Forms w wersjach poniżej 2.4.3.4 występuje zdalne wykonanie kodu (RCE) bez uwierzytelnienia poprzez wstrzyknięcie shortcode pola. Komponent obsługuje kod PHP zdefiniowany przez administratora, uruchamiany po publicznym wysłaniu formularza, i przed wywołaniem eval() zastępuje shortcody surowymi wartościami przesłanymi przez odwiedzającego. Aby wykorzystać podatność, publiczny formularz musi używać opcjonalnej akcji PHP po wysłaniu i interpolować shortcode kontrolowany przez atakującego w ciągu PHP w podwójnych cudzysłowach.

Rozszerzenie Joomla Balbooa Forms przed wersją 2.4.3.4 ma podatność na przechowywany XSS przez nazwę pliku uploadu bez uwierzytelnienia. Publiczny endpoint uploadu waliduje rozszerzenie pliku i wykryty typ MIME, ale przechowuje oryginalną nazwę pliku z multipart dokładnie w `#__baforms_submissions_attachments.name`. Późniejsza anonimowa submisja formularza kojarzy ten tymczasowy załącznik z nowo utworzoną submisją. Gdy administrator otwiera submisję, JavaScript komponentu pobiera zapisany rekord załącznika i konkatenuje `file.name` bezpośrednio do stringa HTML. Cały string jest przypisywany do `innerHTML`.

W rozszerzeniu Joomla Balbooa Forms w wersjach poniżej 2.4.3.2 występuje wstrzyknięcie kodu PHP przed uwierzytelnieniem. Opcjonalny handler PHP uruchamiany po wysłaniu formularza jest wykonywany przez eval(), a shortcode [URL parameter = X] jest zastępowany surową, nieescapowaną wartością parametru zapytania, co pozwala nieuwierzytelnionemu atakującemu wstrzyknąć dowolny kod PHP wykonywany po stronie serwera. Token CSRF potrzebny do wywołania endpointu jest ujawniany anonimowo przez osobne zadanie, więc nie stanowi realnej ochrony.

Rozszerzenie Joomla Balbooa Forms w wersji poniżej 2.4.3 zawiera podatność na zdalne wykonanie kodu bez uwierzytelnienia. Niezabezpieczona logika przetwarzania formularzy umożliwia wykonanie kodu dla formularzy zawierających pole typu podpis.

Rozszerzenie Joomla Balbooa Forms przed wersją 2.4.3.4 ma podatność na path traversal bez uwierzytelnienia, umożliwiającą eksfiltrację lokalnych plików przez załączniki w automatycznej odpowiedzi. Podczas publicznego przesyłania formularza, stan pola upload jest akceptowany jako JSON kontrolowany przez gościa. Dla każdego obiektu, którego 'id' wygląda numerycznie, komponent ufa dostarczonemu 'filename', konkatenuje go poniżej skonfigurowanego katalogu upload i dodaje wynik do tablicy lokalnych ścieżek załączników. Nie ładuje powiązanego rekordu, nie weryfikuje własności/sesji/formularza/pola, nie wymaga istnienia ID, nie kanonizuje ścieżki ani nie egzekwuje ograniczeń. Jeśli opcje 'auto reply' i 'attach uploaded files' są włączone, komponent wysyła te lokalne ścieżki jako załączniki e-mail na adres podany w polu e-mail. Gość może więc przesłać nieistniejący numeryczny ID oraz nazwę pliku z traversal, np. '../../../../configuration.php', i otrzymać dowolny plik czytelny przez proces Joomla.

W rozszerzeniu Balbooa Forms w wersji poniżej 2.4.3.4 występuje manipulacja metadanymi plików. Końcowe przetwarzanie zgłoszenia formularza przetwarza tablice JSON dla każdego pola przesłania, sprawdzając jedynie, czy identyfikatory są numeryczne. Nazwy plików i nazwy wyświetlane dostarczone przez klienta są bezpośrednio zaufane, co wprowadza ryzyko przejęcia między sesjami, manipulacji metadanymi i podatności na path traversal (np. poprzez getFilePath()).

W rozszerzeniu Balbooa Forms dla Joomla (wersje poniżej 2.4.3.4) publiczna akcja removeTmpAttachment przyjmuje identyfikator załącznika i usuwa odpowiadający wiersz w bazie danych oraz plik. Kontroler weryfikuje token sesji Joomla, ale model nie wiąże identyfikatora załącznika z sesją, która przesłała plik, bieżącym użytkownikiem, formularzem ani stanem tymczasowym, co pozwala dowolnemu gościowi na nieautoryzowane usunięcie załącznika.

Rozszerzenie Joomla Balbooa Forms w wersjach przed 2.4.3.2 zawiera podatność na manipulację kwotą płatności przed autoryzacją. Endpointy stripeCharges i payAuthorize przyjmują całkowitą kwotę z parametru kontrolowanego przez klienta i przekazują ją do bramki płatności bez ponownego przeliczenia na podstawie skonfigurowanych cen produktów. Endpointy nie wymuszają uwierzytelnienia ani kontroli CSRF. Nieuwierzytelniony atakujący może kupić dowolny produkt za dowolną kwotę (np. 0,01 USD) oraz sfałszować pozycje, ilości i koszty wysyłki.