将node.js用于彗星行为是否构成安全威胁？

Question

我正在寻找为网站实施彗星行为的方法。到目前为止，Node.js（及其各种衍生产品）似乎领先于其他领域（恕我直言）。

但是，我不禁注意到，在负责更新客户端（浏览器等）的所有客户端JS中，通信端口在客户端脚本中都是明显硬编码的。

对我而言（我可能错了），就像发布服务器的哪些端口是开放的（因此欢迎黑客通过该端口进行攻击）。我是否过度偏执或者这真的令人担忧？

Answer 1

我真的想说Comet不是那么安全，但那不是真的。

首先，它通常不那么安全的原因是Comet请求就像常规HTTP请求一样，但生命周期稍长。因此，与您编写的任何其他HTTP端点相比，它们需要具有相同的安全性要求（例如，确保验证用户的会话cookie等）。

但是长寿命周期意味着底层用户可以通过Comet连接更改中间流。这可能会导致一些有问题的用户体验。例如，假设一个聊天应用程序使用Comet流向浏览器发送消息，并使用常规HTTP轮询更新好友列表，显示用户在线的朋友。现在来看看这个场景......

• Fred在窗口A中登录到基于彗星的聊天应用程序。打开Comet连接（经过身份验证为Fred），然后开始为他提取消息。凉。
• 现在Fred最小化窗口并且（认为他关闭了所有东西）走开了
• Sally出现（没有看到Fred的最小化窗口）并在您的网站上打开第二个窗口并自行登录。这使Fred的会话cookie无效，并将其替换为Sally的。
• 不久之后，Sally看不到，第一个窗口轮询服务器以查看当前用户的哪些朋友在线。因为当前用户现在是Sally，所以第一个窗口会更新以显示她的所有朋友。

...现在Sally在找到第一个窗口时看到了什么？朋友列表已更新以显示她的所有朋友，因此看起来就像她已登录那里一样。但Comet连接已通过Fred验证，仍处于打开状态。所以莎莉得到了弗雷德的信息，而不是她的信息。 EWWW。

这是您需要注意的事情，而不是担心端点的可见性。 所有 http端点都是可见的，并且可以使用现代浏览器调试器和网络数据包嗅探器轻松进行逆向工程。安全性来自在服务器上实现合理的身份验证策略，而不是隐藏连接到服务器的方式。

最后，请注意，您的问题或此答案中没有任何内容特定于node.js.所有Comet解决方案都具有相同的特性。