Bezpieczeństwo 920 serwisów płatniczych i bankowych, których szukają ludzie — 13.4 mln podpowiedzi wyszukiwania zestawionych z badaniem Phase5

• W 48 regionach i 20 językach zebrałem 13.4 mln podpowiedzi wyszukiwania (9.28 mln unikalnych) dla 3,472 marek z obszaru płatności, bankowości, handlu i usług codziennych, a następnie jednym zwykłym wczytaniem strony zaobserwowałem publiczną konfigurację 920 serwisów, na które te podpowiedzi wskazują. Każde przypisanie marki do serwisu sprawdziłem potem ręcznie; 680 serwisów, które przeszły weryfikację, stanowi podstawę wszystkich danych w tym artykule.
• Spośród 269 serwisów płatniczych i bankowych 26.4% (71) miało co najmniej jedną z luk: brak HSTS, ujawniona wersja serwera lub wersja po końcu wsparcia. Najczęstszą luką był brak HSTS (20.1%). 16.4% nie wynegocjowało TLS 1.3; wszystkie serwisy, które odpowiedziały, używały TLS 1.2 lub nowszego.
• Żaden serwis płatniczy ani bankowy nie ujawniał wersji PHP po końcu wsparcia. Spośród wszystkich 1,705 nowo przeskanowanych hostów tylko 18 (9 serwisów, licząc domenę główną i www) ujawniało wersję PHP, a 5 z nich (3 serwisy) używało wersji po końcu wsparcia. W porównaniu z ogólną populacją z Security Exposure Survey 2026 serwisy płatnicze i bankowe albo ukrywają wersję, albo utrzymują ją aktualną.
• Udział podpowiedzi zawierających słowa takie jak „awaria”, „płatność nieudana” czy „nie mogę się zalogować” (wskaźnik wyszukiwań problemowych) wyniósł 0.29% z 3.18 mln podpowiedzi zwróconych dla samej nazwy marki. Maksimum dla pojedynczej marki to 10.0%, a ponad połowa marek nie miała takich podpowiedzi wcale. Wyszukiwania skarżące się na awarie są w podpowiedziach rzadkie.
• Wymieniam z nazwy dwadzieścia dobrych przykładów (Tabela A) i 92 serwisy z zaobserwowanymi problemami (Tabela B). Tabela B zapisuje fakty publiczne — ustawienia TLS i nagłówki HTTP — i nie oznacza, że w którymkolwiek serwisie stwierdzono możliwość ataku.

Ten artykuł jest również opublikowany po angielsku na sitescouter.net i nkzw.jp oraz po japońsku na sitescouter.net. To polskie wydanie w serwisie Site Scouter, przetłumaczone z wersji angielskiej.

Metoda

Ten artykuł łączy dwa badania (Rysunek 1).

1. Zbieranie podpowiedzi (Egosaru). W 48 regionach i 20 językach zarejestrowałem podpowiedzi, które Google, Bing, Yahoo!, Yandex, Naver, Baidu, Daum i Shopee wyświetlają po wpisaniu nazwy marki w pole wyszukiwania. Użyłem dwóch rodzajów zapytań startowych: samej nazwy marki („zapytanie proste”) oraz nazwy marki z dodanym słowem problemowym („zapytanie złożone”). Dało to 83,275 zadań pobierania (83,016 ukończonych, 259 nieudanych) i 13,438,498 podpowiedzi (9,280,238 unikalnych), zebranych w dniach 24–26 października 2026.
2. Obserwacja publicznej konfiguracji (Site Scouter Phase5). Dla marek, które się pojawiły, zidentyfikowałem ich serwisy (5,408 hostów kandydujących, z czego 2,842 odpowiedziały na DNS i HTTPS) i nowo zaobserwowałem 1,705 hostów, których nie było jeszcze we wcześniejszym badaniu. Każda obserwacja to jedno zapytanie DNS, jeden handshake TLS i jedno żądanie HTTP GET — tyle samo, co jednorazowe otwarcie strony w przeglądarce. Nie było skanowania portów, sondowania podatności, prób uwierzytelnienia ani ruchu eksploitującego. Obserwacje prowadziłem w dniach 22–26 października 2026.
3. Oba zbiory połączyłem na poziomie marki, co dało 9,181 wierszy marka × region × wyszukiwarka i 920 unikalnych hostów. Każdy z 920 sprawdziłem następnie ręcznie, aby potwierdzić, że host rzeczywiście jest oficjalnym serwisem marki; 680 hostów, które przeszły weryfikację, jest mianownikiem używanym w całym tekście (wykluczono 212 błędnie zidentyfikowanych i 28 nierozstrzygalnych). Wszystkie mianowniki w tym artykule to liczby hostów.

Przypisanie marki do serwisu było procesem automatycznym, opartym na dokładnych (2,630) i częściowych (2,778) dopasowaniach nazw hostów, który wychwytuje też niepowiązane serwisy o podobnych nazwach. Ręczne sprawdzenie wszystkich 920 hostów wykazało 212 (23.0%), które nie należały do marki (na przykład „Hello bank” przypisany do niepowiązanego serwisu o podobnej nazwie albo „SMBC Nikko Securities” przypisany do serwisu banku), oraz 28, których nie dało się rozstrzygnąć. Błędy skupiają się wokół ogólnych nazw marek, takich jak „Easy”, „Media” czy „Wi-Fi”, oraz wokół niepowiązanych organizacji o tej samej nazwie. Zestawienia w §4 oraz Tabele A i B używają wyłącznie 680 hostów, które przeszły tę weryfikację. Zmierzone ustawienia wykluczonych hostów same w sobie są poprawne, ale odrzuciłem je, ponieważ przypisana im branża i kraj były błędne.

Definicje

• Wskaźnik wyszukiwań problemowych: wśród podpowiedzi zwróconych dla samej nazwy marki udział tych, które zawierają słowo problemowe zdefiniowane z góry dla każdego języka — „awaria”, „nie działa”, „płatność nieudana”, „nie mogę się zalogować”, „aplikacja się nie otwiera”, „kupon nie działa” i podobne. Nie oznacza on, że trwa awaria. Przybliża, jak często użytkownicy szukają informacji o problemach.
• Słowo problemowe w podpowiedzi nie oznacza, że usługa została zatrzymana przez podatność lub włamanie. Przyczyny sięgają od incydentów sieciowych i przeciążenia po błędy użytkowników i ślady dawnych zdarzeń, a moment zbierania podpowiedzi nie pokrywa się z momentem obserwacji bezpieczeństwa. Zestawienie obu danych obok siebie nie twierdzi, że istnieje korelacja ani związek przyczynowy; pokazuje „konfigurację, w chwili obserwacji, usług, które użytkownicy wymieniają najczęściej”.
• Problem konfiguracyjny (co w tym artykule znaczy „ma problemy”): (1) brak nagłówka HSTS (nagłówka wymuszającego HTTPS); (2) produkt lub wersja serwera są widoczne z zewnątrz; (3) ujawniona wersja jest po końcu wsparcia lub mieści się w zakresie opublikowanego CVE. Nie prowadziłem testów inwazyjnych i nic tutaj nie mówi, że serwis „da się faktycznie włamać”.
• Brak TLS 1.3: przy handshake’u oferującym TLS 1.3 wynegocjowano TLS 1.2. Pokazuję to w osobnej kolumnie jako „poniżej zalecanego poziomu” i nie liczę jako problemu. Serwisy obsługujące tylko TLS 1.0/1.1 nie nawiązują połączenia i tą metodą nie da się ich odróżnić od innych błędów (kolumna „akceptuje TLS 1.0/1.1” w Tabeli B pochodzi z osobnego, dodatkowego handshake’u i ma charakter pomocniczy).
• Liczby CVE są górnym oszacowaniem wyprowadzonym z ciągu wersji w nagłówku. Dystrybucje takie jak Debian i RHEL przenoszą poprawki (backport) bez zmiany numeru wersji, czego ta metoda nie widzi. CVE-2024-3566 dotyczy głównie przypadku specyficznego dla Windows, dlatego odsetek ekspozycji na RCE podaję także po jego wyłączeniu.

Wskaźnik wyszukiwań problemowych — skargi to niewielka mniejszość wyszukiwań

Spośród 3,178,854 podpowiedzi zwróconych dla samej nazwy marki 9,104 (0.29%) zawierało słowo problemowe. W 8,236 kombinacjach marka × region × wyszukiwarka z co najmniej 100 podpowiedziami dla zapytania prostego mediana wyniosła 0.0%, 90. percentyl 0.9%, 99. percentyl 3.0%, a maksimum 10.0% (BIDV SmartBanking w Wietnamie, Google). 5,169 kombinacji (62.8%) nie miało ani jednej podpowiedzi ze słowem problemowym.

Według krajów najwyższe wartości miały Irlandia (0.83%), Australia (0.76%), Holandia (0.63%), Nowa Zelandia (0.55%) i Wielka Brytania (0.54%); najniższe Hongkong (0.02%), ZEA (0.04%), Chile (0.08%) i Portugalia (0.08%). Japonia miała 0.28% (z 549,558 podpowiedzi dla zapytania prostego), co dało jej 21. miejsce na 41 krajów. Ponieważ zachowanie podpowiedzi i słownictwo problemowe różnią się między językami, różnice między krajami mają jedynie charakter orientacyjny.

W Japonii (Google) najwyższe wskaźniki miały Wi-Fi (4.1%), au Hikari (3.7%), docomo Hikari (3.7%), OCN (3.4%), Ekinet (3.1%), SoftBank Hikari (3.0%), Rakuten Mobile (2.7%), BIGLOBE (2.7%) i NURO Hikari (2.5%) — lista dostawców internetu stacjonarnego i operatorów komórkowych. Wśród marek płatniczych i bankowych prowadziły Rakuten Pay (2.3%), Vandle Card (2.2%), Rakuten Card (2.0%), QUICPay (1.9%) i d-Barai (1.8%), wszystkie w okolicach 2%.

Słowa problemowe dopasowywałem z uwzględnieniem granic słów, w każdej podpowiedzi po usunięciu nazwy marki (metodę dopasowania zmieniłem 27 października 2026 i wszystkie wartości w tym artykule pochodzą z okresu po tej zmianie).

Wysoki wskaźnik wyszukiwań problemowych to nie podatność — NURO Hikari i menu

Dla dwóch japońskich usług, których podpowiedzi zawierają słowa problemowe, zestawiam same podpowiedzi z obserwacją publicznej konfiguracji z tego samego okresu. Słowo problemowe w podpowiedzi nie oznacza, że usługa została zatrzymana przez podatność lub włamanie. Usterki łącza, awarie systemów, prace serwisowe i błędy aplikacji — problemy niezwiązane z podatnościami — wyszukuje się tymi samymi słowami, a moment zbierania podpowiedzi nie pokrywa się z momentem obserwacji.

NURO Hikari przyciąga wyszukiwania typu „nie łączy”, jak przystało na usługę dostępu do internetu, a mimo to jego publiczna konfiguracja nie wykazała luk: problemy użytkowników powstają na łączu lub w domowym sprzęcie, czyli w innej warstwie niż ustawienia serwisu. Udział słów problemowych dla menu jest niski; zamiast tego pojawiają się podpowiedzi takie jak „usługa zakończona” i „wycofanie”, a serwis zwrócił 502 przy obu obserwacjach. W żadnym z tych przypadków słowa problemowe w podpowiedziach nie odpowiadają lukom w konfiguracji. Wskaźnik wyszukiwań problemowych pokazuje, z czym użytkownicy się zmagają, gdy czegoś szukają; nie jest wskaźnikiem słabości zabezpieczeń.

W tych danych nie było widocznego związku między wskaźnikiem wyszukiwań problemowych a tym, czy serwis miał problemy konfiguracyjne (Rysunek 2). Jak wyjaśnia §2, obie wielkości są ustalane w różnym czasie i mają różne przyczyny. Badanie podpowiedzi służy więc jako operat losowania — „usługi często wymieniane w wyszukiwaniach dotyczących płatności, banków i handlu” — a §4–§6 opisują konfigurację tej próby.

Stan zabezpieczeń

Według kategorii (680 hostów)

Kategoria każdego hosta to najczęstszy segment wśród wierszy marka × region × wyszukiwarka, które na niego wskazują; 40 hostów spoza tych czterech segmentów („inne”) pominąłem w tabeli.

Łącznie dla płatności i banków 71 z 269 hostów (26.4%) miało problemy: 54 (20.1%) nie miały HSTS, a 25 (9.3%) ujawniało wersję; 44 (16.4%) nie wynegocjowały TLS 1.3. To mniej niż w handlu (39.3%) i usługach codziennych (36.3%), więc serwisy płatnicze i bankowe są skonfigurowane stosunkowo dobrze — a jednak co czwarty ma lukę, a co piąty nie ma HSTS.

Według regionu

Region oznacza kraj samego hosta (ustalany na podstawie domen krajowych i podobnych przesłanek), a nie region, w którym wyszukiwano markę. 292 z 680 hostów (42.9%) używa domen .com lub innych, dla których nie da się ustalić kraju; pokazuję je w osobnym wierszu. 17 krajów UE to Niemcy, Francja, Włochy, Hiszpania, Holandia, Belgia, Austria, Portugalia, Irlandia, Szwecja, Dania, Finlandia, Polska, Czechy, Grecja, Węgry i Rumunia.

Tylko Stany Zjednoczone (83) mają 20 lub więcej hostów; dalej są Wietnam (18, w tym 11 z problemami), Japonia (18, w tym 8 z problemami) i Włochy (16, w tym 8 z problemami). Przy tak małych próbach nie tworzę rankingu krajów.

18 japońskich hostów to głównie domeny .jp. Osiem miało problemy i we wszystkich przypadkach był to brak HSTS (povo, LINEMO, IIJmio, TVer, NHK, Qoo10, PayID, Alipay). Żaden japoński host nie ujawniał wersji i nie znaleziono PHP po końcu wsparcia ani wersji z zakresu CVE typu RCE.

Banki i usługi płatnicze wypadają dobrze — dobre przykłady (Tabela A)

Kryteria wyboru: w kolejności malejącej ekspozycji w wyszukiwaniach (liczby podpowiedzi dla zapytania prostego) usługi, które połączyły się przez TLS 1.3, wysyłały HSTS i nie ujawniały wersji serwera. Wymieniam 19, których przypisanie hosta do marki potwierdziłem niezależnie ja i dostawca danych, od najczęściej wyszukiwanych. Z Japonii pochodzą PASMO, JCB Card i BitCash.

Transgraniczne usługi płatnicze — PayPal, Stripe, Wise, Klarna, Venmo, Paytm, PhonePe — spełniły wszystkie trzy warunki. Nie oznacza to, że ich bezpieczeństwo jest „wystarczające”; oznacza, że trzy widoczne z zewnątrz ustawienia bazowe nie miały luk.

Serwisy z zaobserwowanymi problemami (Tabela B)

Kryteria wyboru: dla każdego kraju, w kolejności malejącej ekspozycji w wyszukiwaniach, usługi, w których zaobserwowano brak HSTS, ujawnioną wersję lub wersję po końcu wsparcia. Wymieniam 99, których przypisanie hosta do marki potwierdziłem ja i dostawca danych, według kraju i ekspozycji w wyszukiwaniach. Wykluczyłem siedemdziesiąt cztery wiersze z błędną identyfikacją automatyczną (na przykład „Hello bank” przypisany do niepowiązanego serwisu o podobnej nazwie albo „SMBC Nikko Securities” przypisany do serwisu banku). Marki wyszukiwane w regionie innym niż macierzysty (Commerzbank, Morrisons, Jean Coutu, Qantas) podaję pod ich krajem macierzystym. Adresy URL podaję jako zwykły tekst, a nie linki. Każdy wiersz to obserwacja z podanego momentu; ustawienie mogło zostać od tego czasu poprawione.

Wszystkie siedem japońskich pozycji nie ma HSTS i żadna nie ujawnia wersji; Alipay i Qoo10 dodatkowo akceptowały połączenia TLS 1.0/1.1. PHP po końcu wsparcia pojawiło się w dwóch serwisach — ACI we Włoszech (klub automobilowy, 7.4.33) i TPG w Australii (telekomunikacja, 7.4.33) — żaden z nich nie jest usługą płatniczą ani bankową.

Reakcja na podatność PHP — zero wersji po końcu wsparcia wśród serwisów płatniczych i bankowych

Tak wypada 1,705 nowo zaobserwowanych hostów wobec krytycznej podatności PHP z 2026 roku (CVSS 9.8), omówionej w artykułach A CVSS 9.8 PHP Vulnerability Was Published. Did the World Patch It? oraz Security Exposure Survey 2026.

Przy zaledwie 18 hostach ujawniających PHP liczby bezwzględne mówią więcej niż odsetki. Trzynaście z 18 używa wersji z poprawkami z 2026 roku — nie ukrywają wersji, ale ją aktualizują. Trzy serwisy z wersją po końcu wsparcia to włoski klub automobilowy, australijski operator telekomunikacyjny i peruwiańska instytucja ubezpieczeń społecznych; żaden nie jest usługą płatniczą ani bankową. To wyraźny kontrast z ogólnymi japońskimi serwisami z Security Exposure Survey 2026, gdzie 52.3% serwisów ujawniających PHP pokazywało wersję po końcu wsparcia.

Ograniczenia i zastrzeżenia

• Obserwacja nieinwazyjna: jedno zapytanie DNS, jeden handshake TLS i jedno żądanie HTTP GET na serwis (plus jeden dodatkowy handshake dla kolumny TLS 1.0/1.1 w Tabeli B). Nie podjęto żadnej próby ataku.
• Dane o ekspozycji to górne oszacowania; stary ciąg wersji może już mieć załatane luki dzięki backportom.
• Identyfikacja marki i serwisu była automatyczna: ręczne sprawdzenie wszystkich 920 hostów wykazało 212 (23.0%) błędnie zidentyfikowanych i 28 nierozstrzygalnych. Zestawienia oraz Tabele A i B używają wyłącznie 680 hostów, które przeszły weryfikację, ale także ręczna kontrola może przeoczyć błędy.
• Podpowiedzi jedynie przybliżają popyt. Różnią się w zależności od regionu, języka i czasu, a ta sama marka daje inne propozycje w Google i w Bing. Słownictwo problemowe zdefiniowałem osobno dla każdego języka i nie jest ono wyczerpujące.
• Niektóre kraje mają małe próby. Japonia ma 18 hostów; jej odsetki są orientacyjne i podaję je wraz z liczbami. Nie tworzę rankingu krajów.
• Terminy się różnią: podpowiedzi zbierałem 24–26 października, obserwacje prowadziłem 22–26 października.
• CSP, atrybuty cookie i certyfikaty nie są tu omawiane (zob. Security Exposure Survey 2026).

Co powinni sprawdzić operatorzy

1. Włącz HSTS. Brakowało go w 20.1% serwisów płatniczych i bankowych. Zwracanie Strict-Transport-Security: max-age=31536000; includeSubDomains przypina do HTTPS użytkowników, którzy próbują wejść przez HTTP.
2. Włącz TLS 1.3 i wyłącz TLS 1.0/1.1. 16.4% serwisów płatniczych i bankowych zatrzymało się na TLS 1.2.
3. Ukryj wersje serwera (expose_php = Off, ServerTokens Prod, server_tokens off) — po aktualizacji.
4. Wymień wersje po końcu wsparcia. W przypadku PHP przejdź na 8.3 lub nowszą oraz na wydania z poprawkami z 2026 roku (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) lub nowsze. Procedurę krok po kroku opisuje How to upgrade PHP in practice.
5. Sprawdź własny serwis. Wpisz adres URL w Sprawdzenie informacji o serwerze (/server/) w Site Scouter, aby tą samą metodą co w tym artykule zobaczyć, co Twój serwer pokazuje światu zewnętrznemu (TLS, HSTS, nagłówki serwera, certyfikat, atrybuty cookie) — w około dziesięć sekund. Bez rejestracji.

Powiązane: A CVSS 9.8 PHP Vulnerability Was Published. Did the World Patch It? (blog autora) / Security Exposure Survey 2026 (Site Scouter)

FAQ

Czy to był atak?

Nie. Każdy serwis otrzymał taki sam dostęp, jak przy jednorazowym otwarciu go w przeglądarce, a wykorzystałem wyłącznie publiczne odpowiedzi HTTP i dane DNS.

Czy usługi z Tabeli B są niebezpieczne?

Tabela B wymienia luki w konfiguracji widoczne z informacji publicznych w podanym momencie; nie dowodzi, że którykolwiek serwis da się włamać. Brak nagłówka HSTS czy ujawniona wersja same w sobie nie powodują wycieku danych; to luki, których skutki rosną w połączeniu z innymi warunkami.

Dlaczego podaję nazwy?

Faktami są ustawienia TLS i nagłówki HTTP — informacje publiczne, które każdy może odtworzyć tymi samymi krokami. Atakujący już je znają, więc publikacja niewiele zwiększa ryzyko, a użytkownicy i operatorzy zyskują wiedzę o stanie swoich usług. Przed publikacją nie wysyłałem wcześniejszych powiadomień.

Gdzie przesyłać pytania lub sprostowania?

Na dane kontaktowe autora podane na końcu tej strony. Jeśli ustawienie zostało poprawione po obserwacji, ponownie je zaobserwuję i dodam adnotację.

Czy dane były zmieniane?

Podpowiedzi dopisywałem przy każdym pobraniu, a wyniki obserwacji zapisywałem w tabeli tylko do dopisywania. Podczas agregacji zmieniłem metodę dopasowania dla wskaźnika wyszukiwań problemowych (§3) i przeliczyłem wskaźnik; artykuł używa przeliczonych wartości, a wartości sprzed korekty nie są publikowane.

Źródła

Ostatnio sprawdzono: 2026-10-28. Specyfikacje i zasady mogą się zmieniać; przed podjęciem działań sprawdź źródła pierwotne.

• MDN: Strict-Transport-Security
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• PHP: Supported Versions (php.net)
• NVD - National Vulnerability Database (NIST)
• Egosaru (search suggestion tool)