node.js - 在 session ID 中包含工作端口号的安全影响

Question

我编写了一个多进程实时 WebSocket 服务器，它使用 session ID 根据其正在监听的端口号将流量负载平衡到相关工作线程。 session ID 包含主机名、源端口号、工作端口号以及工作人员用来唯一标识客户端的实际哈希 ID。典型的 session ID 如下所示:

localhost_9100_8000_0_AoT_eIwV0w4HQz_nAAAV

我想知道将工作端口号(在本例中为 9100)作为 session ID 的一部分的安全影响。

我有点担心拒绝服务 (DoS) 威胁 - 理论上，这可能允许恶意用户针对特定端口号生成大量 HTTP 请求(例如，通过使用包含该端口号的虚假 sessionID) - 但这是一个严重的威胁吗？ (假设你有像样的防火墙)？从安全角度来看，像 Google 这样的大公司如何处理粘性 session ？

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

我设计这样的服务器的原因是考虑到初始 HTTP 握手以及客户端不支持 WebSocket 的情况(在这种情况下使用 HTTP 长轮询 - 因此来自客户端的后续 HTTP 请求需要转到后端的同一工作人员)。

Answer 1

所以你的问题中有几个子问题。我会尝试将它们分开并相应地回答它们:

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

这要看情况。如果您有 100 个用户，则可能不会。但您可以确信，有人会查看您的应用程序，并尝试找出弱点并利用这些弱点。

如果您可以攻击整个服务器，那么现在对单个工作人员进行 DoS 攻击的可能性很大吗？我实际上会说是的，因为这是一种更精确的攻击=>当你一个接一个地杀死 worker 时，你需要更少的资源。但是，如果您仅允许 HTTP 端口 80 上的外部连接并阻止其他所有内容，则此问题将得到解决。

像 Google 这样的大公司如何处理粘性 session ？

简单的答案 - 谁说的，他们就是这么做的？当您拥有分布式系统时，还有多种其他方法可以解决 session 问题:

• 不要基于服务器存储任何 session ，只需在 cookie 中保存一个 key ，您可以使用它再次识别用户，类似于自动登录。
• 将 session 状态存储在数据库或对象存储中(这会增加大量开销)
• 将 session 信息存储在代理(或代理、http 端点等)中，并将它们与请求一起发送给下一个工作人员

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

总是存在不可预见的威胁，这就是为什么您永远不应该发布不必要的信息的原因。在这种情况下，大多数大公司甚至不会发布其 WebServer 的正确名称和版本(例如，对于 google 来说是 gws)

<小时/>话虽这么说，我明白你为什么可能想保留你的实现，但也许你可以稍微修改它，在负载均衡器中存储一个字典，其中包含主机名、源端口号、工作端口号的哈希值，并将两个哈希值的集合作为 session ID。负载均衡器通过查看字典知道需要将其发送给哪个工作人员。此信息应与上次检索信息的时间戳一起保存，并且每分钟您都可以删除未使用的数据。