1

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

localhost_9100_8000_0_AoT_eIwV0w4HQz_nAAAV

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

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

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

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

4

1 回答 1

1

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

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

这取决于。如果您将有 100 个用户，则可能不会。但是您可以肯定，那里有人会查看您的应用程序并尝试找出弱点并加以利用。

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

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

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

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

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

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

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

于 2014-03-12T23:04:43.050 回答