Безпека 920 платіжних і банківських сайтів, які шукають користувачі: 13.4 мільйона пошукових підказок у поєднанні з дослідженням Phase5

• У 48 регіонах і 20 мовах я зібрав 13.4 мільйона пошукових підказок (9.28 мільйона унікальних) для 3,472 брендів платіжних систем, банків, ритейлу та повсякденних сервісів і переглянув публічну конфігурацію 920 сайтів, на які вказують ці підказки, — по одному звичайному завантаженню сторінки на кожен. Потім кожну відповідність «бренд — сайт» перевірено вручну, і 680 сайтів, що пройшли перевірку, становлять основу всіх цифр цієї статті.
• Серед 269 платіжних і банківських сайтів 26.4% (71) мали принаймні одну з прогалин: немає HSTS, розкрито версію сервера або версія без підтримки. Найпоширеніша прогалина — відсутність HSTS (20.1%). 16.4% не узгодили TLS 1.3; усі сайти, що відповіли, використовували TLS 1.2 або новіший.
• Жоден платіжний чи банківський сайт не показував версію PHP без підтримки. Серед усіх 1,705 нових просканованих хостів лише 18 (9 сайтів, якщо рахувати apex і www разом) розкривали версію PHP, і 5 із них (3 сайти) мали версію без підтримки. Порівняно із загальною сукупністю в Дослідженні безпекової експозиції 2026 платіжні й банківські сайти або приховують версію, або підтримують її актуальною.
• Частка підказок зі словами на кшталт «збій», «оплата не пройшла» чи «не можу увійти» (частка проблемних запитів) становила 0.29% від 3.18 мільйона підказок, отриманих для самої назви бренду. Максимум для окремого бренду — 10.0%, а понад половина всіх брендів таких підказок не мали зовсім. Запити зі скаргами на збої серед підказок трапляються рідко.
• Поіменно названо двадцять хороших прикладів (таблиця A) і 92 сайти з виявленими проблемами (таблиця B). Таблиця B фіксує публічні факти — налаштування TLS і HTTP-заголовки — і не означає, що будь-який сайт визнано придатним до експлуатації вразливостей.

Ця стаття також опублікована англійською на sitescouter.net і nkzw.jp та японською на sitescouter.net. Це українська версія на Site Scouter, перекладена з англійської.

Методика

Ця стаття поєднує два дослідження (рис. 1).

1. Збір підказок (Egosaru). У 48 регіонах і 20 мовах я фіксував підказки, які показують Google, Bing, Yahoo!, Yandex, Naver, Baidu, Daum і Shopee, коли в пошуковий рядок вводять назву бренду. Використано два типи початкових запитів: сама назва бренду («простий запит») і назва бренду разом зі словом про проблему («складений запит»). Так утворилося 83,275 завдань отримання (83,016 виконано, 259 невдалих) і 13,438,498 підказок (9,280,238 унікальних), зібраних 24–26 жовтня 2026 року.
2. Спостереження публічної конфігурації (Site Scouter Phase5). Для брендів, що трапилися в підказках, я визначив їхні сайти (5,408 хостів-кандидатів, з яких 2,842 відповіли на DNS і HTTPS) і заново спостеріг 1,705 хостів, яких ще не було в попередньому дослідженні. Кожне спостереження складається з DNS-запиту, одного TLS-рукостискання та одного HTTP GET — так само, як один раз відкрити сайт у браузері. Жодного сканування портів, пошуку вразливостей, спроб автентифікації чи експлойт-трафіку не було. Спостереження тривали 22–26 жовтня 2026 року.
3. Обидва набори поєднано на рівні бренду, що дало 9,181 рядок «бренд × регіон × пошукова система» і 920 унікальних хостів. Потім кожен із 920 вручну перевірено, щоб підтвердити, що хост справді є офіційним сайтом бренду; 680 хостів, що пройшли перевірку, є знаменником для всієї статті (виключено 212 хибно ідентифікованих хостів і 28 хостів, які не вдалося визначити). Усі знаменники в цій статті — це кількість хостів.

Зіставлення бренду з сайтом виконувалося автоматично за точним (2,630) і частковим (2,778) збігом імен хостів, а такий підхід підхоплює сторонні сайти зі схожими назвами. Ручна перевірка всіх 920 хостів виявила 212 (23.0%), що не належали бренду (наприклад, «Hello bank» було зіставлено зі стороннім сайтом зі схожою назвою, а «SMBC Nikko Securities» — із сайтом банку), і 28, які не вдалося визначити. Помилки зосереджені навколо загальних назв брендів на кшталт «Easy», «Media» чи «Wi-Fi» та навколо сторонніх організацій з тією самою назвою. Агреговані дані в §4 і таблицях A та B спираються лише на 680 хостів, що пройшли цю перевірку. Виміряні налаштування виключених хостів самі по собі коректні, але їх відкинуто, бо приписані їм галузь і країна були хибними.

Визначення

• Частка проблемних запитів: серед підказок, отриманих для самої назви бренду, частка тих, що містять наперед визначене для кожної мови слово про проблему — «збій», «не працює», «оплата не пройшла», «не можу увійти», «застосунок не відкривається», «купон не діє» тощо. Це не означає, що відбувається збій. Показник приблизно відображає, наскільки активно користувачі шукають інформацію про проблеми.
• Слово про проблему в підказці не означає, що сервіс зупинився через вразливість чи вторгнення. Причини різні — від мережевих інцидентів і перевантаження до помилок самих користувачів і слідів минулих подій, а час збору підказок не збігається з часом спостереження безпеки. Показ обох даних поруч не стверджує ні кореляції, ні причинно-наслідкового зв'язку; він показує «конфігурацію на момент спостереження тих сервісів, які користувачі називають найчастіше».
• Проблема конфігурації (що в цій статті означає «має проблеми»): (1) немає заголовка HSTS (заголовка, що примусово переводить на HTTPS); (2) продукт або версію сервера видно ззовні; (3) розкрита версія не має підтримки або потрапляє в діапазон опублікованого CVE. Інтрузивного тестування не проводилося, і ніщо тут не стверджує, що сайт «справді можна зламати».
• Немає TLS 1.3: під час рукостискання, у якому пропонувався TLS 1.3, було узгоджено TLS 1.2. Це показано в окремій колонці як «нижче рекомендованого рівня» і не зараховується як проблема. Сайти, що підтримують лише TLS 1.0/1.1, не з'єднуються, і цим методом їх неможливо відрізнити від інших збоїв (колонка «приймає TLS 1.0/1.1» у таблиці B отримана з окремого додаткового рукостискання й наведена для довідки).
• Кількість CVE — це верхня межа, виведена з рядка версії в заголовку. Дистрибутиви, як-от Debian і RHEL, переносять виправлення у старі версії, не змінюючи номера версії, і цей метод такого не бачить. CVE-2024-3566 здебільшого стосується лише Windows, тому частку експозиції до RCE наведено також без нього.

Частка проблемних запитів — скарги становлять незначну меншість пошуків

З 3,178,854 підказок, отриманих для самої назви бренду, 9,104 (0.29%) містили слово про проблему. Серед 8,236 комбінацій «бренд × регіон × пошукова система», що мали щонайменше 100 підказок простого запиту, медіана становила 0.0%, 90-й процентиль — 0.9%, 99-й процентиль — 3.0%, а максимум — 10.0% (BIDV SmartBanking у В'єтнамі, Google). 5,169 комбінацій (62.8%) взагалі не мали підказок зі словами про проблеми.

За країнами найвищі показники мали Ірландія (0.83%), Австралія (0.76%), Нідерланди (0.63%), Нова Зеландія (0.55%) і Велика Британія (0.54%); найнижчі — Гонконг (0.02%), ОАЕ (0.04%), Чилі (0.08%) і Португалія (0.08%). Японія мала 0.28% (з 549,558 підказок простого запиту) і посіла 21-ше місце з 41 країни. Оскільки поведінка підказок і лексика проблем різняться залежно від мови, відмінності між країнами мають лише орієнтовний характер.

У Японії (Google) найвищі частки мали 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%) і NURO Hikari (2.5%) — суцільний перелік провайдерів широкосмугового та мобільного зв'язку. Серед платіжних і банківських брендів лідирували Rakuten Pay (2.3%), Vandle Card (2.2%), Rakuten Card (2.0%), QUICPay (1.9%) і d-Barai (1.8%) — усі на рівні близько 2%.

Слова про проблеми зіставлялися з урахуванням меж слів у кожній підказці після вилучення з неї назви бренду (метод зіставлення переглянуто 27 жовтня 2026 року, і всі значення в цій статті отримано вже після цього перегляду).

Висока частка проблемних запитів — не вразливість: NURO Hikari і menu

Для двох японських сервісів, у підказках яких трапляються слова про проблеми, наводимо самі підказки поруч зі спостереженням публічної конфігурації за той самий період. Слово про проблему в підказці не означає, що сервіс зупинився через вразливість чи вторгнення. Збої на лінії, системні збої, технічне обслуговування й помилки застосунків — проблеми, не пов'язані з вразливостями, — шукають тими самими словами, а час збору підказок не збігається з часом спостереження.

NURO Hikari, як і належить широкосмуговому сервісу, притягує запити на кшталт «не підключається», проте його публічна конфігурація не показала прогалин: проблеми користувачів виникають на лінії або в домашньому обладнанні, тобто на іншому рівні, ніж налаштування вебсайту. У menu частка слів про проблеми низька; натомість з'являються підказки на кшталт «сервіс припинено» та «видалення акаунта», а сайт повертав 502 під час обох спостережень. У жодному з випадків слова про проблеми в підказках не відповідають прогалинам конфігурації. Частка проблемних запитів показує, з чим користувачі мають труднощі, коли щось шукають; це не показник слабкості безпеки.

У цих даних не простежувався зв'язок між часткою проблемних запитів і наявністю в сайту проблем конфігурації (рис. 2). Як пояснено в §2, ці два показники визначаються в різний час і різними причинами. Тому дослідження підказок слугує основою вибірки — «сервіси, які часто називають у пошуках, пов'язаних із платежами, банками та ритейлом», — а §4–§6 описують конфігурацію цієї вибірки.

Стан безпеки

За категоріями (680 хостів)

Категорія кожного хоста — найчастіший сегмент серед рядків «бренд × регіон × пошукова система», що на нього вказують; 40 хостів поза цими чотирма сегментами («інше») до таблиці не включено.

Якщо взяти платежі й банки разом, 71 з 269 хостів (26.4%) мали проблеми: 54 (20.1%) не мали HSTS, а 25 (9.3%) розкривали версію; 44 (16.4%) не узгодили TLS 1.3. Це нижче, ніж у ритейлу (39.3%) і повсякденних сервісів (36.3%), тож платіжні та банківські сайти налаштовані порівняно добре — проте кожен четвертий має прогалину, а кожен п'ятий не має HSTS.

За регіонами

Регіон означає країну самого хоста (визначену за доменами з кодом країни тощо), а не регіон, у якому шукали бренд. 292 з 680 хостів (42.9%) використовують .com або інші домени, країну яких визначити неможливо; їх показано окремим рядком. 17 країн ЄС — це Німеччина, Франція, Італія, Іспанія, Нідерланди, Бельгія, Австрія, Португалія, Ірландія, Швеція, Данія, Фінляндія, Польща, Чехія, Греція, Угорщина та Румунія.

Лише США (83) мають 20 або більше хостів; далі йдуть В'єтнам (18, з них 11 з проблемами), Японія (18, з них 8 з проблемами) та Італія (16, з них 8 з проблемами). За таких малих вибірок країни не ранжуються.

18 японських хостів — здебільшого домени .jp. Вісім із них мали проблеми, і в усіх випадках це відсутність HSTS (povo, LINEMO, IIJmio, TVer, NHK, Qoo10, PayID, Alipay). Жоден японський хост не розкривав версію, і не знайдено ні PHP без підтримки, ні версії в діапазоні RCE CVE.

Банки й платіжні сервіси тримають рівень — хороші приклади (таблиця A)

Критерії відбору: за спаданням пошукової видимості (кількості підказок простого запиту) — сервіси, що з'єдналися через TLS 1.3, надсилали HSTS і не розкривали версію сервера. Наведено 19 сервісів, для яких відповідність «хост — бренд» незалежно підтвердили я і постачальник даних, у порядку від найпопулярніших у пошуку. Від Японії до списку потрапили PASMO, JCB Card і BitCash.

Транскордонні платіжні сервіси — PayPal, Stripe, Wise, Klarna, Venmo, Paytm, PhonePe — усі відповідали трьом умовам. Це не означає, що їхня безпека «достатня»; це означає, що три базові налаштування, видимі ззовні, не мали прогалин.

Сервіси з виявленими проблемами (таблиця B)

Критерії відбору: для кожної країни, за спаданням пошукової видимості, — сервіси, у яких виявлено відсутність HSTS, розкриту версію або версію без підтримки. Наведено 99 сервісів, для яких відповідність «хост — бренд» підтвердили я і постачальник даних, упорядкованих за країнами та пошуковою видимістю. Сімдесят чотири рядки з хибною автоматичною ідентифікацією (наприклад, «Hello bank» було зіставлено зі стороннім сайтом зі схожою назвою, а «SMBC Nikko Securities» — із сайтом банку) виключено. Бренди, які шукали в іншому регіоні, ніж їхній домашній (Commerzbank, Morrisons, Jean Coutu, Qantas), наведено під їхньою домашньою країною. URL подано як звичайний текст, а не як посилання. Кожен рядок — це спостереження в зазначений час; відтоді налаштування могли виправити.

Усі сім японських записів не мають HSTS, і жоден не розкриває версію; Alipay і Qoo10 до того ж приймали з'єднання TLS 1.0/1.1. PHP без підтримки виявлено на двох сайтах — ACI в Італії (автомобільний клуб, 7.4.33) і TPG в Австралії (телеком, 7.4.33), — і жоден із них не є платіжним чи банківським сервісом.

Реакція на вразливість PHP — жодної версії без підтримки серед платіжних і банківських сайтів

Ось як 1,705 нових спостережених хостів виглядають на тлі критичної вразливості PHP 2026 року (CVSS 9.8), розглянутої в статтях Опубліковано вразливість PHP із CVSS 9.8. Чи встиг світ її закрити? і Дослідження безпекової експозиції 2026.

Оскільки версію PHP розкривають лише 18 хостів, абсолютні числа змістовніші за частки. Тринадцять із 18 працюють на виправленій версії 2026 року — вони не приховують версію, але оновлюються. Три сайти без підтримки — це італійський автомобільний клуб, австралійський телеком і перуанське агентство соціального страхування; жоден із них не є платіжним чи банківським сервісом. Це різко контрастує із загальними японськими сайтами в Дослідженні безпекової експозиції 2026, де 52.3% сайтів, що розкривають версію PHP, показували версію без підтримки.

Обмеження та застереження

• Неінтрузивне спостереження: один DNS-запит, одне TLS-рукостискання та один HTTP GET на сайт (плюс одне додаткове рукостискання для колонки TLS 1.0/1.1 у таблиці B). Жодних спроб атаки не здійснювалося.
• Показники експозиції — це верхні межі; стара версія могла вже бути виправлена перенесеними виправленнями.
• Ідентифікація «бренд — сайт» була автоматичною: ручна перевірка всіх 920 хостів виявила 212 (23.0%) хибно ідентифікованих і 28 невизначених. Агреговані дані й таблиці A та B спираються лише на 680 хостів, що пройшли перевірку, але й ручна перевірка може пропустити помилки.
• Підказки лише приблизно відображають попит. Вони різняться залежно від регіону, мови та часу, а той самий бренд дає різні варіанти в Google і Bing. Лексику проблем визначено для кожної мови окремо, і вона не вичерпна.
• Для деяких країн вибірки малі. У Японії 18 хостів; її частки орієнтовні й наведені разом з абсолютними числами. Країни не ранжуються.
• Час різниться: підказки зібрано 24–26 жовтня, спостереження проведено 22–26 жовтня.
• CSP, атрибути cookie та сертифікати тут не розглядаються (див. Дослідження безпекової експозиції 2026).

Що варто перевірити операторам сайтів

1. Увімкніть HSTS. Його не мали 20.1% платіжних і банківських сайтів. Відповідь із заголовком Strict-Transport-Security: max-age=31536000; includeSubDomains закріплює за HTTPS користувачів, які намагаються зайти через HTTP.
2. Увімкніть TLS 1.3 і вимкніть TLS 1.0/1.1. 16.4% платіжних і банківських сайтів зупинилися на TLS 1.2.
3. Приховайте версії сервера (expose_php = Off, ServerTokens Prod, server_tokens off) — після оновлення.
4. Замініть версії без підтримки. Для PHP перейдіть на 8.3 або новішу та на виправлені випуски 2026 року (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) чи новіші. Покрокову процедуру описано в статті Як оновити PHP на практиці.
5. Перевірте власний сайт. Введіть URL у Перевірку інформації про сервер (/server/) від Site Scouter, щоб приблизно за десять секунд побачити тим самим методом, що й у цій статті, що ваш сервер показує зовнішньому світу (TLS, HSTS, серверні заголовки, сертифікат, атрибути cookie). Реєстрація не потрібна.

Пов'язані матеріали: Опубліковано вразливість PHP із CVSS 9.8. Чи встиг світ її закрити? (блог автора) / Дослідження безпекової експозиції 2026 (Site Scouter)

Поширені запитання

Це атака?

Ні. Кожен сайт отримав такий самий доступ, як під час одного відкриття в браузері, і використовувалися лише публічні HTTP-відповіді та дані DNS.

Чи небезпечні сервіси з таблиці B?

Таблиця B перелічує прогалини конфігурації, які можна було спостерігати з публічної інформації в зазначений час; вона не встановлює, що будь-який сайт можна зламати. Відсутній заголовок HSTS чи розкрита версія самі по собі не призводять до витоку даних; це прогалини, вплив яких зростає в поєднанні з іншими умовами.

Навіщо їх називати?

Факти — це налаштування TLS і HTTP-заголовки, тобто публічна інформація, яку будь-хто може відтворити тими самими кроками. Зловмисники вже її знають, тож публікація додає мало ризику, тоді як користувачі й оператори отримують користь від знання стану своїх сервісів. Попередніх повідомлень перед публікацією не надсилалося.

Куди надсилати запитання чи виправлення?

На контакти автора наприкінці цієї сторінки. Якщо налаштування виправлено після спостереження, я проведу повторне спостереження й додам примітку.

Чи змінювалися дані?

Підказки додавалися за кожним отриманням, а результати спостережень зберігалися в таблиці, до якої дані лише додаються. Під час агрегації метод зіставлення для частки проблемних запитів переглянуто (§3), а частку перераховано; у статті використано перераховані значення, а значення до виправлення не публікуються.

Джерела

Остання перевірка: 2026-10-28. Специфікації та правила можуть змінюватися; перш ніж діяти, звіртеся з першоджерелами.

• 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)