I'm wondering how I could secure my socket.io connection to the server from th following.
Security Issues:
What would stop malicious users from connecting to the socket server via client side code?
Example:
OUTSIDE DOMAIN REQUEST var socket = io.connect('http://Mydomain', {port: 4000});
Users can seemingly create thousands of concurrent connections just by opening a different browser window.
How can I prevent these issues?
You should be able to check serverside that the HTTP referrer is correct. Check the socket.io spec for info on both http referring as well as handshaking.
https://github.com/socketio/socket.io-protocol
Also 0.8 has referrer verification. Havent used it before, but this may be a place to start looking:
https://github.com/LearnBoost/socket.io/pull/481
Well, if your (real) clients are coming from a well know location, you'd probably want to to block everyone else at the firewall level. Assuming your service is available to everyone, you can probably look into client-server handshake mechanism.
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.
Is http ok vs https in an intranet connected to the internet ?
If a bank has a website which using http and only accessible if connected to the network, is this a security risk?
Not sure if I understood your question, but let me try an answer.
HTTPS has the objective to guarantee that no one in the middle of the connection is being able to see what you and the server are talking to each other, he does it using encryption, so even in an intranet using HTTPS has its advantages.
Imagine a wireless connection, everyone in the bank is in the middle of you and the connection with the router (consequently, the server) if you are using it, so if this website has sensitive information like a password, even in an intranet, you would want it secure so no one inside that network can sniff packets and get your password easily in a clear HTTP request.
I am working on a nodejs app with Socket.io and I did a test in a single process using PM 2 and it was no errors. Then I move to our production environment(We use Google Cloud Compute Instance).
I run 3 app processes and a iOS client connects to the server.
By the way the iOS client doesn't keep the socket connection. It doesn't send disconnect to the server. But it's disconnected and reconnect to the server. It happens continuously.
I am not sure why the server disconnects the client.
If you have any hint or answer for this, I would appreciate you.
That's probably because requests end up on a different machine rather than the one they originated from.
Straight from Socket.io Docs: Using Multiple Nodes:
If you plan to distribute the load of connections among different processes or machines, you have to make sure that requests associated with a particular session id connect to the process that originated them.
What you need to do:
Enable session affinity, a.k.a sticky sessions.
If you want to work with rooms/namespaces you also need to use a centralised memory store to keep track of namespace information, such as the Redis/Redis Adapter.
But I'd advise you to read the documentation piece I posted, things might have changed a bit since the last time I've implemented something like this.
By default, the socket.io client "tests" out the connection to its server with a couple http requests. If you have multiple server requests and those initial http requests don't go to the exact same server each time, then the socket.io connect will never get established properly and will not switch over to webSocket and it will keep attempting to use http polling.
There are two ways to fix this.
You can configure your clients to just assume the webSocket protocol will work. This will initiate the connection with one and only one http connection which will then be immediately upgraded to the webSocket protocol (with socket.io running on top of that). In socket.io, this is a transport option specified with the initial connection.
You can configure your server infrastructure to be sticky so that a request from a given client always goes back to the exact same server. There are lots of ways to do this depending upon your server architecture and how the load balancing is done between your servers.
If your servers are keeping any client state local to the server (and not in a shared database that all servers access), then you will need even a dropped connection and reconnect to go back to the same server and you will need sticky connections as your only solution. You can read more about sticky sessions on the socket.io website here.
Thanks for your replies.
I finally figured out the issue. The issue was caused by TTL of backend service in Google Cloud Load Balancer. The default TTL was 30 seconds and it made each socket connection tried to disconnect and reconnect.
So I updated the value to 3600s and then I could keep the connection.
I am designing a website which uses a node server and socket.io as a middle man between the server and client. As far as I am aware, the only way to connect the client socket.io to the server is to write a line of code like the following:
var socket = io.connect("http://SERVER_IP:PORT");
With the obvious substitutions. I may be wrong in thinking this, but having this information on client code for all to see seems like a serious security risk. I was wondering if this actually the case, that there may be serious issues posed by displaying this information; if so, how would I go about not having it displayed on client code, since the client has to have some method of connecting to the server. I've looked into proxy ip's, but saw it only in php and didn't know if socket had another way of dealing with this.
I basically want to know if its possible to use Socket.io using the server-side only with no client side? BUT I want to know if my server-side can instead connect with a different site that I cannot use Socket.io to connect to.
Use PhantomJS to load the third-party site and then inject your own javascript into the page to catch events and send those events back to your own server.
socket.io is a two-way connection. Client <--> Server. You must have a socket.io endpoint at both ends to even establish a connection in the first place. And, then once you establish the connection, you must have agreed upon messages that can be exchanged between the two ends for it to do anything useful.
It is not useful to have a server-side socket.io that doesn't actually connect to anything and nothing connects to it. It wouldn't be doing anything, just sitting there waiting for someone to connect to it.
It is possible to have two cooperating servers connect to one another with socket.io (one server just acts like a client in that case by initiating the connection to the other server). But, again both endpoints must participate in the connection for the connection to even be established and certainly for it to do anything useful.
If you just want to download the contents of a site for scraping purposes, then you would not use socket.io for that. You would just use the nodejs http module (or any of several other modules built on top of it). Your server would essentially pretend to be a browser. It would request a web page from any random web server using HTTP (not socket.io). That web server would return the web page via the normal HTTP request. Your receiving server can then do whatever it wants with that web page (scrape it, whatever).