WebSocket і локальні порти: як антифрод виявляє ознаки середовища

WebSocket локальні порти означають канал, через який сайт може непрямо оцінити сервіси на localhost за часом відповіді. Його використовують, щоб помітити відкриті налагоджувальні порти, локальні агенти, proxy-клієнти або сліди автоматизації.

Для команд, які працюють з кількома профілями, ця тема стоїть поруч із перевіркою WebRTC-витоків і UDP-поведінки. Зовнішній IP і проксі можуть виглядати акуратно, але браузер усе одно залишається процесом на локальній машині. Якщо сторінка бачить непрямі ознаки цього середовища, цифровий відбиток стає ширшим за Canvas, WebGL і User-Agent.

Саме тому WebSocket timing attack варто розглядати як частину браузерного fingerprinting. Він не читає файли, не отримує список процесів і не показує назву програми. Але він може дати сигнал: порт швидко відмовив, відповів із затримкою або взагалі завис до timeout. У поєднанні з Canvas, WebGL і video fingerprinting та поведінковими метриками такий сигнал допомагає антифроду оцінювати середовище сесії.

Окремо стоїть порт 9222, який часто асоціюють із Chrome DevTools Protocol. Якщо в браузері активовано віддалене керування через CDP, а сайт фіксує нетипову часову різницю на цьому порту, це може стати додатковим сигналом середовища. Для розуміння суміжних витоків корисно тримати поруч матеріал про CDP-витоки Puppeteer, бо обидві теми стосуються не зовнішнього IP, а того, як автоматизація проявляється всередині браузерного середовища.

Чому вебсторінка може звертатися до локальної адреси

Вебсторінка може створити WebSocket-з'єднання не тільки до віддаленого сервера, а й до адреси на кшталт 127.0.0.1 або localhost. Це не означає, що сайт автоматично читає локальні дані. Суть у спробі встановити з'єднання і виміряти час до браузерної події помилки, який може непрямо залежати від мережевого стану локального порту.

WebSocket був створений для постійного двостороннього зв'язку: чати, біржові графіки, live-статуси, ігри в браузері. На старті браузер робить TCP-з'єднання, надсилає HTTP Upgrade і чекає, чи сервер погодиться перейти в WebSocket-протокол. Якщо адресою є localhost, трафік не виходить у зовнішню мережу. Він іде в loopback-інтерфейс тієї самої операційної системи.

Проблема в тому, що навіть невдала спроба дає побічну інформацію. Сторінка не повинна бачити відповідь MySQL, SSH або локального проксі. І за нормальної моделі безпеки вона її не бачить. Але JavaScript може фіксувати різницю в часі до події помилки. На неї можуть впливати швидка відмова ОС, встановлення TCP-з'єднання з подальшою невдачею WebSocket Upgrade або довший timeout.

Це не класичне сканування портів у стилі nmap. Браузерний скрипт не має сирого доступу до TCP-пакетів, не бачить SYN/ACK напряму і не отримує банер сервісу. Він працює грубіше: пробує кілька портів, фіксує час до події onerror і порівнює результат із базовим значенням.

Для антифрод-системи локальний таймінг набуває значення в поєднанні з іншими ознаками. Якщо в сесії одночасно видно підозрілий User-Agent, нетиповий WebGL renderer, нестабільний IP і таймінг, схожий на відкритий CDP-порт, сукупність сигналів може вплинути на оцінку ризику.

Як час відповіді допомагає оцінити стан порту

Часова атака WebSocket спирається на статистичні відмінності в часі помилки, які за певних умов можуть відповідати закритому, відкритому або відфільтрованому firewall порту. Сайт не читає локальний сервіс, а таймінг не дає гарантованої класифікації стану порту.

Типовий сценарій виглядає просто. Скрипт бере високоточний таймер, запускає new WebSocket("ws://127.0.0.1:9222"), чекає на помилку і рахує різницю. Далі він повторює спробу для кількох портів і порівнює їх із контрольним портом, який майже напевно закритий.

Умовний алгоритм перевірки такий:

1. виберіть контрольний високий порт, який не використовується локальними сервісами
2. виміряйте середній час помилки для цього контрольного порту
3. спробуйте WebSocket-з'єднання з портами, які мають сенс для ризик-моделі
4. порівняйте затримку кожного порту з базовим значенням
5. відкиньте одиничні викиди, які могли з'явитися через навантаження процесора або garbage collection
6. передайте не сирий висновок, а скоринговий сигнал із рівнем впевненості

Цифри не варто читати як універсальний закон. На localhost закритий порт часто дає дуже швидку відмову, відкритий порт може відповідати помітно довше через TCP handshake і невдалий WebSocket Upgrade, а filtered-порт може чекати до системного timeout. Але точні мілісекунди залежать від ОС, браузера, навантаження процесора, політик таймера і того, що саме слухає порт.

Після таблиці легко зробити неправильний висновок: якщо порт відкритий, користувач винен. Насправді ні. Локальні порти відкривають легальні програми: IDE, Docker, VPN-клієнти, менеджери паролів, криптогаманці, корпоративні агенти безпеки. Технічний сигнал стає антифрод-ризиком лише в контексті всієї сесії.

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

Що обмежують браузери та операційні системи

Браузери обмежують доступ вебсторінки до локальних ресурсів кількома різними механізмами. Same-Origin Policy і CORS насамперед регулюють доступ до відповідей звичайних вебзапитів, Secure Context визначає доступність окремих можливостей, а Private Network Access додає перевірки для звернень до приватних мереж. Ці механізми не слід вважати однаковим захистом від WebSocket-таймінгів: час до браузерної події помилки за певних умов може залишатися побічним каналом.

Це важлива межа. Якщо сайт спробує прочитати відповідь локального HTTP-сервера через fetch, браузер має заблокувати доступ до тіла відповіді без потрібних CORS-заголовків. WebSocket працює інакше: сервер може перевіряти Origin. Але сам факт успішного або невдалого шляху до помилки все одно виникає.

Операційна система теж не завжди усуває такий побічний канал. Loopback-трафік не виходить за межі пристрою, а поведінка firewall щодо нього залежить від ОС і конфігурації. Правила DROP і REJECT також можуть створювати різні часові характеристики.

Коли Ви налаштовуєте захист, різниця між цими діями практична:

• REJECT зазвичай швидко повертає відмову, але конкретний таймінг залежить від ОС, firewall і мережевої конфігурації
• DROP може відкидати пакет без швидкої відповіді та спричиняти довший timeout
• повне блокування localhost може ламати легальні локальні агенти
• список дозволених сервісів зменшує шум, але потребує підтримки
• окреме середовище профілю краще ізолює локальні сервіси від браузерної сесії

Якщо у Вас кілька робочих ролей на одній машині, не варто відкривати все в одному звичайному браузері і сподіватися, що проксі вирішить локальні витоки. Проксі змінює зовнішній маршрут, але не прибирає локальний Docker daemon, CDP endpoint або корпоративний агент, який слухає порт на loopback.

Private Network Access частково закриває класичні сценарії доступу з публічних сайтів до приватних мережевих ресурсів. Але PNA не є універсальною відповіддю на timing side-channel. Якщо браузеру треба спробувати з'єднання, щоб потім відхилити його політикою, сама різниця часу може залишитися корисною для скорингу.

Для практичної безпеки це означає одне: не варто покладатися на один шар. Браузерна політика зменшує доступ до даних, firewall контролює реакцію ОС, а ізоляція середовища прибирає зайві локальні сервіси з поля зору робочої сесії.

Як такі сигнали можуть входити до антифроду

Антифрод може використовувати локальні WebSocket-таймінги як один із сигналів середовища. Конкретне використання залежить від платформи, її ризик-моделі та правил.

Сигнал локального порту потенційно може бути корисним у трьох ситуаціях:

1. система перевіряє ознаки автоматизації через CDP, Playwright, Puppeteer або Selenium
2. оцінює нетипове серверне середовище, де на localhost відкриті бази даних, SSH, панелі керування або локальні проксі
3. зіставляє нібито незалежні профілі за повторюваним набором локальних ознак

Тут WebSocket timing attack перетинається з темою headless browser detection. Headless-режим може мати помітні ознаки у WebDriver, canvas-параметрах або поведінці API. Локальний порт додає ще один шар: не те, як браузер малює сторінку, а те, що поруч із браузером працює на машині.

Умовний приклад того, як такий сигнал теоретично може виглядати в скоринговій системі:

Якщо кілька профілів із різними IP, cookies і fingerprint мають однаковий набір локальних портів, система оцінки ризику потенційно може врахувати повторюваний патерн як ознаку спільної інфраструктури.

Важливо враховувати не тільки браузер, а й мережевий маршрут. Якщо профілі працюють через різні проксі, але всі вони запускаються на одній машині з однаковими локальними сервісами, проксі не розділяє цей шар. Для QUIC, UDP і SOCKS5 це окрема тема, яку варто зіставити з матеріалом про UDP через SOCKS5 і маршрутизацію QUIC.

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

Як перевірити локальне середовище й зменшити витік даних

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

На macOS і Linux базову картину дають lsof -iTCP -sTCP:LISTEN -n -P або ss -ltnp. На Windows можна почати з netstat -ano і зіставити PID із процесами в Task Manager або PowerShell. Далі список треба не просто зберегти, а розділити на нормальні, службові й ризикові порти.

Практичний порядок аудиту такий:

1. перевірте список портів, що прослуховуються, перед запуском робочого браузера
2. закрийте IDE, локальні сервери, Docker-контейнери й debug-сесії, якщо вони не потрібні для завдання
3. переконайтеся, що CDP-порт не відкритий назовні без реальної потреби
4. обмежте доступ до непотрібних локальних сервісів за допомогою firewall і залиште доступними лише необхідні для роботи з’єднання
5. протестуйте один і той самий профіль у звичайному браузері та в ізольованому середовищі
6. повторіть вимірювання кілька разів, щоб відокремити стабільний сигнал від шуму
7. задокументуйте, які локальні агенти дозволені в командному SOP

У робочих процесах із багатьма акаунтами та сама логіка переходить у кластерний ризик. Один профіль із відкритим локальним портом може бути випадковістю. П'ятдесят профілів із однаковим набором локальних портів можуть вказувати на спільну інфраструктуру. Саме тут доречно згадати Sybil-детекцію і кластерний аналіз, бо системи оцінки ризику можуть враховувати не один окремий сигнал, а повторювану структуру ознак.

Що робити на практиці, якщо Ви керуєте командною інфраструктурою:

• розділяйте робочі ролі за окремими профілями й середовищами
• не запускайте automation-debugging у тому самому середовищі, де входите в важливі акаунти
• використовуйте список дозволених локальних агентів, які справді потрібні
• відрізняйте блокування від швидкої відмови, бо для таймінгу це різні сигнали
• фіксуйте зміни в SOP, щоб команда не відкривала випадкові порти перед робочою зміною
• перевіряйте не лише IP і fingerprint, а й локальний мережевий контур

Afina доречна в такому процесі як інфраструктура для ізольованих браузерних профілів, керування fingerprint-параметрами, проксі та командними доступами. Ізоляція профілів дає змогу розділяти cookies, сесії, налаштування проксі та робочі ролі, але не замінює аудит локальної ОС, firewall і сервісів на localhost. Матеріал надано виключно в ознайомчих та освітніх цілях.

Для командного SOP зручно тримати окремий чеклист: які локальні сервіси дозволені, які порти не мають бути відкриті перед запуском профілю, хто відповідає за оновлення правил firewall і де зберігаються результати тестів. Така документація допомагає відстежувати зміни середовища та аналізувати причини додаткових перевірок ризику для окремих профілів.

Скачати