I am trying to implement user authentication in an application that primarily uses WebSockets, but I am unsure how to begin.
I am using the Gorilla mux and websocket packages.
I have thought about using the method described here (files main.go and auth.go), but does this approach secure against authenticated users somehow hijacking each others sockets like described in this article?
Can someone suggest a good method or package(s) in Go?
Authenticate as you would for a plain HTTP request before upgrading the connection to the WebSocket protocol. Use whatever methods or packages you would use for plain HTTP requests.
A WebSocket connection can be hijacked to the extent that a plain HTTP connection can be hijacked. The WebSocket protocol does not introduce any new issues here.
Socket.io is a layer above WebSockets, long-polling and other techniques for sending events from the server to a browser client. Issues with Socket.io do not necessarily apply to direct use of a WebSocket.
Related
I was wondering to have a realtime system made with express and i came to know about socket.io and websockets. But the way they are used i.e.
const io = socket.io("https://example.com") ;
Is it safe to use. Since the url for socket connection is available at client side any third party service can enjoy and exploit the services by connecting from their service. I don't have much idea about socket.io so correct me if I am wrong.
Kindly don't mark this question as duplicate since I found a similar question but the answer to it was related to game development, here I am specific about updating clients whenever any updates are there on the server side. Clients may be website made with angular or apps made with Android studio.
Any help is highly appreciable.
socket.io is widely used. It is perfectly fine for use in production.
Regarding the authentication part, A websocket connection b/w client and browser is established via http upgrade request(in http/1.1).
If you have an authentication mechanism in place for your application using cookie and session then you should be safe. No one can establish websocket connection directly without first logging in. On top of this you can limit connection per user to ensure that a registered user cant further exploit the connection using the cookie data.
I have seen this question and answer, which explains how to share sessions with Socket.IO 1.x and Express 4.x and this blog which suggests the use of socketio-auth.
Is there a need to use both approaches for authentication if you are already sharing sessions with express. Does it add any security advantage?
If you already have an authenticated session via http in Express, then a socket.io connection is really JUST another http connection (it actually starts with an http connection and is then converted to the webSocket protocol (with a socket.io layer on top). So, if you're willing to trust the session for the next http request from that client, then it is no different to trust the session for an incoming socket.io connection from that same client. They are the same thing.
Where it might be useful to auth a socket.io connection from scratch would be when you don't already have an authenticated http page that the socket.io connection comes from, either because the socket.io connection is its own API and own service, perhaps even on a separate host so there is no "other" auth to rely on.
Is there a need to use both approaches for authentication if you are already sharing sessions with express.
No. You can just use the express session you already have in order to now that the socket.io connection comes from the same client.
Does it add any security advantage?
Only if there's some reason you want to require auth on every new request and not rely on a session cookie at all, even for http requests. Or, if there is no session cookie because the socket.io connection goes to a different host.
I am using Socket.IO with a MEAN stack and it's been excellent for low latency and bidirectional communication, but what would be the major draw back for using it for relatively static data as well as dynamic?
My assumption is that it would be more apt for sending more dynamic content. That being said, once a socket connection is established, how relevant is the amount of communication being done? Is there a time where it would be more appropriate to use http instead when a connection is constantly established throughout the user's direct interaction with the application?
Thanks!
WebSockets are a bidirectional data exchange within a HTTP connection. So the question is not if you use HTTP or WebSockets, because there is no WebSockets without HTTP. WebSockets are often confused with simple (BSD) sockets, but WebSockets are actually a socket-like layer inside a HTTP connection which is inside a TCP connection which uses "real" sockets. Or for anybody familiar with OSI layers: it as a layer 4 (transport) encapsulated inside layer 7 (application) and the main reason for doing it this strange way instead of using layer 4 directly is that plain sockets to ports outside of HTTP, SMTP and a few other protocols are no longer possible because of all the port blocking firewalls.
So the question should be more if you use simple HTTP or if you need to use WebSockets (inside HTTP).
With simple HTTP the client sends a request and the server sends the response back. The format is well defined and browser and server transparently support compression, caching and other optimizations. But this simple request-response pattern is limited, because there is no way to push data from server to client or to have a more (BSD) socket like behavior where both client and server can send any data at any time. There are various more or less good workarounds for this, like long polling.
WebSockets gives you a bidirectional communication, which makes it possible for the server to push data to the client or to send data in both directions at any time. And once the WebSocket connection is established by upgrading an existing HTTP connection the overhead for the data itself is very small, much smaller then with a full new HTTP request. While this sounds good you loose all the advantages of simple request-response HTTP like caching at the client or in proxies. And because client and server need resources to keep the underlying TCP connection open it needs more resources, which can be relevant for a busy server. Also, WebSockets might give you more trouble with middleboxes (like proxies or firewalls) then simple HTTP does.
In summary: if you don't need the advantages of WebSockets stay with simple request-response HTTP.
I set up a Node.js HTTP server. It listens to path '/' and returns an empty HTML template on a get request.
This template includes Require.js client script, which creates Socket.IO connection with a server.
Then all communication between client and server is provided by Web Sockets.
On connection, server requires authentication; if there are authentication cookies then client sends them to server for validation, if no cookies then client renders login view and waits for user input, etc.
So far everything works, after validating credentials I create a SID for user and use it to manage his access rights. Then I render main view and application starts.
Questions:
Is there a need to use HTTPS instead of HTTP since I'm only using HTTP for sending script to the client? (Note: I'm planning to use Local Storage instead of cookies)
Are the any downfalls in using pure Web Sockets without HTTP?
If it works, why nobody's using that?
Is there a need to use HTTPS instead of HTTP since I'm only using HTTP
for sending script to the client? (Note: I'm planning to use Local
Storage instead of cookies)
No, HTTP/HTTPS is required for handshake for websockets. Choice of HTTP or HTTPS is from security point of view. If you want to use it for simply sending script then there is no harm. If you want to implement user login / authentication in your pages then HTTPS should be used.
Are the any downfalls in using pure Web Sockets without HTTP?
Web sockets and HTTP are very different. If you use pure Web Sockets you will miss out on HTTP. HTTP is the preferred choice for cross-platform web services. It is good for document traversal/retrieval, but it is one way. Web socket provides full-duplex communications channels over a single TCP connection and allows us to get rid of the workarounds and hacks like Ajax, Reverse Ajax, Comet etc. Important thing to note is that both can coexist. So aim for web sockets without leaving out HTTP.
If it works, why nobody's using that?
We live in the age of HTTP, web sockets are relatively new. In the long term, web sockets will gain popularity and take up larger share of web services. Many browsers until recently did not support web sockets properly. See here, IE 10 is the latest and only version in IE to support web sockets. nginx, a wildly popular server did not support web sockets until Feb-March 2013. It will take time for web sockets to become mainstream but it will.
Your question is pretty similar to this one
Why use AJAX when WebSockets is available?
At the end of the day they were both created for different things although you can use web sockets for most, if not everything which can be done in normal HTTP requests.
I'd recommend using HTTPS as you do seem to be sending authentication data over websockets (which will also use the SSL, no?) but then it depends on your definition of 'need'.
Downfalls - Lack of support for older browsers
It's not used this this in many other situations because it's not necessary and it's still 'relatively new'.
I have an existing websocket server which serves json over websockets for IM on some non-http/s port.
This works fine for browsers which support websocket protocol but leaves a lot of other browsers from using the feature.
I was reading up on socket.io and nodejs and was thinking of adding a proxy using socket.io and nodejs in front of the websocket server to handle all websocket requests. Since socket.io supports fallback using flash websockets or long polling, I was hoping that using socket.io on client side will allow support for all older browsers as well.
So, my questions are,
Is the above approach feasible?
How does the fallback to long polling have to be handled in nodejs? Is it handled automatically or needs to be implemented?
Any existing resources which might help me out.
Thanks
It can be made feasible. However I suggest using NodeJS and Socket.IO for both your non-http request and http request for browsers. NodeJS can handle them very easily.
Socket.IO handles fallback automatically.
A simple chat system example here for http.