websocket开发_如何使用Websocket窃取开发人员的秘密

websocket开发

这是一个复杂的，不是很有用的方法的故事，该方法用于从不知情的从事最高机密项目JavaScript开发人员中提取代码。

最近有几篇文章在这些站点上流行，它们记录了滥用websocket功能来对用户计算机进行端口扫描的网站。 例如： https : //nullsweep.com/why-is-this-website-port-scanning-me/ 。

这些技术起作用的原因是因为浏览器允许来自公共起源的Websocket在没有很多保护的情况下打开到localhost的Websocket连接。

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

现实比我想象的要糟。

方案

1.进行设置，或将广告恶意软件注入到前端开发人员经常访问的受欢迎站点中。 假设http://frontend-overflowstack.com/

2.在此页面上，添加尝试打开与普通端口的websockets连接的代码（扫描1万个端口大约需要一秒钟，因此您在这里可以很慷慨）

3.如果页面设法打开连接，请使其保持打开状态，然后将收到的所有消息转发到您的恶意数据库。

4.？

5.利润

它行得通吗？

我在以下网址托管了一个非常简单的页面： http : //frontend-overflowstack.com/ 。 在加载时，该页面尝试将websocket连接到访问者计算机上2,000至10,000之间的每个端口（除非Firefox不允许使用其中的几个端口）。 如果连接了端口，则它将侦听该端口并输出收到的所有消息。

该页面不会保存或传输任何捕获的数据，只会暂时显示在屏幕上。

如果此页面上显示任何输出，则实际上是恶意站点可能会将该输出轻松发送到所需的任何服务器。

产生资料

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

var express = require ( 'express' )
var http = require ( 'http' )
var path = require ( 'path' )
var reload = require ( 'reload' );

var app = express()
 
app.get( '/' , function ( req, res )  {
	res.sendFile(path.join(__dirname, 'public' , 'test.html' ));
})

var server = http.createServer(app)
 
reload(app).then( function ( reloadReturned )  {
  server.listen( 3000 , function ()  {});
	setInterval(reloadReturned.reload, 5000 );
});

运行时，它将在端口3000上启动服务器，在端口9856上启动Websocket服务器，并发送一条消息：每5秒重新加载到任何已连接的Websocket客户端。

如果我们启动嗅探器站点，则会显示以下内容：

因此，frontend-overflowstack.com直接窃听了本地开发服务器发送到本地浏览器的重载消息。

在此阶段，可以坐下来轻松地计算每个访问我们网站的访问者对其本地JavaScript代码进行更改的次数，但是我们可以使用它来获取更多信息吗？

情节变厚

如今 ，大多数前端开发似乎都涉及使用React，并且通常涉及运行webpack-dev服务器，该服务器包括自己的，更漂亮的Web套接字接口。

该服务器通过其Websocket共享更多（只有一点点有趣）的数据。 演示这就像调用create-react-app一样简单：

$ npx create-react-apptest
$ cd test /
$ npm start

如果运行此命令，然后再次查看我们的恶意站点：

即时显示了更多数据，我们收到了哈希和状态消息以及所有无用的信息。

但是，当开发人员输入错误时会发生什么？ Webpack开发服务器通过其websocket连接，尝试将大量调试和堆栈信息发送到开发人员的屏幕。

幸运的是，我们的邪恶站点也可以看到此信息：

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

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

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

“攻击”的剖析

没有某种形式的图表，任何技术设计都是不完整的。 这是图形方式的工作原理：

（为简化该图，我省略了运行的本地Web服务器，并假装websocket服务器直接来自编辑器内部）

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

威胁评估

限制因素

认真地说，这种攻击媒介非常渺茫。 您必须诱使不知情的用户访问您的网站，并在他们开发JS代码时留在该网站上。

然后，您必须等待，以幸运地从他们的编码错误中收集少量数据，也许找到一个可以使您从泄漏中获利的开口。

综合考虑

但是，我们已经看到，各种站点已经在使用Websocket端口扫描技术，而没有太多的一般开发人员意识。 鉴于JS工具倾向于使用少量的知名端口，因此编写脚本来巧妙地泄露React Dev流量并不是特别困难。

想象一下，为Twitbook工作的内部开发人员只是在其编辑器中按“保存”，并使该访问令牌或内部服务器地址泄露给了错误的受众。

稍微令人恐惧的方面是，一个合理的开发人员应该普遍期望，在他们选择的代码编辑器中按Save可以有效地将数据泄漏给第三方Web服务的可能性为0。 这次攻击使这一机会引起了足够的关注。

整治

我采用了这种尝试拦截JavaScript热重装机制的方法，因为它实际上是我所熟悉的Websocket的唯一通用用法。 Discord还使用了websocket，但是对此一目了然并没有产生任何明显的结果，因为该频道的设计似乎是考虑到了公共互联网。

令人担忧的是，单向通信通道的这种简单重用案例仅能将大量潜在信息暴露给不良网站。

鉴于此，websocket的其他用途（用于非公共互联网设计的数据）可能会受到类似的损害。

可以说，webpack-dev服务器应该进行一些身份验证，或者将备用浏览器通信通道用于热重载（我相信出于其他原因，这已经在计划中）。

当然，这似乎是浏览器/网络标准为websocket实施原始策略的方式，这令人惊讶，并且导致设计用于仅本地开发的软件以非理想的方式公开给公共互联网。

我希望任何修复都可以集中精力在浏览器中实现额外的控件。

翻译自: https://hackernoon.com/how-to-steal-secrets-from-developers-using-websockets-dw3p3zgk

websocket开发