Когда вендор сделал веб-интерфейс, который "спрятал" запросы от devtools 😈
Недавно я столкнулся с интересной ситуацией на одном из проектов. Наш вендор разрабатывал веб-интерфейс для взаимодействия с сервером, и реализовал его так, что в DevTools (инструменты разработчика в браузере) вообще не отображаются HTTP-запросы. Сначала это вызвало удивление, а потом и восхищение — оказалось, что всё общение с сервером было реализовано через WebSocket.
Вместо традиционных HTTP-запросов (GET, POST и т.д.), все данные передавались через WebSocket-соединение. Это значит, что вкладка "Network" в DevTools оставалась пустой, так как она по умолчанию отображает только HTTP/HTTPS-трафик. WebSocket-сообщения, если кто не знает, можно увидеть только во вкладке "WS" (WebSocket), но даже там не всегда легко разобраться, что именно передается, особенно если данные зашифрованы или упакованы в бинарный формат.
Почему это интересно? 1. Производительность: WebSocket позволяет поддерживать постоянное соединение с сервером, что уменьшает задержки и накладные расходы на установку соединения для каждого запроса. 2. Скрытность: Отсутствие видимых запросов в DevTools может быть полезно с точки зрения безопасности, так как усложняет анализ трафика для потенциальных злоумышленников. 3. Реальнаяия в реальном времени: WebSocket идеально подходит для приложений, где важна мгновенная передача данных (чаты, уведомления, онлайн-игры).
Но как тестировать такие приложения? Столкнувшись с такой реализацией, я задумался: как же теперь тестировать и отлаживать такое приложение? Вот несколько подходов, которые могут помочь:
1. Использование вкладки "WS" в DevTools: Во вкладке "WebSocket" можно увидеть сообщения, которые передаются между клиентом и сервером. Однако, если данные зашифрованы или упакованы, их расшифровка может быть нетривиальной задачей.
2. Логирование на стороне сервера: Если у вас есть доступ к серверу, можно добавить логирование всех входящих и исходящих сообщений через WebSocket. Это поможет понять, что именно отправляется и принимается.
3. Прокси-инструменты: Инструменты вроде Fiddler или Charles Proxy могут перехватывать WebSocket-трафик. Они позволяют анализировать сообщения, даже если они зашифрованы (при условии, что у вас есть доступ к сертификатам).
4. Мокирование WebSocket-сообщений: Для тестирования можно создать мок-сервер, который будет имитировать WebSocket-соединение и отправлять заранее подготовленные сообщения. Это полезно для проверки реакции клиента на разные сценарии.
5. Инструменты для анализа WebSocket: Существуют специализированные инструменты, такие как wscat (для командной строки) или WebSocket King (онлайн-сервис), которые позволяют вручную отправлять и принимать WebSocket-сообщения.
6. Тестирование безопасности: Поскольку WebSocket-трафик может быть менее очевидным для стандартных инструментов анализа, важно уделить особое внимание тестированию на уязвимости, такие как инъекции через WebSocket или недостаточная проверка данных.
Вывод Реализация веб-интерфейса через WebSocket — это мощный подход, который может значительно улучшить производительность и пользовательский опыт. Однако, он требует особого внимания при тестировании и отладке. Если вы столкнулись с подобной реализацией, не пугайтесь — просто вооружитесь правильными инструментами и подходами.
А вы сталкивались с подобными кейсами? Как вы тестируете приложения, где основной трафик идёт через WebSocket? Делитесь опытом в комментариях!
