R-WEB
websocat
A netcat-like CLI for connecting to and probing WebSocket endpoints by hand.
OVERVIEW
websocat (github.com/vi/websocat) is a command-line WebSocket client in the spirit of netcat: it opens a `ws://` or `wss://` connection and pipes stdin/stdout to the frames, so you can type a message and read the reply without a browser tab or a full proxy session in the way. That makes it the quick tool for a chat backend, a live-update API, or any endpoint that speaks WebSocket instead of plain HTTP.
Because it is scriptable, it also fits into a fuzzing loop — pipe a wordlist or a small generator script into websocat and read what comes back, or set `-t`/`-b` for text vs binary framing when the target is picky. For anything past a handful of manual probes, capture the traffic through an intercepting proxy that supports WebSocket (Burp, mitmproxy) so requests and responses land in the same evidence trail as the rest of the HTTP testing.
USE CASES
Practical use cases
- 01
Opening a WebSocket endpoint by hand to send a message and read the raw reply.
- 02
Replaying an authentication handshake captured from the browser to confirm it still works from the CLI.
- 03
Piping a small wordlist or payload set into a WebSocket endpoint as a manual fuzzing step.
- 04
Bridging a local TCP port to a remote WebSocket (or vice versa) to reach a service that only speaks one of the two.
QUICK START
When a web app in scope uses a WebSocket endpoint and you need to open, send, and read raw frames by hand instead of relying on the browser dev tools.
- Confirm the WebSocket endpoint and host are inside the authorized scope.
- Connect first with no payload to confirm the handshake and any required headers/cookies.
- Send a known-good message and compare the reply against what the browser produced.
- Move to scripted or fuzzed input only after the manual baseline matches, and stay inside the agreed rate.
websocat wss://target.example/wsBEFORE YOU RUN IT
What to check before running it
A WebSocket connection often skips the auth checks applied to the initial HTTP handshake — confirm you are not bypassing an access control by connecting directly instead of through the app flow.
Traffic against a production WebSocket service should respect the engagement’s agreed rate and scope; a scripted loop of messages is as disruptive as any other flood.
Captured frames can carry session tokens or personal data from other users if the service is shared — handle saved transcripts under the same rules as other engagement evidence.