dominics
commented
9 years ago There are a few issues here. Fundamentally, though, you can't ever ensure the sender is an anointed piece of downloaded JS running in the browser, versus a debugging console, versus a person sitting on a telnet console pretending to be a browser.
I wouldn't say allowing an arbitrary client to post "directly" to a websocket is inherently insecure. (Although, please don't attempt to write a hardened web application using this hobby server.) If someone is dedicated enough to emulate the websocket handshake, including the headers and key, then they're dedicated enough to emulate other parts of your client.
To mitigate this, if I was writing a hardened web application, yeah, I might like to have a write token provided through another channel (say, a regular old AJAX call) and require it to use the websocket API and channels and whatnot.
But I'd first have to accept connections, so that the client can provide their key. So, it's somewhat incorrect to say that "server side scripts only have access to write to the socket" - the TCP socket itself is still just as open and "insecure" (ceteris paribus firewalls, NAT, local networks) as it was before the write tokens: if there's a bug in my WriteTokenValidator I'm in trouble.
All that aside, I think it's probably pretty easy to implement this logic yourself in the server. But I think it's firmly in the domain of the application: I wouldn't want my server dictating anything about how I use the underlying technology beyond, you know, implementing WAMP or whatever.
Two final notes:
- If someone came up with a nice decoupled implementation PR, I'd be more than happy to merge it. But I don't otherwise see it being the direction we go. It hurts discoverability, may not be needed for some applications, etc. And if you never bind to a remotely-accessible interface in the first place, you just don't care.
- If you want to try to implement it, your hands are tied somewhat, because you can't assume anything about the server-side framework.
- This doesn't mean it's hard to do with Wrench. It's just always going to be much easier to subclass/control Wrench from your regular old server-side framework than it is going to be to build awareness of your framework into Wrench.
How about creating a "write key", similar to what pusher.js does with their websocket api. this means server side scripts only have access to write to the socket, preventing malicious users from submitting messages to the socket directly from the js console. It's pretty alarming that there isn't an open source library with this functionality, but i suppose it would be pretty easy to add on top of the basic server example, though i think it should be mandatory part of the library anyway. What do you think about it? There are alot of newbs to websockets out there who can easily step into the beartrap of an insecure websocket, and depending on what kind of data they are sending accross the wires it could have bad consequences.