[[330889]]

一群從事絕密項目而不自知的JavaScript開發(fā)人員，該用什么樣的方法來提取他們的代碼呢？本文的故事就是關(guān)于這個的。這些技術(shù)之所以有效，是因為瀏覽器在不需要多重防護的條件下就允許公共來源的websockets打開本地主機的websockets連接。

這讓筆者產(chǎn)生了一些思考。筆者知道流行的JavaScript框架在開發(fā)中使用websockets，以在內(nèi)容更改時自動重新加載頁面。一個惡意的網(wǎng)站能不能竊聽到這些流量，并找出開發(fā)人員在何時保存下的代碼？

事實比想象的還要糟糕。

計劃如下：

· 進行一些設(shè)置，或是將廣告惡意軟件注入前端開發(fā)人員經(jīng)常訪問的熱門網(wǎng)站。比如說 
http://frontend-overflowstack.com/

· 在此頁上，添加嘗試打開到公共端口的websockets連接的代碼（掃描10k端口大致需要一秒鐘，因此可以在這里輕松實現(xiàn)此功能）

· 如果頁面成功打開連接，請保持打開狀態(tài)，并將收到的所有消息轉(zhuǎn)發(fā)到自己的秘密數(shù)據(jù)庫。

計劃生效了嗎？

一個非常簡單的頁面就能驗證：http://frontend overflowstack.com/。加載時，它會嘗試將websocket連接到訪客計算機上2000到10000之間的每個端口（除了Firefox不允許的幾個端口）。

如果某個端口連接，它將偵聽該端口輸出接收到的任何消息。此頁不會保存或傳輸任何捕獲的數(shù)據(jù)，僅在屏幕上臨時顯示。如果此頁上出現(xiàn)任何輸出，則實際惡意站點可以很容易地將該輸出發(fā)送到其所需的任何服務(wù)器。

生成數(shù)據(jù)

為了測試這個概念，我需要一個簡單的使用熱加載的web服務(wù)器：

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上的服務(wù)器，端口9856上的websocket服務(wù)器，并發(fā)送一條消息：每5秒重新加載(reload )鏈接所有websocket的客戶端。如果啟動嗅探器站點，將顯示以下內(nèi)容：

因此，前端overflowstack.com可直接竊聽重載消息，這些消息從本地開發(fā)服務(wù)器發(fā)送到本地瀏覽器。在這個階段，我們可以坐下來數(shù)一數(shù)每個訪問我們網(wǎng)站的人對本地JavaScript代碼進行了多少次更改。

但是，可以用這種方式來獲取更多信息嗎？

情節(jié)更復雜了

目前大多數(shù)的前端開發(fā)似乎都會使用React，通常這涉及到運行webpack dev服務(wù)器，其中包括它自己的，以及更繁多的web socket接口。該服務(wù)器通過其websocket可共享更多數(shù)據(jù)，只是更有趣些：

$ npxcreate-react-app test 
$ cd test/ 
$ npm start 

運行這些代碼之后，再來看看我們的惡意網(wǎng)站：

馬上就會有更多的數(shù)據(jù)顯示出來，得到散列式和狀態(tài)式的消息，以及所有無用的信息。當開發(fā)人員輸入錯誤時，會發(fā)生什么？webpack dev服務(wù)器通過其websocket連接，嘗試將一堆調(diào)試和堆棧信息發(fā)送到開發(fā)人員的屏幕上。這些信息在惡意網(wǎng)站也能看到：

現(xiàn)在，我們有了代碼片段、文件路徑、位置等各種有用的信息。甚至當開發(fā)人員最終意外地在包含有用數(shù)據(jù)的代碼行上鍵入錯誤時，得到的結(jié)果會更好：

現(xiàn)在你可獲得一份開發(fā)人員的AWS開發(fā)人員證書副本。

沒有圖表，任何技術(shù)設(shè)計都是不完整的。這里展示了圖像化的代碼運行：

為了簡化圖表，此處省略了正在運行的本地web服務(wù)器，并假設(shè)websocket服務(wù)器直接來自于編輯器中。

某些瀏覽器選項卡上的惡意網(wǎng)頁會自動連接到用戶計算機上打開的WebSocket。當敏感數(shù)據(jù)通過該套接口發(fā)送時（從希望通過僅本地通道進行通信的進程發(fā)送），網(wǎng)站可以接收該消息數(shù)據(jù)，并將其轉(zhuǎn)發(fā)到任何外部數(shù)據(jù)庫。

限制因素

值得注意的是，該攻擊向量很小。必須誘使不知情的用戶訪問網(wǎng)站，并在他們開發(fā)JS代碼時繼續(xù)使用它。然后，必須等待在較為幸運的情況下從他們的編碼錯誤中收集一些數(shù)據(jù)，這也許有助于找到從這些數(shù)據(jù)中獲利的突破口。

綜合考慮

然而，許多網(wǎng)站已經(jīng)在使用websocket端口掃描技術(shù)，而沒有太多開發(fā)人員能意識到這一點?？紤]到JS工具傾向于使用那些眾所周知的端口的小部分，編寫一個腳本來巧妙地過濾react Dev通信量并不是特別困難。

想象一下，一個為Twitbook工作的內(nèi)部開發(fā)人員只需在其編輯器中按save鍵，就會導致訪問令牌或內(nèi)部服務(wù)器地址被泄露給錯誤的訪問者。

這有點嚇人，正常開發(fā)人員通常會希望在他們選擇的代碼編輯器中按下save鍵時，是不會將數(shù)據(jù)泄漏到第三方web服務(wù)的。而這增加了這種風險，足以讓人有點擔心。

補救

筆者的建議是這種嘗試攔截JavaScript熱加載機制的方法，它是筆者所熟悉的websockets的唯一通用方法。Discord也使用websockets，但匆匆一瞥并不會產(chǎn)生任何明顯的效果，因為該通道以公共互聯(lián)網(wǎng)為設(shè)計目標。

令人擔憂的是，僅僅這一個用于重新加載的單向通信簡單用例，就將如此多的潛在信息暴露給了那些惡意網(wǎng)站。websockets的其他用途（對于不是為公共互聯(lián)網(wǎng)設(shè)計的數(shù)據(jù)）也可能受到類似的威脅。

爭論在于，webpack dev服務(wù)器應該進行一些身份驗證，或者使用備用的瀏覽器通信通道進行熱重載。瀏覽器/web標準為websockets實現(xiàn)源代碼策略的方式無疑令人驚訝。導致那些專為本地開發(fā)而設(shè)計的軟件以一種難以預料的方式暴露在公共互聯(lián)網(wǎng)上。

很期待針對瀏覽器中額外控制功能部分的修復。