Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Na wybranych stronach internetowych dużych marek, w tym Toshiba i Muji, pojawiły się nieoczekiwane okna logowania generowane po stronie przeglądarki. Incydent powiązano z zasobem polyfill.io, historycznie wykorzystywanym do dostarczania skryptów JavaScript zapewniających zgodność z przestarzałymi przeglądarkami. Z perspektywy cyberbezpieczeństwa jest to przykład ryzyka łańcucha dostaw po stronie front-endu: nawet jeśli sama witryna nie została bezpośrednio zhakowana, zewnętrzny komponent może wywołać zachowanie prowadzące do phishingu, utraty zaufania użytkowników i potencjalnej kompromitacji danych.
W skrócie
Problem dotyczył niespodziewanych monitów uwierzytelniających wyświetlanych użytkownikom odwiedzającym wybrane strony WWW. Według opublikowanych komunikatów zjawisko miało związek z zewnętrzną usługą polyfill.io. Obie firmy zaleciły użytkownikom ostrożność oraz zmianę haseł w przypadku ich wcześniejszego wprowadzenia w podejrzanym formularzu.
- Incydent miał charakter phishingopodobny i był związany z ładowaniem zewnętrznego zasobu.
- Po identyfikacji problemu usługa została wyłączona lub odłączona od dotkniętych serwisów.
- Nie przedstawiono publicznych dowodów potwierdzających wyciek poświadczeń, ale ryzyko dla użytkowników było realne.
Kontekst / historia
Polyfill to mechanizm umożliwiający uruchamianie nowoczesnych funkcji JavaScript w starszych przeglądarkach. Przez lata wiele serwisów korzystało z gotowych bibliotek i sieci CDN dostarczających odpowiedni kod bez konieczności hostowania go lokalnie. Taki model upraszcza wdrożenia, ale jednocześnie zwiększa zależność od zewnętrznych dostawców.
Znaczenie tego przypadku jest większe ze względu na wcześniejsze kontrowersje wokół domeny polyfill.io. Już wcześniej środowisko bezpieczeństwa ostrzegało, że korzystanie z tego zasobu może być niebezpieczne po zmianie właściciela domeny i pojawieniu się złośliwych lub niepożądanych zachowań w dostarczanych skryptach. Mimo tych ostrzeżeń część organizacji nie usunęła wszystkich odwołań do usługi ze swoich stron, szablonów, podstron kampanijnych lub starszych komponentów. To właśnie takie pozostałości techniczne mogły umożliwić ponowne wystąpienie problemu po reaktywacji odpowiedzi z domeny.
Analiza techniczna
Technicznie incydent nie przypomina klasycznego przejęcia kont użytkowników poprzez włamanie do aplikacji webowej. Z dostępnych informacji wynika, że domena polyfill.io zaczęła zwracać odpowiedzi HTTP 401 Unauthorized. Dla przeglądarek oznacza to żądanie uwierzytelnienia i może skutkować automatycznym wyświetleniem natywnego okna logowania.
To istotny detal: użytkownik nie musi widzieć klasycznego formularza HTML osadzonego w stronie. Zamiast tego pojawia się natywny monit przeglądarki, który przez część odbiorców może zostać uznany za legalny element serwisu. W praktyce taki scenariusz zwiększa skuteczność socjotechniki, ponieważ okno wygląda bardziej systemowo niż typowy phishingowy popup.
Najbardziej prawdopodobny łańcuch zdarzeń wyglądał następująco:
- Strona nadal zawierała odwołanie do zewnętrznego zasobu z domeny polyfill.io.
- Przeglądarka próbowała pobrać skrypt wymagany przez front-end.
- Serwer zamiast pliku JavaScript zwracał odpowiedź HTTP 401.
- Przeglądarka interpretowała odpowiedź jako wymaganie podania nazwy użytkownika i hasła.
- Użytkownik widział niespodziewany monit uwierzytelnienia i mógł błędnie uznać go za prawidłowy.
Z punktu widzenia bezpieczeństwa aplikacyjnego to klasyczny przykład zagrożenia wynikającego z niekontrolowanego ładowania zewnętrznych zależności. Nawet jeśli sam skrypt nie został wykonany, samo zachowanie infrastruktury zewnętrznej wystarczyło do wywołania phishingopodobnego efektu. Warto podkreślić, że problem mógł wynikać nie z naruszenia stron Toshiba czy Muji, lecz z obecności historycznych referencji do usługi CDN w kodzie front-endu, szablonach lub zależnościach pośrednich.
Konsekwencje / ryzyko
Najbardziej oczywiste ryzyko dotyczy poświadczeń użytkowników. Jeżeli odwiedzający wprowadzili dane logowania do wyświetlonego monitu, mogły one zostać narażone na ujawnienie, choć publicznie nie potwierdzono takiego scenariusza. Samo ryzyko było jednak wystarczająco poważne, by organizacje rekomendowały zmianę haseł.
Drugim obszarem jest ryzyko reputacyjne. Dla użytkownika końcowego nie ma dużego znaczenia, czy źródłem problemu była bezpośrednia kompromitacja witryny, czy zewnętrzny komponent. Widoczny efekt jest ten sam: strona dużej marki zachowuje się w sposób podejrzany, co podważa zaufanie do serwisu.
Trzeci wymiar to ryzyko operacyjne i compliance. Organizacje, które nie prowadzą pełnej inwentaryzacji zewnętrznych skryptów, mogą nie wiedzieć, że stare komponenty nadal są ładowane na niszowych podstronach, landing page’ach, panelach regionalnych lub archiwalnych sekcjach serwisu. Oznacza to lukę w zarządzaniu aktywami aplikacyjnymi i trudność w szybkim reagowaniu na incydenty supply chain.
Incydent pokazuje również, że zagrożenia po stronie klienta nie zawsze polegają na wstrzyknięciu kodu kradnącego dane. Czasami wystarczy manipulacja odpowiedzią HTTP, aby uruchomić mechanizm wywołujący zachowanie phishingowe bez potrzeby pełnego wykonania złośliwego JavaScript.
Rekomendacje
Organizacje powinny potraktować ten przypadek jako sygnał do pełnego przeglądu zależności front-endowych. W praktyce oznacza to:
- przeprowadzenie inwentaryzacji wszystkich zewnętrznych skryptów, bibliotek i zasobów ładowanych przez strony publiczne,
- usunięcie historycznych odwołań do porzuconych, przejętych lub niezweryfikowanych domen CDN,
- hostowanie krytycznych bibliotek lokalnie tam, gdzie jest to możliwe i uzasadnione operacyjnie,
- wdrożenie polityk Content Security Policy ograniczających możliwość ładowania nieautoryzowanych zasobów,
- stosowanie Subresource Integrity dla zewnętrznych plików statycznych, jeśli model wdrożeniowy na to pozwala,
- monitorowanie odpowiedzi zewnętrznych zasobów pod kątem anomalii, takich jak zmiana typu treści, kody 401, 403 i 5xx lub nietypowe przekierowania,
- skanowanie całych serwisów, w tym starych podstron i środowisk marketingowych, pod kątem osadzonych referencji do zewnętrznych domen,
- utrzymywanie procesu zarządzania ryzykiem dostawców obejmującego także komponenty JavaScript po stronie klienta.
Z perspektywy użytkowników końcowych zalecenia są prostsze, ale równie ważne:
- nie wpisywać danych logowania w niespodziewane okna uwierzytelnienia pojawiające się bez kontekstu,
- weryfikować, czy logowanie odbywa się w oczekiwanym formularzu witryny,
- zmienić hasło, jeśli zostało wpisane w podejrzanym monicie,
- włączyć wieloskładnikowe uwierzytelnianie wszędzie tam, gdzie jest dostępne,
- obserwować historię logowań i aktywność kont po incydencie.
Dla zespołów SOC i AppSec dobrym krokiem będzie także utworzenie detekcji dla zmian w zachowaniu skryptów trzecich stron, szczególnie tych ładowanych z domen historycznie powiązanych z incydentami supply chain.
Podsumowanie
Incydent z podejrzanymi monitami logowania na stronach Toshiba i Muji pokazuje, że zagrożenia związane z łańcuchem dostaw JavaScript nie znikają wraz z pierwszą falą ostrzeżeń. Nawet po latach pozostałości po dawnych integracjach mogą ponownie stać się źródłem ryzyka. W tym przypadku problem najprawdopodobniej wynikał z odwołań do polyfill.io oraz odpowiedzi HTTP 401, które skłoniły przeglądarki do wyświetlenia natywnych okien logowania. Choć brak publicznego potwierdzenia kradzieży poświadczeń, zdarzenie należy traktować poważnie: to czytelny przykład, jak niepozorna zależność front-endowa może uruchomić skuteczny wektor phishingowy i narazić organizację na straty wizerunkowe oraz operacyjne.
Źródła
- BleepingComputer — Suspicious Polyfill login prompts pop up on Toshiba, Muji websites — https://www.bleepingcomputer.com/news/security/suspicious-polyfill-login-prompts-pop-up-on-toshiba-muji-websites/
- Toshiba — komunikat dotyczący podejrzanego ekranu logowania — https://www.global.toshiba/ww/news/corporate/2026/06/news-20260605-01.html
- MUJI — komunikat dotyczący wyświetlania podejrzanych ekranów uwierzytelnienia — https://www.muji.com/jp/ja/notice/20250603_01
- Sansec — Polyfill supply chain attack hits over 100K sites — https://sansec.io/research/polyfill-supply-chain-attack
- Cloudflare — A note on polyfill.io — https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet/