来源：unsplash一群JavaScript开发人员在不知情的情况下从事绝密项目，他们应该用什么方法提取他们的代码？本文中的故事就是关于此的。这些技术之所以有效，是因为浏览器允许来自公共来源的websockets打开与本地主机的websockets连接，而无需多层保护。这让我不禁思考了一下。我知道流行的JavaScript框架在开发中使用websockets来在内容更改时自动重新加载页面。恶意网站是否可以窃听此流量并找出开发人员何时保存了代码？真相比想象的还要糟糕。计划如下：进行一些设置，或将广告恶意软件注入前端开发人员经常光顾的热门网站。说http://frontend-overflowstack.com/在这个页面上，添加尝试打开一个websockets连接到公共端口的代码（扫描10k个端口大约需要一秒钟，所以这里可以很容易地实现）如果该页面成功打开连接，请保持打开状态，并将收到的所有消息转发到自己的秘密数据库。计划成功了吗？一个很简单的页面可以验证：http://frontendoverflowstack.com/。加载后，它会尝试与来宾计算机上2000到10000之间的每个端口建立websocket连接（Firefox不允许的几个端口除外）。如果端口已连接，它将侦听在该端口输出上接收到的任何消息。此页面不保存或传输任何捕获的数据，它只是暂时显示在屏幕上。如果此页面上出现任何输出，则实际的恶意站点可以轻松将该输出发送到它想要的任何服务器。生成数据为了测试这个概念，我需要一个使用热重载的简单Web服务器：varexpress=require('express')varhttp=require('http')varpath=require('path')varreload=require('reload');varapp=express()app.get('/',function(req,res){res.sendFile(path.join(__dirname,'public','test.html'));})varserver=http。createServer(app)reload(app).then(function(reloadReturned){server.listen(3000,function(){});setInterval(reloadReturned.reload,5000);});运行时，它会启动3000端口9856端口上的websocket服务器上的服务器，并发送消息：每5秒重新加载（reload）所有连接的websocket客户端。如果您启动嗅探器站点，将显示以下内容：因此前端overflowstack.com可以直接窃听从本地开发服务器发送到本地浏览器的重新加载消息。在这个阶段，我们可以坐下来统计每个访问我们网站的人对本地JavaScript代码做了多少更改。但是这样可以获取更多的信息吗？情节变得更加复杂如今大多数前端开发似乎都在使用React，而且通常这涉及运行一个webpack开发服务器，它包含自己的、更广泛的web套接字接口。服务器通过它的websocket共享更多数据，只是更有趣：，以及所有这些废话。当开发人员输入错误时会发生什么？webpack开发服务器通过其websocket连接，试图将一堆调试和堆栈信息发送到开发人员的屏幕。这些信息也可以在恶意网站中看到：现在我们有代码片段、文件路径、位置和各种有用的信息。如果开发人员最终不小心在包含有用数据的代码行中输入错字，那就更好了：现在您可以获得开发人员的AWS开发人员证书的副本。没有图表，任何技术设计都是不完整的。这是代码运行的图形表示：为了简化图表，这里省略了运行的本地Web服务器，假设websocket服务器直接来自编辑器。某些浏览器选项卡上的恶意网页会自动连接到用户计算机上打开的WebSockets。当通过此套接字发送敏感数据时（来自希望通过仅本地通道进行通信的进程），网站可以接收该消息数据并将其转发到任何外部数据库。一个值得注意的限制因素是这种攻击向量很小。必须引诱不知情的用户访问该站点并在他们开发JS代码时继续使用它。然后，必须等待在幸运的情况下从他们的编码错误中收集一些数据，这可能有助于找到突破口，从这些数据中获利。来源：unsplash综合考虑然而，很多网站已经在使用websocket端口扫描技术，而没有多少开发者知道。鉴于JS工具倾向于使用这些知名端口的一小部分，因此编写脚本来巧妙地过滤ReactDev流量并不是特别困难。想象一下为Twitbook工作的内部开发人员只是在他们的编辑器中按下保存，导致访问令牌或内部服务器地址泄露给错误的访问者。这有点可怕，普通开发人员通常希望在他们选择的代码编辑器中按下保存，而不会将数据泄露给第三方Web服务。这增加了风险，足以让人有点担心。Remedy我的建议是这种尝试拦截JavaScript热加载机制的方法，这是我熟悉的唯一的websockets通用方法。Discord也使用websockets，但快速浏览不会产生任何明显的效果，因为该频道是为公共互联网设计的。令人担忧的是，这种用于重新加载的单向通信的简单用例会将如此多的潜在信息暴露给恶意网站。websockets的其他用途（用于不是为公共互联网设计的数据）可能会受到类似的威胁。图片来源：unsplash争论的焦点是webpack开发服务器应该做一些身份验证，或者使用备用浏览器通信通道进行热重载。浏览器/网络标准为websockets实现源策略的方式当然令人惊讶。结果，为本地开发设计的软件以不可预知的方式暴露在公共互联网上。期待修复浏览器中的额外控件。
