Origin, TLS, and Proxies

## What actually happens when a page opens a socket A WebSocket connection begins life as a normal HTTP/1.1 request. The client sends a `GET` for the target path carrying `Upgrade: websocket`, `Connection: Upgrade`, a freshly generated `Sec-WebSocket-Key` and `Sec-WebSocket-Version: 13`. A server that accepts it answers `101 Switching Protocols` with the matching `Sec-WebSocket-Accept`, and from that moment the bytes on the connection are WebSocket frames rather than HTTP messages. Because the opening request is a real request aimed at your host, the browser dresses it the way it dresses any other: it fills in `Host`, and it attaches the cookies stored for that host. The one thing that may hold those cookies back is the cookie's own same-site attribute — a cookie the site marked for cross-site use is sent from any page, and a cookie restricted to same-site use is not. You cannot rely on that attribute being set the way you hope, and on the municipal parking-garage occupancy board the session cookie is exactly the credential an operator's console already holds. ## Why the browser does not refuse on your behalf For a scripted cross-origin HTTP request, browsers run a familiar dance: for some requests a preflight goes first, and the response is withheld from the calling script unless the server says that origin may read it. Two properties of that machinery matter here, and neither helps: - it protects the **response**, not the request — the request usually reaches your server either way; - it is defined for fetching HTTP resources, and a protocol upgrade is not one of them. `RFC 6455` took a different route. Rather than a response opt-in, it requires a **browser** client to include the `Origin` request field on the handshake and leaves the judgement entirely to the server: a server not intended to process input from any page **should** verify that field, and when it decides an origin is unacceptable it **must** reply with `403 Forbidden`. That is a decision the specification hands you; if you never wrote the check, you never had one. The result is the cross-site socket hijack. An operator signs into the occupancy console, then visits some other page in another tab. That page opens a socket to your server, the browser attaches the operator's cookie, your server completes the handshake, and the attacker's page now holds a live, authenticated, full-duplex channel into the board — able to read every occupancy update and to send whatever the console could send. ## Validate on the handshake, never after it The refusal has to land while the exchange is still HTTP: 1. read `Origin` from the upgrade request; 2. compare it whole — scheme, host and port together — against a short allowlist you control; 3. on a miss, answer `403 Forbidden` and never send the `101`. Accepting first and closing a moment later is worse than it looks. The handshake succeeded, so any per-connection setup your application does on open has already run; the refusal is now a WebSocket Close control frame rather than an HTTP status, which is harder to alert on; and your access log records a completed upgrade, so the attack does not show up as a rejection anywhere. Two details decide whether the check is real: - **Match the whole string.** A prefix or substring test against `https://console.example` also accepts `https://console.example.attacker.test`, which is a completely different registrable domain that an attacker can register today. - **Decide deliberately what an absent `Origin` means.** A non-browser client is not obliged to send one at all. Treating absence as "trusted" is a hole; treating it as "not a browser, so fall back to the credential check that actually authenticates" is a policy you can defend. ## What the check is and is not | | ordinary cross-origin request | WebSocket upgrade | |---|---|---| | who decides | the browser, from the response | the server, from the request | | what is consulted | the server's response opt-in | the `Origin` request field | | binds a non-browser client | no | no | | what a refusal looks like | the script cannot read the response | `403 Forbidden`, no `101` | The check is a **cross-site** defence: it stops a page the victim's own browser loaded from spending the victim's ambient credentials. It is not authentication, because only a browser is obliged to fill the field in honestly. Both properties are true at once, and an interviewer will usually ask for the second one the moment you have given the first. ## On the occupancy board The board's server keeps one allowlist entry — the operator console's origin — reads `Origin` on every upgrade, refuses everything else with `403 Forbidden`, and logs the refused value. The credential check still runs afterwards, because the `Origin` allowlist is the outer gate and not the lock.