Podatności Shopper

Shopper, panel administracyjny e-commerce headless, przed wersją 2.8.0 zawiera dwie wady autoryzacji w ustawieniach zespołu. Umożliwiają one każdemu uwierzytelnionemu użytkownikowi przejęcie systemu RBAC, tworzenie nowych ról, usuwanie innych użytkowników (w tym administratorów) oraz eskalację uprawnień do pełnego administratora panelu.

W panelu administracyjnym Shopper (headless e-commerce) przed wersją 2.8.0 wykryto trzy powiązane defekty: brak blokady identyfikatorów modeli Eloquent w komponentach Livewire umożliwiał manipulację danymi, przesyłanie hasła w postaci jawnego tekstu przez ukryte pole formularza prowadziło do ujawnienia wrażliwych danych, a pole kodu kreskowego produktu było renderowane bez odpowiedniego escapingu, co pozwalało na trwałe przechowywanie złośliwego kodu XSS.

Shopper przed wersją 2.8.0 nie sprawdza uprawnień dla akcji włączania/wyłączania, edycji i usuwania w tabelach admina dla PaymentMethods, Currencies i Carriers. Użytkownik z niskimi uprawnieniami może wyłączyć metody płatności, zmienić domyślną walutę lub wyłączyć przewoźników.

Shopper przed wersją 2.8.0 zawiera podatność w komponentach Livewire używanych w edytorze produktów (Edit, Inventory, Seo, Shipping, Files), gdzie metoda store() nie sprawdza autoryzacji. Każdy uwierzytelniony użytkownik może modyfikować ceny, stany magazynowe, metadane SEO, wymiary wysyłki i załączniki dowolnego produktu.

W Shopper, headless e-commerce panelu administracyjnym, przed wersją 2.8.0, funkcja CreateOrderFromCartAction::execute tworzyła zamówienie przed sprawdzeniem i inkrementacją licznika total_use rabatu. Przy współbieżnym obciążeniu (Black Friday, wyprzedaż błyskawiczna, wiralny kupon) globalny limit użycia był cicho przekraczany: zamówienia były zatwierdzane z pełnym rabatem, podczas gdy licznik blokował się na limicie. Sprzedawca nie miał sygnału o nadmiernym wykorzystaniu rabatu.

Shopper, panel administracyjny e-commerce typu Headless, przed wersją 2.8.0 zawiera podatność polegającą na tym, że wiele akcji Filament w szczegółach zamówienia i tabeli wysyłek może być wywoływanych przez uwierzytelnionego użytkownika o niskich uprawnieniach bez wymaganych uprawnień do modyfikacji zamówień. Akcje takie jak anulowanie, oznaczenie jako zapłacone, ukończone, przechwycenie płatności, archiwizacja i rozpoczęcie przetwarzania były dostępne z uprawnieniami tylko do odczytu read_orders, a nie wymaganymi edit_orders. Funkcja capturePayment mogła faktycznie przechwycić środki w systemie płatności. Użytkownik z dostępem tylko do odczytu mógł zmieniać cykl życia każdego zamówienia i inicjować rzeczywiste przechwycenia płatności.