使用WebSocket从开发人员那里窃取机密

这是一个关于从从事绝密项目的不知情的JavaScript开发人员那里提取Codez的复杂但不太有用的方法的故事。

最近有几篇关于网站滥用WebSocket功能对用户的计算机进行端口扫描的文章出现在这些网站上。例如：https://nullsweep.com/why-is-this-website-port-scanning-me/.。

这些技术之所以有效，是因为浏览器允许来自公共来源的WebSocket打开到本地主机的WebSockets连接，而不需要太多保护。

这让我开始思考。我知道流行的JavaScript框架在开发中使用WebSockets在内容更改时自动重新加载页面。恶意网站会窃听该流量，并找出开发人员何时保存他们的代码吗？

要么设置，要么向前端开发人员经常使用的热门站点注入广告恶意软件。让我们说http://frontend-overflowstack.com/。

在此页面上，添加尝试打开公共端口的WebSockets连接的代码(扫描10k端口大约需要一秒钟，因此您可以在此相当慷慨)。

如果页面设法打开了一个连接，请使其保持打开状态，并将收到的所有消息转发到您的恶意秘密数据库。

我在http://frontend-overflowstack.com/.上托管了一个非常简单的页面。加载后，它会尝试将网络插座连接到访问者计算机上2000到10000之间的每个端口(除了Firefox不允许的几个端口)。如果端口连接，则它会侦听该端口并输出收到的任何消息。此页面不保存或以其他方式传输任何捕获的数据，它仅临时显示在屏幕上。

如果此页上出现任何输出，则实际恶意的站点可以很容易地将该输出发送到它想要的任何服务器。

要测试这个概念，我们需要一个使用热重新加载的简单Web服务器。这是我能想到的最简单的方法：

它在运行时会在端口3000上启动服务器，在端口9856上启动WebSocket服务器，并每隔5秒向任何连接的WebSocket客户端发送消息：RELOAD。

因此，front end-overflowstack.com直接窃听本地开发服务器向我的本地浏览器发送的重新加载消息。

在这个阶段，可以坐下来兴高采烈地计算每个访问我们站点的访问者对他们的本地JavaScript代码进行了多少次更改，但是我们能用这个来获取更多信息吗？

现在的大多数前端开发似乎都涉及到使用REACTION，通常这涉及到运行webpack开发的服务器，该服务器包括它自己的、更花哨的Web套接字接口。

此服务器通过其Web套接字共享更多数据，但只有一点点有趣。演示这一点非常简单，只需调用Create-Reaction-app：

一旦有更多的数据被显示，我们就会得到哈希和状态消息，所有无用的信息。

但是，当开发人员输入错误时会发生什么呢？webpack开发服务器通过其WebSocket连接，很有帮助地尝试将大量调试和堆栈信息发送到开发人员的屏幕上。

现在事情变得更有趣了。我们有代码片段，文件路径，位置，各种有用的信息。

如果最终开发人员意外地在包含有用数据的行上输入错误，情况会更好：

现在，我们已经获得了此开发人员的AWS开发人员凭据的副本。快点，启动比特币矿工！

没有某种形式的图表，任何技术设计都是不完整的。下面是它的工作原理，用图表表示：

(为了简化图表，我省略了正在运行的本地Web服务器，并假装WebSocket服务器直接从编辑器内部发起)。

某些浏览器选项卡上的恶意网页会以静默方式连接到用户计算机上打开的WebSocket。当敏感数据通过该套接字发送时(来自期望通过仅本地通道进行通信的进程)，网站可以接收该消息数据，并将其转发到任何外部数据库。

说真的，这个攻击媒介是相当微不足道的。您必须引诱不知情的用户访问您的站点，并在他们开发JS代码时停留在该站点上。

然后，你必须等待幸运地从他们的编码错误中收集到一些数据，也许才能找到一个可以让你从这些数据中获利的机会。

然而，我们已经看到各个站点已经在使用WebSocket端口扫描技术，而没有引起一般开发人员的注意。由于JS工具往往使用少量的知名端口，因此编写脚本来巧妙地渗透Reaction Dev流量并不是特别困难。

想象一下，一个为Twitbook工作的内部开发人员只是在他们的编辑器中按了SAVE，导致访问令牌或内部服务器地址泄露给了错误的用户。

这有点吓人的方面是，一个合理的开发人员应该有一个普遍的期望，即在他们选择的代码编辑器中按下保存应该没有有效地导致数据泄漏到第三方Web服务的可能性。这次袭击增加了这种可能性，足以让人有点担心。

我试图拦截JavaScript热重载机制，因为这确实是我熟悉的WebSockets的唯一通用用法。不和谐也使用WebSockets，但匆匆一瞥并没有产生任何明显的结果，因为该频道的设计考虑到了公共互联网。

令人担忧的是，仅仅这一个用于重新加载的单向通信通道的简单用例就将如此多的潜在信息暴露给了不好的网站。

考虑到这一点，WebSockets的其他用途(对于不是为公共互联网设计的数据)可能会受到类似的危害。

可以说，webpack开发的服务器应该进行一些身份验证，或者使用替代的浏览器通信通道进行热重新加载(我相信出于其他原因，这已经在计划中了)。

浏览器/Web标准为WebSocket实现源码策略的方式确实令人惊讶，并导致专为本地开发而设计的软件以一种不理想的方式暴露在公共互联网上。