在会话ID中包含工作端口号的安全隐患

Question

我编写了一个多进程实时WebSocket服务器，它使用会话ID根据正在侦听的端口号对相关工作者的流量进行负载均衡。会话ID包含主机名，源端口号，工作端口号以及工作者用于唯一标识客户端的实际哈希ID。典型的会话ID如下所示：

localhost_9100_8000_0_AoT_eIwV0w4HQz_nAAAV

我想知道将工作端口号（在本例中为9100）作为会话ID的一部分的安全隐患。

我有点担心拒绝服务（DoS）威胁 - 理论上，这可能允许恶意用户生成针对特定端口号的大量HTTP请求（例如，使用包含伪造的sessionID）那个港口号码） - 但这是一个严重的威胁吗？ （假设你有不错的防火墙）？从安全角度来看，Google等大公司如何处理粘性会话？

我还应该考虑其他威胁吗？

我设计这样的服务器的原因是为了解释初始HTTP握手以及客户端不支持WebSocket的时间（在这种情况下使用HTTP长轮询 - 因此客户端需要后续的HTTP请求）去后端找同一个工人。）

Answer 1

因此，您的问题中有几个子问题。我会尝试拆分它们并相应地回答它们：

对特定工作人员的DoS攻击是否构成严重威胁？

这取决于。如果你有100个用户，可能不会。但你可以肯定的是，那里有人，会看看你的应用程序，并试图弄清楚这些弱点并利用它们。

现在对单个工作者的DoS攻击是一个严重的可能性，如果你可以攻击整个服务器？我实际上会说是，因为它是一个更精确的攻击=＆gt;当你逐一进行工作时，你需要更少的资源来杀死工人。但是，如果您仅允许来自外部的连接在端口80上用于HTTP并阻止其他所有内容，则此问题将得到解决。

Google等大公司如何处理粘性会话？

简单回答 - 谁说，他们这样做？当您拥有分布式系统时，还有其他多种方法可以解决会话问题：

• 不要根据服务器存储任何会话，只需在厨房中放一个钥匙就可以再次识别用户，类似于自动登录。
• 将会话状态存储在数据库或对象存储中（这会增加很多开销）
• 将会话信息存储在代理（或代理，http端点，...）中，并将它们与请求一起发送给下一个工作人员

我还应该考虑其他威胁吗？

总有无法预见的威胁，这就是为什么你不应该发布超过必要的信息的原因。在这种情况下，大多数大公司甚至不会发布他们的WebServer的正确名称和版本（例如谷歌为gws）

---

话虽如此，我明白你的观点，为什么你可能想保留你的实现，但也许你可以稍微修改它以在你的负载均衡器中存储一个字典，其中包含一个散列值为hostname，source port number，worker port number和将会话ID作为两个哈希的集合。通过查看字典，负载均衡器知道需要向哪个工作者发送。此信息应与时间戳一起保存，最后一次检索信息时，每分钟都可以删除未使用的数据。