W otwartej platformie do organizacji e-commerce , co zajmuje około rynek systemów do tworzenia sklepów internetowych, podatności, których połączenie pozwala na przeprowadzenie ataku w celu wykonania kodu na serwerze, przejęcia pełnej kontroli nad sklepem internetowym oraz zorganizowania przekierowania płatności. Luki w Magento wydano wersje 2.3.2, 2.2.9 i 2.1.18, które łącznie naprawiły 75 problemów związanych z bezpieczeństwem.
Jeden problem pozwala nieuwierzytelnionemu użytkownikowi na umieszczenie kodu JavaScript (XSS), który można wykonać podczas przeglądania historii anulowanych zakupów w interfejsie administratora. Istotą luki jest możliwość ominięcia operacji czyszczenia tekstu przy pomocy funkcji escapeHtmlWithLinks() podczas przetwarzania notatki w formularzu anulowania na ekranie kasy (za pomocą znacznika „a href=http://onmouseover=…” zagnieżdżone w innym tagu). Problem pojawia się przy korzystaniu z wbudowanego modułu Authorize.Net, który służy do akceptowania płatności kartami kredytowymi.
Aby uzyskać pełną kontrolę za pomocą kodu JavaScript w kontekście bieżącej sesji pracownika sklepu, wykorzystywana jest druga podatność, która pozwala załadować plik phar pod przykrywką obrazu ( „deserializacja Phara”). Plik Phar można przesłać za pomocą formularza wstawiania obrazu we wbudowanym edytorze WYSIWYG. Po wykonaniu kodu PHP atakujący może zmienić szczegóły płatności lub przechwycić dane karty kredytowej klienta.
Co ciekawe, informacja o problemie XSS została wysłana do twórców Magento już we wrześniu 2018 roku, po czym pod koniec listopada wypuszczono łatkę, która jak się okazało eliminuje tylko jeden ze szczególnych przypadków i jest łatwa do obejścia. W styczniu dodatkowo zgłoszono możliwość pobrania pliku Phar pod przykrywką obrazu i pokazano, w jaki sposób można wykorzystać kombinację dwóch luk do włamania się do sklepów internetowych. Pod koniec marca w Magento 2.3.1,
W wersjach 2.2.8 i 2.1.17 naprawiono problem z plikami Phar, ale zapomniałem o poprawce XSS, mimo że zgłoszenie problemu zostało zamknięte. W kwietniu wznowiono analizowanie XSS, a problem został naprawiony w wersjach 2.3.2, 2.2.9 i 2.1.18.
Należy zauważyć, że te wydania naprawiają także 75 luk, z czego 16 zostało sklasyfikowanych jako krytyczne, a 20 może prowadzić do wykonania kodu PHP lub podstawienia kodu SQL. Większość krytycznych problemów może popełnić wyłącznie uwierzytelniony użytkownik, ale jak pokazano powyżej, uwierzytelnione operacje można łatwo przeprowadzić przy użyciu luk XSS, z których kilkadziesiąt zostało załatanych w odnotowanych wydaniach.
Źródło: opennet.ru