在会话ID中包含工作端口号的安全影响
我写了一个多进程实时WebSocket服务器，它使用会话ID来根据正在监听的端口号将stream量负载平衡到相关的worker。 会话ID包含主机名，源端口号，工作端口号以及工作人员用来唯一标识客户端的实际哈希ID。 典型的会话ID如下所示：
localhost_9100_8000_0_AoT_eIwV0w4HQz_nAAAV
我想知道将工作端口号（在这种情况下为9100）作为会话ID的一部分的安全含义。
我有点担心拒绝服务（DoS）威胁 – 理论上，这可能会允许恶意用户生成大量针对特定端口号的HTTP请求（例如，使用包含该端口号的假sessionID ） – 但是这是一个严重的威胁？ （假设你有体面的防火墙）？ 像Google这样的大公司如何从安全angular度处理粘性会话？
还有其他的威胁我应该考虑吗？
我这样devise服务器的原因是要考虑到最初的HTTP握手，以及什么时候客户端不支持WebSocket（在这种情况下，使用HTTP长轮询 – 因此，来自客户端的后续HTTP请求需要去在后端的同一个工人）。
所以在你的问题中有几个子问题。 我会尽量把它们分开并相应地回答它们：
DoS攻击某个特定的员工是否有严重的威胁？
这取决于。 如果你有100个用户，可能不是。 但是你可以肯定的是，有人在那里，看看你的应用程序，并试图找出弱点和利用这些。
如果你能攻击整个服务器，现在是单个工作者的DoS攻击严重的可能性吗？ 我实际上会说是的，因为这是一个更精确的攻击=>当你一个接一个的时候，你需要更less的资源来杀死工人。 但是，如果只允许在80端口连接外部HTTP，并阻止其他任何事情，则会解决此问题。
Google这样的大公司如何处理粘性会话？
简单的答案 – 谁说，他们呢？ 当您拥有分布式系统时，还有其他多种方法来解决会话问题：
- 不要存储基于服务器的任何会话，只需要有一个密钥，您可以再次识别用户，类似于自动login。
- 将会话状态存储在数据库或对象存储中（这会增加很多开销）
- 将会话信息存储在代理（或代理，http端点，…）中，并将其与请求一起发送给下一个工作人员
还有其他的威胁我应该考虑吗？
总是有无法预料的威胁，这就是为什么你永远不应该公布更多信息。 在这种情况下，大多数大公司甚至不发布他们的Web服务器的正确名称和版本（对于谷歌来说，例如gws ）
这就是说，我明白了你为什么要保留你的实现，但也许你可以稍微修改它，以便在你的负载平衡器中存储一个具有主机名，源端口号，工作端口号的哈希值的字典，并且作为会话ID是两个散列的集合。 负载均衡器通过查看字典知道需要发送哪个工作者。 此信息应与时间戳一起保存，上次检索信息时，每分钟可删除未使用的数据。