[Thorrez]

> they totally bypass CORS

You can reimplement the Same Origin Policy serverside by checking that the Origin header equals the Host header. Even more secure would be to check both against an allowlist (this protects against DNS rebinding, which the Same Origin Policy doesn't protect against).

>as well as other browser built-in protections

I'm curious what those are.

>for most use cases require to implement many features by yourself: [...] authorization

Isn't auth of websockets generally the same as auth of any Javascript-initiated HTTP request (e.g. fetch())? Check that the cookie looks good? Now, in the cause of OAuth tokens, websockets are more difficult than fetch(), because you cannot attach an Authorization: Bearer header to a websocket. But OAuth is less common than cookies for websites.

[kdunglas]

Once the connection is upgraded, you loose all metadata included in the HTTP headers (because it’s not HTTP) and all protections relying on it. Also CORS and SOP can be bypassed: https://dev.to/pssingh21/websockets-bypassing-sop-cors-5ajm

Even very experienced teams make mistake with this kind of things. See for instance, this Kubernetes vulnerability: https://goteleport.com/blog/kubernetes-websocket-upgrade-sec...

Of course you can reimplement everything by hand (and you must if you use WebSockets), but with SSE/Mercure you don't have to because it's plain old HTTP.

[whilenot-dev]

> Once the connection is upgraded, you loose all metadata included in the HTTP headers (because it’s not HTTP) and all protections relying on it.

The Upgrade request is HTTP and you can extract all needed metadata from there and store it server side as needed. Those metadata wouldn't change during an active WebSocket session anyway, would they?

[matharmin]

With your own native client: Yes, you can send arbitrary headers in the Upgrade request.

In a browser however, you can't. It typically sets very little headers itself, and doesn't allow you to add custom headers.

[whilenot-dev]

The auth headers (Authorization, Cookie) are all passed along, and that's what I want to establish a secure connection from the browser.

For more customized wishes there's always this "ticket"-based flow[0][1] that shouldn't be hard to implement. I might be a bit naive, but what needed metadata and custom headers are we talking about?

[0]: https://devcenter.heroku.com/articles/websocket-security#aut...

[1]: https://lucumr.pocoo.org/2012/9/24/websockets-101/#authoriza...

[Thorrez]

>Also CORS and SOP can be bypassed: https://dev.to/pssingh21/websockets-bypassing-sop-cors-5ajm

Like I said, you can reimplement SOP by checking that the Origin header equals the Host header. Or alternatively check them against an allowlist. It's just a couple lines of code, and then it's as secure as normal HTTP.

https://dev.to/pssingh21/websockets-bypassing-sop-cors-5ajm

That article contains a confusing quote:

>The initial handshake occurs via HTTP Upgrade request, the response body is disregarded and the HTTP/HTTPS protocol is upgraded to WS/WSS protocol.

But the response body isn't disregarded. What could best be described as the response body is the server->client websocket messages. Those aren't disregarded.

>Even very experienced teams make mistake with this kind of things. See for instance, this Kubernetes vulnerability: https://goteleport.com/blog/kubernetes-websocket-upgrade-sec...

Thanks, that's an interesting vulnerability. I'm not so sure it's websocket-specific though. It looks like the attack could be done without websockets at all. The end request that does the malicious action is plain HTTP. The initial request that triggers the desync uses a Connection: Upgrade header, which is used in websockets, but isn't actually websocket-specific. Connection: Upgrade was created in RFC 2616 from 1999, which was before the websocket RFC 6455 in 2011.

The vulnerability was there was a proxy, and the proxy didn't properly handle the Connection header as specified in RFC 2616. RFC 2616 says that a proxy must remove the Connection header if it's not handling it itself, and the proxy in this case wasn't handling it itself (not checking for 101 response).

I would say this vulnerability is an HTTP request smuggling vulnerability. That's a vulnerability where there's a proxy that implements some type of security, and the proxy can be tricked into sending a request to the backend that the proxy didn't actually parse. HTTP request smuggling vulnerabilities impact regular HTTP, not just websockets. This has nothing to do with the Same Origin Policy.

https://portswigger.net/web-security/request-smuggling

https://portswigger.net/research/http-desync-attacks-request...

[jand]

> ... because you cannot attach an Authorization: Bearer header to a websocket.

Well, not properly. You can abuse the Sec-Websocket-Protocol header to pass an initial token to the server.

[Thorrez]

:) I have in fact done that.