Як виникає витік через WebRTC

Антифрод-система не отримує вашу реальну IP-адресу окремим запитом. Вона порівнює дві адреси: адресу TCP-сесії та адресу, яку браузер повідомляє через WebRTC поверх UDP. Розбіжність між ними стає сигналом.

Механіка перевірки

Послідовність однакова для всіх трьох сценаріїв:

1. Браузер відкриває сторінку через SOCKS5-проксі. Увесь HTTP/HTTPS-трафік передається через TCP, тому сайт бачить IP-адресу проксі.
2. Антифрод-система передає сторінці скрипт, який створює RTCPeerConnection і вказує власний STUN- або TURN-сервер у iceServers.
3. Браузер починає збирати ICE-кандидатів і надсилає на цей сервер STUN Binding Request через UDP.
4. STUN-сервер повертає Binding Response з атрибутом XOR-MAPPED-ADDRESS. У ньому вказана публічна адреса джерела пакета. Браузер перетворює її на srflx-кандидата.
5. Скрипт отримує кандидата через onicecandidate, дістає з нього IP-адресу та порівнює її з адресою TCP-сесії.

Ключовий момент: крок 3. Чи пройде UDP-пакет через проксі, залежить від двох умов: чи підтримує проксі UDP і чи вміє браузер спрямовувати UDP через цей проксі. Звідси виникають три можливі результати.

Сценарій 1. Проксі передає UDP, адреси збігаються

1. TCP-сесія проходить через SOCKS5-проксі, тому сайт бачить 198.51.100.7.
2. Антифрод-система передає скрипт із налаштуваннями свого STUN-сервера.
3. Браузер відкриває UDP-асоціацію через той самий проксі (UDP ASSOCIATE, RFC 1928) і надсилає Binding Request через нього.
4. STUN бачить адресу проксі та повертає те саме значення в XOR-MAPPED-ADDRESS: 198.51.100.7.
5. Скрипт порівнює значення. IP-адреса TCP-сесії та srflx-кандидат збігаються.

Результат: WebRTC працює штатно, кандидати доступні, а адреси збігаються. На мережевому рівні профіль поводиться як звичайний користувач.

Для цього одночасно потрібні дві умови: проксі з підтримкою UDP ASSOCIATE і клієнт, наприклад браузер або антидетект-браузер, який справді спрямовує WebRTC-трафік через проксі.

---

Сценарій 2. UDP обходить проксі та розкриває реальну адресу

1. TCP-сесія проходить через проксі, тому сайт бачить 198.51.100.7.
2. Антифрод-система передає скрипт із налаштуваннями свого STUN-сервера.
3. Браузер надсилає Binding Request безпосередньо з мережевого інтерфейсу, оминаючи проксі.
4. STUN бачить реальну адресу 113.22.13.2 і повертає її як srflx-кандидата.
5. Скрипт порівнює значення: 113.22.13.2 ≠ 198.51.100.7. Проксі виявлено, реальну IP-адресу розкрито.

Результат: витік IP-адреси. Антифрод-система отримує конкретну адресу, а не лише підозрілу ознаку.

UDP може обходити проксі з кількох причин:

• проксі підтримує лише TCP: HTTP-проксі через CONNECT передає тільки TCP, як і SOCKS5 без UDP ASSOCIATE;
• проксі підтримує UDP, але браузер не спрямовує UDP через нього: Chrome за замовчуванням не передає WebRTC-трафік через налаштований проксі та надсилає його безпосередньо;
• проксі налаштований лише для конкретного профілю або розширення, а WebRTC працює на рівні всього процесу.

Якщо антифрод-система контролює STUN/TURN-сервер, зазначений у iceServers, їй навіть не потрібен крок 5. Вона бачить реальну адресу безпосередньо в адресі джерела вхідного UDP-пакета.

Локальні адреси, наприклад 192.168.* і 10.*, тут менш важливі. Починаючи з Chrome 80, host-кандидати передаються як mDNS-імена на зразок <uuid>.local, тому отримати дані про локальну мережу через WebRTC стало складніше. У цьому сценарії розкривається саме публічна srflx-адреса.

---

Сценарій 3. Браузер блокує WebRTC: витоку немає, але це помітно

1. TCP-сесія проходить через проксі, тому сайт бачить 198.51.100.7.
2. Антифрод-система передає скрипт із налаштуваннями свого STUN-сервера.
3. RTCPeerConnection заблокований розширенням, налаштуванням браузера або зміненим API в антидетект-браузері. STUN-запит не надсилається ані через проксі, ані безпосередньо.
4. Відповіді немає. onicecandidate не спрацьовує, а збирання кандидатів завершується порожнім списком.
5. Скрипту немає чого порівнювати.

Результат: реальна IP-адреса не розкрита. Однак антифрод-система бачить іншу аномалію: сучасну настільну версію Chrome, у якій WebRTC повністю недоступний. У більшості звичайних користувачів WebRTC увімкнений, тому порожній список кандидатів може підвищити оцінку ризику, як і будь-яка інша невідповідність заявленого user-agent фактичній поведінці API.

Отже, вимкнення WebRTC замінює витік IP-адреси аномалією відбитка. У деяких випадках це прийнятний компроміс, але не повноцінне рішення.