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.

Shopper to headless panel administracyjny e-commerce. W wersji przed 2.10.1 trasa szczegółów klienta /cpanel/customers/{user}/show sprawdza uprawnienie read_customers, ale wyszukuje dowolny identyfikator użytkownika bez zastosowania zakresu roli customers używanego na liście. Uwierzytelniony personel z access_dashboard i read_customers może zmienić ID użytkownika, aby uzyskać profile administratorów lub personelu, mimo braku view_users. Luka ujawnia dane profilu i umożliwia enumerację ID użytkowników; w połączeniu z delete_customers może umożliwić destrukcyjne działania wobec kont niebędących klientami. Problem naprawiono w wersji 2.10.1.

Podatność typu stored XSS w panelu administracyjnym Shopper pozwala uwierzytelnionemu pracownikowi z uprawnieniami do przesyłania treści na zapisanie wykonywalnych plików HTML lub SVG, które są serwowane bez nagłówka Content-Disposition i CSP. Gdy administrator otworzy taki plik, złośliwy skrypt wykonuje się w jego sesji i może utworzyć nowe konto administratora z wybranym hasłem. Problem dotyczy wersji 2.0.0–2.10.0 oraz 3.0.0-beta.1 i beta.2; naprawiono w 2.10.1 i 3.0.0-beta.3.

W Shopper przed wersją 2.10.0 komponent Livewire Variants w packages/admin/src/Livewire/Components/Products/Form/Variants.php udostępnia DeleteAction i DeleteBulkAction bez autoryzacji po stronie serwera. Uwierzytelniony pracownik z uprawnieniem edit_products może uzyskać podpisany stan komponentu i trwale usuwać pojedyncze lub wiele wariantów bez uprawnienia delete_product_variants. Może to zniszczyć katalog produktów i zakłócić działanie sklepu, koszyka i finalizacji zamówień. Problem naprawiono w wersji 2.10.0.

Shopper to headless panel administracyjny e-commerce. Od wersji 2.8.0 do 2.8.1 trzy komponenty Livewire zachowują luki w autoryzacji: pracownik z uprawnieniami tylko `view_users` i `access_dashboard` może zmieniać uprawnienia, tworzyć administratora lub usuwać role. Może nadać dowolne uprawnienia, w tym `access_setting` własnej roli, utworzyć wstępnie zweryfikowanego administratora z wybranym hasłem lub usunąć role, co umożliwia eskalację uprawnień i denial of service w RBAC.

W aplikacji Shopper od wersji 2.0.0 do 2.6.0 występuje brak autoryzacji, który pozwala użytkownikom panelu administracyjnego z uprawnieniem `access_dashboard` na tworzenie administratorów i nadawanie uprawnień. Atakujący mogą wywołać `CreateTeamMember::store()` lub `Permissions::togglePermission()` bezpośrednio przez `/livewire/update`, aby utworzyć konta administratorów i eskalować uprawnienia.

W panelu administracyjnym Shopper (Headless e-commerce Admin Panel) w wersjach od 2.0.0 do 2.9.2 uwierzytelnieni użytkownicy z uprawnieniem access_setting mogli wywołać destrukcyjne akcje przez endpoint Livewire, ponieważ komponenty ustawień stref wysyłki, stref podatkowych i stawek podatkowych nie egzekwowały autoryzacji usuwania po stronie serwera. Możliwe było usunięcie opcji przewoźników, stref wysyłki, stref podatkowych oraz stawek podatkowych. Problem naprawiono w wersji 2.9.2.

Shopper to headlessowy panel administracyjny e-commerce. W wersjach przed 2.9.0 interfejs administracyjny /cpanel/discounts akceptuje ujemne wartości rabatu fixed_amount, zapisuje je w sh_discounts i przekazuje przez DiscountCalculator.php oraz Calculate.php bez wymuszenia dodatniej wartości. Ponieważ obliczenia odejmują discountTotal od sumy częściowej, ujemny rabat zwiększa końcową wartość zamówienia zamiast ją zmniejszać.

Shopper to headlessowy panel administracyjny e-commerce. W wersjach przed 2.9.2 wcześniejsza zmiana wzmacniająca podformularz produktu pozostawiła metodę store() w Media.php bez sprawdzenia autoryzacji edit_products używanego przez inne podformularze. Uwierzytelniony pracownik z uprawnieniem browse_products może wywołać akcję Livewire store i zastąpić miniaturę oraz obrazy galerii produktu, którego komponent Media został zainicjowany, nawet bez uprawnienia do edycji produktu.

W Shopper przed wersją 2.9.2 plik packages/admin/src/Livewire/Components/Products/VariantStock.php udostępnia stockAction() bez autoryzacji edit_product_variants i pozostawia public $variant mutowalnym po stronie klienta, ponieważ brakuje atrybutu Livewire Locked. Każdy uwierzytelniony użytkownik panelu administracyjnego, w tym personel z uprawnieniem tylko browse_products, może wybrać dowolny wariant produktu i lokalizację magazynu poprzez stan komponentu, a następnie przesłać dodatnią lub ujemną korektę ilości. Pozwala to personelowi z uprawnieniem tylko przeglądania zawyżać stany magazynowe, zmniejszać je lub wymuszać stany wyprzedania dla wariantów spoza bieżącej strony. Problem naprawiono w wersji 2.9.2.

W Shopper przed wersją 2.9.2 akcje grupowe groupedBulkActions w plikach packages/admin/src/Livewire/Pages/Attribute/Browse.php, Tag/Index.php, Brand/Index.php, Category/Index.php i Supplier/Index.php pomijają autoryzację po stronie serwera, podczas gdy strony wymagają jedynie uprawnień browse_attributes, browse_tags, browse_brands, browse_categories lub browse_suppliers. Użytkownik personelu z uprawnieniem tylko przeglądania może wywołać DeleteBulkAction, aby masowo usuwać atrybuty lub tagi, oraz BulkAction::make('enabled') lub BulkAction::make('disabled'), aby zmieniać widoczność atrybutów, marek, kategorii lub dostawców. Operacje te mogą zepsuć warianty produktów i poważnie zakłócić widoczność katalogu sklepu. Problem naprawiono w wersji 2.9.2.

W Shopper przed wersją 2.9.2 plik packages/admin/src/Livewire/Components/Collection/CollectionProducts.php udostępnia Action::make('delete') i DeleteBulkAction::make() bez autoryzacji delete_collections, a public Collection $collection pozostaje mutowalny po stronie klienta, ponieważ brakuje atrybutu Livewire Locked. Uwierzytelniony użytkownik personelu z uprawnieniem tylko browse_collections może wywołać akcję usuwania Livewire, podstawić dowolny identyfikator kolekcji i odłączyć wybrane produkty lub opróżnić kolekcję. Może to zakłócić działanie stron docelowych katalogu i promocji powiązanych z docelową kolekcją. Problem naprawiono w wersji 2.9.2.

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.