Strona internetowa może działać prawidłowo i jednocześnie wykonywać w przeglądarce użytkownika złośliwy JavaScript. Pokazują to zarówno ataki na pojedyncze sklepy internetowe, jak i kompromitacje popularnych bibliotek wykorzystywanych przez tysiące witryn. Poniżej przedstawiamy trzy przypadki, które pokazują, dlaczego samo sprawdzenie własnego kodu serwisu nie zawsze wystarcza.
Case study nr 1: złośliwy JavaScript dystrybuowany przez Google Tag Manager
W lutym 2025 roku Sucuri opisało przypadek kampanii wymierzonej w sklepy internetowe oparte na Magento, w której do ukrycia i uruchomienia złośliwego JavaScript wykorzystano Google Tag Manager (GTM) – powszechnie używany mechanizm służący do zarządzania kodem analitycznym, reklamowym i marketingowym.
Złośliwy kod został przygotowany w taki sposób, aby przypominał typowy fragment związany z Google Tag Manager i Google Analytics. W rzeczywistości zawierał zakodowany payload prowadzący do uruchomienia skimmera danych kart płatniczych.
Po wykonaniu w przeglądarce skimmer przechwytywał dane wprowadzane przez klientów podczas procesu płatności i przesyłał je do infrastruktury kontrolowanej przez atakujących.
Dlaczego ten scenariusz jest szczególnie niebezpieczny?
Współczesna strona internetowa nie składa się wyłącznie z kodu stworzonego i utrzymywanego przez jej właściciela.
Typowy serwis ładuje JavaScript pochodzący z systemów analitycznych, reklamowych, marketing automation, tag managerów, systemów A/B testing, widgetów, chatbotów oraz wielu innych usług zewnętrznych.
Powstaje w ten sposób rozbudowany łańcuch dostaw oprogramowania po stronie klienta (client-side software supply chain).
Szczególnie interesującym przykładem jest Google Tag Manager. Kontener GTM może uruchamiać Custom HTML oraz JavaScript, w tym kod pochodzący od innych dostawców. Dla administratora obserwującego kod strony obecność zasobu z domeny googletagmanager.com jest przy tym czymś całkowicie normalnym.
To właśnie zaufanie może zostać wykorzystane przez atakującego.
Badacze bezpieczeństwa obserwowali kampanie Magecart, w których złośliwy kod lub loader skimmera znajdował się wewnątrz kontenera GTM. Mechanizm Google powodował następnie jego załadowanie i wykonanie w przeglądarce ofiary.
Gdzie w takim scenariuszu działa wIDS?
Ten przypadek dobrze pokazuje różnicę pomiędzy kontrolą źródła skryptu a analizą samego kodu wykonywanego przez użytkownika.
Informacja:
JavaScript pochodzi z googletagmanager.com
nie oznacza automatycznie:
JavaScript wykonywany na stronie jest bezpieczny.
Mechanizm Malicious JavaScript Detection analizuje kod pozyskany podczas rzeczywistego badania chronionego serwisu. Model ML nie opiera swojej decyzji wyłącznie na reputacji domeny, nazwie pliku czy znanym hashu, lecz analizuje strukturę JavaScript i poszukuje cech charakterystycznych dla kodu malicious.
Dzięki temu również kod dostarczony poprzez zaufany komponent third-party może stać się źródłem anomalii.
Ma to szczególne znaczenie dla ataków typu Magecart. Skimmer może zostać uruchomiony wyłącznie na określonych podstronach – na przykład podczas checkoutu lub w formularzu płatności.
Strona główna, katalog produktów i zdecydowana większość serwisu mogą pozostawać całkowicie niezmienione.
wIDS może analizować zasoby JavaScript występujące na wielu podstronach pozyskanych z sitemap, poszukując podejrzanego kodu również głęboko w strukturze serwisu, w miejscach występujących dopiero na konkretnym etapie ścieżki użytkownika.
Dla CTI wykrycie potencjalnie złośliwego JavaScript stanowi wówczas obserwowalny artefakt (observable), który może zostać skorelowany z innymi zmianami: pojawieniem się nowej domeny zewnętrznej, nowego zasobu, modyfikacją istniejącego skryptu lub innymi anomaliami obserwowanymi przez wIDS.
Incydent pokazuje fundamentalny problem współczesnego bezpieczeństwa aplikacji webowych: organizacja może ufać dostawcy lub domenie, z której pochodzi skrypt, ale z perspektywy bezpieczeństwa ostatecznie znaczenie ma kod, który rzeczywiście został wykonany w przeglądarce użytkownika.
Case study nr 2: Złośliwy JavaScript w British Airways
W 2018 roku British Airways padło ofiarą ataku, którego końcowym elementem była modyfikacja JavaScript wykonywanego na stronie przewoźnika.
Według oficjalnego postępowania brytyjskiego Information Commissioner’s Office atakujący uzyskał dostęp do infrastruktury BA, przemieszczał się wewnątrz sieci, a następnie zidentyfikował pliki zawierające kod serwisu britishairways.com.
Atakujący zmodyfikował JavaScript bibliotekę Modernizr. W efekcie kod był odpowiedzialny za działanie serwisu w taki sposób, aby dane kart płatniczych wprowadzane przez klientów były kopiowane i przesyłane do kontrolowanej przez niego domeny BAways.com.
Z punktu widzenia użytkownika proces rezerwacji i płatności nadal funkcjonował prawidłowo.
I właśnie ta cecha czyni client-side malware szczególnie niebezpiecznym.
Atakujący nie musi podmieniać strony, wyświetlać komunikatu ani powodować awarii. Jego celem może być pozostanie niezauważonym. Prawidłowa aplikacja nadal realizuje swoją funkcję, ale w jej kodzie działa dodatkowy fragment JavaScript wykonujący równolegle operację na rzecz atakującego.
W przypadku British Airways złośliwy mechanizm pozostawał aktywny przez około 15 dni. Incydent został wykryty dopiero po otrzymaniu przez BA zewnętrznej informacji wskazującej na komunikację z domeną kontrolowaną przez atakującego.
Gdzie w takim scenariuszu działa wIDS?
Malicious JavaScript Detection analizuje właśnie warstwę, którą atakujący wykorzystał w tym incydencie – kod wykonywany w przeglądarce klienta.
Gdyby podczas kolejnej analizy w monitorowanym zasobie pojawiła się zmodyfikowana wersja JavaScript zawierająca struktury charakterystyczne dla złośliwego kodu, model ML mógłby zaklasyfikować ją jako anomalię wymagającą dalszej analizy.
Szczególnie istotna jest możliwość prowadzenia kontroli na szerokiej powierzchni serwisu.
Skimmer nie musi występować na stronie głównej. W praktyce znacznie bardziej wartościowym celem jest miejsce, w którym użytkownik wprowadza dane – formularz płatności, checkout, logowanie, rejestracja lub panel klienta.
Strona główna może więc pozostać całkowicie czysta.
wIDS, analizując zasoby występujące na podstronach pozyskanych z sitemap, może poszukiwać potencjalnie złośliwego JavaScript również głęboko w strukturze aplikacji, w tym w obszarach wykorzystywanych tylko na określonym etapie ścieżki użytkownika.
Incydent British Airways pokazuje tym samym zasadniczą wartość tego rodzaju sensora dla CTI: możliwe jest poszukiwanie technicznych symptomów kompromitacji zanim atak spowoduje widoczną awarię lub zmianę wyglądu serwisu.
W połączeniu z innymi czynnikami wIDS wykrycie podejrzanego JavaScript może zostać dodatkowo skorelowane z pojawieniem się nowej domeny zewnętrznej, zmianą zasobu, modyfikacją struktury strony lub innymi observables. Pojedyncza anomalia ML staje się wówczas elementem szerszego obrazu potencjalnego incydentu.
Case study nr 3: Polyfill.io JavaScript supply chain hack.
W czerwcu 2024 roku wykryto jeden z najbardziej znaczących współczesnych przykładów kompromitacji łańcucha dostaw JavaScript.
Popularny serwis Polyfill.io dostarczał bibliotekę JavaScript wykorzystywaną przez ponad 100 tysięcy witryn internetowych. Właściciele tych serwisów nie przechowywali lokalnej kopii biblioteki – przeglądarki użytkowników pobierały kod bezpośrednio z zewnętrznej infrastruktury.
Po przejęciu projektu i domeny przez nowego właściciela kod dostarczany użytkownikom został zmodyfikowany. Do prawidłowej biblioteki wprowadzono zachowanie pozwalające między innymi selektywnie przekierowywać użytkowników do zewnętrznych serwisów.
Właściciel strony wykorzystującej Polyfill.io nie musiał w tym czasie dokonać żadnej zmiany we własnym kodzie.
Nie musiało dojść również do kompromitacji jego serwera, CMS, repozytorium czy kont administratorów.
Zmieniła się zawartość zewnętrznego JavaScript, któremu aplikacja wcześniej zaufała.
Gdzie w takim scenariuszu działa wIDS?
To modelowy przykład znaczenia obserwacji aplikacji z perspektywy przeglądarki użytkownika.
Kontrola własnego repozytorium kodu mogła nie wykazać żadnej zmiany. Integralność plików na serwerze mogła pozostać nienaruszona. System WAF również nie musiał obserwować ataku na chronioną aplikację.
Zmienił się natomiast kod JavaScript faktycznie dostarczany i wykonywany w przeglądarkach użytkowników.
Malicious JavaScript Detection może analizować również kod pozyskiwany z zewnętrznych zasobów wykorzystywanych przez chronione strony. Jeżeli wcześniej prawidłowa biblioteka zaczyna wykazywać strukturalne cechy charakterystyczne dla malicious JavaScript, powstaje niezależny sygnał wymagający analizy.
Incydent Polyfill.io pokazuje tym samym, dlaczego ciągła analiza rzeczywiście dostarczanego JavaScript może być istotnym elementem CTI i monitorowania zewnętrznej powierzchni ataku.
Nie wystarczy wiedzieć, jakie biblioteki organizacja zdecydowała się wdrożyć.
Istotne jest również to, jaki kod te biblioteki dostarczają użytkownikom dzisiaj.
Źródła:
1. https://blog.sucuri.net/2025/02/google-tag-manager-skimmer-steals-credit-card-info-from-magento-site.html
2. https://rhisac.org/threat-intelligence/google-tag-manager-magento/
3. https://thehackernews.com/2025/02/hackers-exploit-google-tag-manager-to.html
4. https://www.bleepingcomputer.com/news/security/british-airways-fell-victim-to-card-scraping-attack/
5. https://www.rapid7.com/blog/post/2018/09/20/the-british-airways-breach-pci-is-not-enough/
6. https://www.securonix.com/blog/securonix-threat-research-british-airways-breach-magecart-formgrabbing-supply-chain-attack-detection/
7. https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet/
8. https://sansec.io/research/polyfill-supply-chain-attack
