Bezpieczeństwo Magento: luka CosmicSting i łatki CVE

Czy Magento 2.4 samo w sobie jest podatne na ataki?

Magento 2.4 nie jest systemem dziurawym domyślnie, ale zaniedbanie kwartalnych wydań Security Patches (np. przejścia z wersji 2.4.6 na 2.4.7-p2) wystawia sklep na automatyczne skanery botnetów w ciągu kilkudziesięciu godzin od publikacji biuletynu Adobe Security. Jeśli nikt nie audytował kodu Twojego sklepu przez ostatnie pół roku, rzetelny audyt techniczny Magento wykaże zazwyczaj co najmniej jedną podatność SQL Injection w customowym module, niepoprawnie zabezpieczony endpoint REST API lub podatność XSS w panelu administracyjnym. W e-commerce bezpieczeństwo to proces utrzymaniowy, a nie jednorazowa konfiguracja serwera przy wdrożeniu.

Boty skanujące sieć nie sprawdzają wielkości Twojego biznesu. Uderzają masowo w każdy adres IP z otwartym portem 443, który w nagłówkach HTTP lub strukturze katalogów zdradza obecność silnika Adobe Commerce. Cel jest prosty: wstrzyknięcie skryptu kradnącego numery kart (Magecart / digital skimming), przejęcie bazy zarejestrowanych klientów na potrzeby phishingu lub wykorzystanie mocy procesora do farmingu kryptowalut.

Najgroźniejsze CVE w ekosystemie Magento: CosmicSting i podatności RCE

Ostatnie dwa lata brutalnie zweryfikowały sklepy, które odkładały aktualizacje na „spokojniejszy okres po sezonie”. Najgłośniejszy przypadek to CVE-2024-34102, znany szerzej jako CosmicSting. Ta krytyczna luka (CVSS 9.8) typu XML External Entity Injection (XXE) w parserze API REST/GraphQL pozwalała nieuwierzytelnionemu napastnikowi na odczyt dowolnych plików z serwera.

Konsekwencja? Pobranie pliku app/etc/env.php, wyciągnięcie klucza szyfrującego (crypt/key) oraz danych dostępowych do bazy MariaDB/MySQL. Posiadając unikalny klucz kryptograficzny instancji, atakujący generuje fałszywy token administratora JSON Web Token (JWT) i uzyskuje pełny dostęp do panelu zarządczego z uprawnieniami roota bez znajomości hasła.

Samo zaktualizowanie silnika do wersji Magento 2.4.7-p1 lub nałożenie poprawki izolowanej po ataku nie unieważnia skradzionego crypt/key. Jeśli plik env.php wyciekł, konieczna jest ręczna rotacja klucza i re-enkrypcja wrażliwych danych w bazie komendą CLI, inaczej sklep pozostaje skompromitowany.

Inne krytyczne podatności, które regularnie wracają w audit logach:

• CVE-2022-24086 (Adobe Commerce Improper Input Validation): Umożliwiała zdalne wykonanie kodu (RCE) przez szablony e-mail w module checkoutu.
• CVE-2024-20720: Luka wykorzystująca niepoprawne czyszczenie danych wejściowych w module Magento_CustomerBalance, pozwalająca na wstrzyknięcie złośliwego kodu do layoutu.
• Brak ochrony OpenSearch 2.x: Wystawienie portu 9200 na świat zewnętrzny. Atakujący omija Magento, czyta pełną strukturę katalogu produktów, stanów magazynowych i cen hurtowych bezpośrednio z klastra wyszukiwarki.

Gdzie Magento łamie OWASP Top 10 przez błędy w integracjach z ERP i płatnościami?

Rdzeń Magento (core code) jest regularnie sprawdzany przez Adobe i społeczność bug bounty. Prawdziwym wektorem ataku są customowe moduły pisane na kolanie przez agencje bez standardów PSR-12 oraz marketplace'owe wtyczki od firm trzecich (Amasty, Mirasvit, Mageworx), które nie były aktualizowane od trzech lat.

U nas w projektach najczęściej spotykamy luki z listy OWASP Top 10 w modułach integrujących sklep z polskim ekosystemem biznesowym:

1. Broken Access Control i Insecure Direct Object References (IDOR) w modułach ERP

Moduły synchronizujące dane z Comarch ERP Optima, Subiekt GT/nexo czy Wapro Mag często tworzą własne controllery w Magento bez implementacji Magento\Framework\AuthorizationInterface. Skutek: zewnętrzny skrypt może odpytać URL typu /custom_erp/sync/getOrders?from_id=1000 i pobrać kompletne dane adresowe klientów, numery PESEL, NIP oraz historię transakcji z pominięciem jakiejkolwiek autoryzacji sesją czy tokenem Bearer.

2. SQL Injection i podatności XSS w integracjach logistycznych i bramkach płatności

Pisząc własne moduły pod generowanie etykiet InPost Paczkomaty lub obsługę webhooków odroczonych płatności (PayPo, Twisto, BLIK, Przelewy24), deweloperzy zapominają o korzystaniu z Magento Service Contracts i Repositories. Zamiast operować na \Magento\Framework\DB\Select z bindowaniem parametrów, wstrzykują surowe zmienne $_POST['transaction_id'] wprost do zapytań SQL przez $connection->query(...). To otwarta droga do zrzucenia tabeli admin_user lub sales_order_payment.

3. Nieprawidłowa walidacja danych przy fakturowaniu i KSeF

Pola wprowadzane przez klienta (np. NIP do faktury, prefiks VAT UE) trafiają bez sanitizacji (strip_tags, htmlspecialchars) do panelu administracyjnego. W momencie, gdy księgowa otwiera podgląd zamówienia w panelu administracyjnym, wykonuje się wstrzyknięty kod JavaScript (Stored XSS), który kradnie jej ciasteczko sesyjne i instaluje złośliwego administratora w tle.

Jak wygląda oficjalny cykl łatek Adobe i co to oznacza dla budżetu?

Adobe odeszło od częstych wydań dużych wersji funkcyjnych na rzecz rozdzielenia aktualizacji bazowych od łatek bezpieczeństwa (Security-Only Patches). Obecnie w cyklu życia Magento 2.4 wyróżniamy dwa typy aktualizacji:

1. Pełne wersje (np. Magento 2.4.7): Wymagają aktualizacji środowiska PHP (np. skok z PHP 8.1 na 8.2 lub 8.3), podbicia wersji OpenSearch do 2.12+, biblioteki Composer 2.7+. Często wymuszają modyfikację szablonów Hyvä Themes lub Luma ze względu na zmiany w zależnościach JavaScript/PHP.
2. Security-Only Patches (np. 2.4.7-p1, 2.4.7-p2, 2.4.7-p3): Zawierają wyłącznie łatki podatności CVE bez zmian architektonicznych i bez wprowadzania nowych funkcji. Można je wdrożyć w ciągu 2-4 godzin roboczych.

W SISL rekomendujemy sztywne trzymanie się zasady: łatka security-only musi wjechać na środowisko produkcyjne maksymalnie w ciągu 14 dni od jej opublikowania. Zaniedbanie tego powoduje nawarstwienie długu technologicznego. Jeśli zostaniesz na Magento 2.4.4, instalacja łatki z 2.4.7-p2 nie będzie możliwa metodą composer update bez podbicia całego systemu, co zamiast kosztu 1 000 – 2 000 PLN wygeneruje projekt migracyjny wyceniany na 15 000 – 40 000 PLN.

Ile realnie kosztuje włamanie na sklep Magento 2 w polskich realiach prawnych?

Koszty ataku hakerskiego rzadko kończą się na przywróceniu kopii zapasowej bazy danych. W polskim e-commerce zaniedbanie bezpieczeństwa pociąga za sobą natychmiastowe straty operacyjne:

• Kary Prezesa UODO: Wyciek bazy danych osobowych (RODO/GDPR) z powodu braku aktualizacji oprogramowania jest traktowany jako rażące niedopełnienie obowiązków administratora danych. Kary w sektorze MŚP w Polsce sięgają od kilkudziesięciu do kilkuset tysięcy złotych.
• Blokady bramek płatności: Gdy operatorzy tacy jak Przelewy24, PayU czy AutoPay odnotują podejrzany wzrost transakcji fraudowych lub kradzieży kart powiązany z Twoim identyfikatorem Merchant ID, natychmiast zawieszają wypłatę środków na rachunek bankowy i blokują bramkę do czasu przedstawienia raportu powłamaniowego.
• Zablokowanie kampanii Google Ads i Meta Ads: Googlebot regularnie skanuje landing page. Jeśli wykryje na stronie kod skimmera (obfuskowany JavaScript podpięty pod zdarzenia click na przycisku „Kupuję i płacę”), domena trafia na czarną listę Malware/Compromised Site. Odblokowanie kampanii w Google Merchant Center po incydencie potrafi trwać od 5 do 20 dni roboczych.
• Biała lista podatników VAT i błędy JPK: Skompromitowany serwer może posłużyć do podmiany numerów kont bankowych generowanych na fakturach proforma w plikach PDF przesyłanych do klientów B2B, co generuje bezpośrednie straty finansowe i spory karnoskarbowe.

Praktyczna lista kontrolna: 7 twardych kroków zabezpieczenia instancji Magento 2.4

Niezależnie od tego, czy korzystasz z tradycyjnego motywu Luma, czy headless PWA lub Hyvä Themes, poniższa konfiguracja to absolutne minimum na poziomie serwera Linux (Nginx/PHP-FPM) i aplikacji:

1. Zmiana domyślnej ścieżki panelu admina: Nigdy nie zostawiaj frontName jako admin w pliku app/etc/env.php. Używaj unikalnego ciągu znaków (np. zarzadzanie_sklepem_sisl) i zabezpiecz ten endpoint regułami IP Whitelist na poziomie Nginx lub Cloudflare WAF.
2. Wymuszenie dwuskładnikowego uwierzytelniania (2FA): Moduł Magento_TwoFactorAuth nie może być wyłączony (bin/magento module:disable Magento_TwoFactorAuth to kryminał wdrożeniowy). Skonfiguruj klucze sprzętowe U2F/WebAuthn lub Google Authenticator dla każdego konta z rolą administratora.
3. Restrykcyjna konfiguracja Nginx: Zablokuj całkowity dostęp HTTP do katalogów /app/, /var/, /generated/, /pub/media/customer/ oraz bezpośrednich wywołań plików .env, composer.json, composer.lock.
4. Polityka Content Security Policy (CSP): Od wersji 2.4.7 CSP w Magento działa domyślnie w trybie blokującym (restrictive mode). Zamiast wyłączać moduł Magento_Csp, zdefiniuj precyzyjną białą listę domen dla zewnętrznych skryptów (Google Tag Manager, Hotjar, widget InPost Paczkomaty, czat Smartsupp) w pliku etc/csp_whitelist.xml Twojego motywu.
5. Odizolowanie portu OpenSearch: Serwer OpenSearch/Elasticsearch musi nasłuchiwać wyłącznie na interfejsie lokalnym (127.0.0.1) lub w wydzielonej sieci prywatnej (VPC). Zero publicznych adresów IP dla portu 9200.
6. Wdrożenie Magento Security Scanner: Zarejestruj domenę w darmowym narzędziu Adobe Security Scanner, które wykonuje codzienne testy podatności znanych CVE i sprawdza sumy kontrolne plików bazowych.
7. Prawidłowy deployment bez uprawnień roota: Całość operacji budowania (bin/magento setup:di:compile, bin/magento setup:static-content:deploy) musi być wykonywana przez dedykowanego użytkownika systemowego z uprawnieniami chmod 755 dla katalogów i 644 dla plików. Nigdy nie uruchamiaj procesów Magento jako root.

Utrzymanie bezpiecznego sklepu nie wymaga zatrudniania sztabu inżynierów, ale dyscypliny w stosowaniu poprawek i czujności przy doborze wtyczek. Jeśli nie masz pewności, czy Twoja wersja Magento 2.4 posiada niezałatane luki lub przygotowujesz się do wdrożenia nowych integracji z ERP i KSeF, napisz do nas — sprawdzimy stan techniczny Twojej platformy i wdrożymy niezbędne łatki bez przerywania sprzedaży.