Podatności Part-DB

Part-DB przed wersją 2.13.3 buduje bezwzględny URL linku do resetowania hasła na podstawie nagłówka HTTP Host dostarczonego przez klienta, bez walidacji zaufanego hosta. Nieuwierzytelniony atakujący może wysłać żądanie resetu hasła dla znanego konta ze sfałszowanym nagłówkiem Host, powodując wysłanie linku z hostem kontrolowanym przez atakującego, ale z prawdziwym tokenem resetowania. Gdy ofiara otworzy link (lub zrobi to skaner poczty), token wycieka do atakującego, który może przejąć konto, w tym konto administratora.

Part-DB przed wersją 2.13.2 zawiera podatność na wstrzyknięcie formuł arkusza kalkulacyjnego w procesie importu/eksportu części. Uwierzytelniony użytkownik z uprawnieniami do importu może zaimportować plik CSV zawierający wartości z prefiksem formuły, takie jak =1+1, do kontrolowanych pól części. Gdy część zostanie wyeksportowana jako arkusz XLSX, Part-DB zapisuje wartość za pomocą setCellValue() bez neutralizacji znaków formuły, co może spowodować wykonanie formuły przez oprogramowanie arkusza kalkulacyjnego innego użytkownika.

Part-DB przed wersją 2.13.2 pozwala uwierzytelnionym użytkownikom API obejść skonfigurowany maksymalny rozmiar załącznika, przesyłając załączniki przez API z danymi pliku zakodowanymi w base64. Aplikacja egzekwuje limit rozmiaru dla zwykłych przesyłań przez przeglądarkę, ale ścieżka API base64 nie stosuje tej samej walidacji. W rezultacie użytkownik z dostępem do API i uprawnieniami do tworzenia załączników może przesłać pliki większe niż limit, potencjalnie wyczerpując miejsce na dysku i powodując odmowę usługi.

Part-DB przed wersją 2.13.2 pozwala uwierzytelnionym użytkownikom obejść skonfigurowany maksymalny rozmiar załącznika podczas korzystania z funkcji „Download external file” po stronie serwera. Gdy pobieranie załączników po stronie serwera jest włączone, Part-DB pobiera zdalny plik i strumieniuje go bezpośrednio na dysk bez egzekwowania limitu MAX_ATTACHMENT_FILE_SIZE. W rezultacie użytkownik z uprawnieniami do tworzenia lub edycji załączników może spowodować przechowywanie plików większych niż limit, potencjalnie wyczerpując miejsce na dysku i powodując odmowę usługi.

Part-DB przed wersją 2.12.3 sanityzuje pliki SVG wyłącznie na podstawie rozszerzenia nazwy pliku kontrolowanego przez użytkownika, a nie rzeczywistego typu zawartości. Uwierzytelniony atakujący może przesłać złośliwy plik SVG z ładunkiem JavaScript podając inne rozszerzenie (np. .jpg), całkowicie omijając sanityzację. Gdy dowolny użytkownik wyświetli załącznik inline, przeglądarka otrzyma Content-Type: image/svg+xml i wykona osadzony skrypt w kontekście Part-DB.

W Part-DB przed wersją 2.12.2 komunikaty walidacji BOM są renderowane z użyciem filtra |raw w Twig, a zawierają placeholdery wypełniane nazwami części kontrolowanymi przez użytkownika. Użytkownik mogący edytować nazwę części może zapisać znaczniki HTML, które zostaną wyrenderowane na stronie wyników walidacji BOM innego użytkownika, co prowadzi do przechowywanego wstrzyknięcia HTML.

W Part-DB przed wersją 2.12.1 plik .env w repozytorium zawiera stałą wartość APP_SECRET, której oficjalny obraz Docker jbtronics/part-db1 nie nadpisuje ani nie losuje przy starcie kontenera. Symfony używa APP_SECRET jako klucza HMAC do podpisywania ciasteczek remember-me, więc atakujący znający ten sekret może sfałszować ciasteczko remember-me dowolnego użytkownika i uzyskać w pełni uwierzytelnioną sesję bez poświadczeń.

W Part-DB, systemie zarządzania inwentarzem komponentów elektronicznych, w wersjach przed 2.12.1 występuje podatność typu stored XSS. Klasa LogEntryExtraFormatter w gałęzi CollectionElementDeleted wstawia nazwę usuniętego pod-elementu (getOldName(), getCollectionName()) do HTML bez użycia htmlspecialchars(), co pozwala użytkownikowi z niskimi uprawnieniami zapisać złośliwy kod HTML/JS jako nazwę pod-elementu, a następnie wywołać jego wykonanie w przeglądarce administratora lub audytora przeglądającego dziennik aktywności lub historię elementu.

W Part-DB przed wersją 2.12.1 mechanizm blokowania niebezpiecznych rozszerzeń przy przesyłaniu załączników nie obejmuje rozszerzenia .phar. Plik .phar przesłany jako załącznik trafia do katalogu public/media/, który jest dokument root Apache, a konfiguracja Apache kieruje .phar do PHP-FPM, co pozwala na wykonanie dowolnego kodu PHP.