使用node.js实现类似彗星的行为是否会带来安全威胁?

Does using node.js for comet like behaviour pose a security threat?

本文关键字:是否 威胁 安全 实现 js node 使用      更新时间:2023-09-26

我一直在寻找实现彗星行为的网站。到目前为止,Node.js(及其各种衍生产品)似乎领先于该领域的其他产品(IMHO)。

然而,我不禁注意到,所有负责更新客户端(浏览器等)的客户端JS,通信端口显然是硬编码在客户端脚本。

对我来说(我可能是错的),这就像发布服务器的哪些端口是开放的(因此欢迎黑客通过该端口进行攻击)。是我太多疑了还是这真的值得关注?

我真的想说Comet的安全性并不差,但事实并非如此。

首先,它通常不那么安全的原因是Comet请求就像普通的HTTP请求一样,但生命周期稍长一些。因此,它们与您编写的任何其他HTTP端点(例如,确保验证用户的会话cookie等)一样,都要遵守相同的安全要求

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

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

…现在莎莉发现第一个窗口时看到了什么?好友列表已经更新以显示她的所有好友,因此看起来就像她已经登录了那里。但是Comet连接已被认证为Fred,并且仍然是打开的。所以莎莉收到了弗雷德的短信,而没有收到她的。咦。

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

最后,请注意,你的问题或这个答案中没有任何内容是特定于node.js的。所有Comet解决方案都具有这些相同的特性。