Security implications of including worker port number in session ID

Question

I wrote a multi-process realtime WebSocket server which uses the session id to load-balance traffic to the relevant worker based on the port number that it is listening on. The session id contains the hostname, source port number, worker port number and the actual hash id which the worker uses to uniquely identify the client. A typical session id would look like this:

localhost_9100_8000_0_AoT_eIwV0w4HQz_nAAAV

I would like to know the security implications for having the worker port number (in this case 9100) as part of the session id like that.

I am a bit worried about Denial of Service (DoS) threats - In theory, this could allow a malicious user to generate a large number of HTTP requests targeted at a specific port number (for example by using a fake sessionID which contains that port number) - But is this a serious threat? (assuming you have decent firewalls)? How do big companies like Google handle dealing with sticky sessions from a security perspective?

Are there any other threats which I should consider?

The reason why I designed the server like this is to account for the initial HTTP handshake and also for when the client does not support WebSocket (in which case HTTP long-polling is used - And hence subsequent HTTP requests from a client need to go to the same worker in the backend).

Answer 1

So there are several sub-questions in your question. I'll try to split them up and answer them accordingly:

Is DoS-Attack on a specific worker a serious threat?

It depends. If you will have 100 users, probably not. But you can be sure, that there are people out there, which will have a look at your application and will try to figure out the weaknesses and exploit those.

Now is a DoS-Attack on single workers a serious possibility, if you can just attack the whole server? I would actually say yes, because it is a more precise attack => you need less resources to kill the workers when you do it one by one. However if you allow connection from the outside only on port 80 for HTTP and block everything else, this problem will be solved.

How do big companies like Google handle dealing with sticky sessions?

Simple answer - who says, they do? There are multiple other ways to solve the problem of sessions, when you have a distributed system:

• don't store anything session based on the server, just have a key in the cooky with which you can identify the user again, similar as with automatic login.
• store the session state in a data base or object storage (this will add a lot of overhead)
• store session information in the proxy (or broker, http endpoint, ...) and send them together with the request to the next worker

Are there any other threats which I should consider?

There are always unforeseen threats, and that's the reason, why you should never publish more information than necessary. In that case, most big companies don't even publish the correct name and version of their WebServer (for google it is gws for instance)

---

That being said, I see your point why you might want to keep your implementation, but maybe you can modify it slightly to store in your load balancer a dictionary with a hashed value of hostname, source port number, worker port number and have as a session id a collection of two hashes. Than the load balancer knows, by looking into the dictionary, to which worker it needs to be sent. This info should be saved together with a timestamp, when the info was retrieved the last time, and every minute you can delete unused data.