開發人員請注意！使用Websockets可能會被竊取秘密
圖源：unsplash
一群從事絕密項目而不自知的JavaScript開發人員，該用什么樣的方法來提取他們的代碼呢？本文的故事就是關于這個的。這些技術之所以有效，是因為瀏覽器在不需要多重防護的條件下就允許公共來源的websockets打開本地主機的websockets連接。
這讓筆者產生了一些思考。筆者知道流行的JavaScript框架在開發中使用websockets，以在內容更改時自動重新加載頁面。一個惡意的網站能不能竊聽到這些流量，并找出開發人員在何時保存下的代碼？
事實比想象的還要糟糕。
計劃如下：
· 進行一些設置，或是將廣告惡意軟件注入前端開發人員經常訪問的熱門網站。比如說
http://frontend-overflowstack.com/
· 在此頁上，添加嘗試打開到公共端口的websockets連接的代碼（掃描10k端口大致需要一秒鐘，因此可以在這里輕松實現此功能）
· 如果頁面成功打開連接，請保持打開狀態，并將收到的所有消息轉發到自己的秘密數據庫。
計劃生效了嗎？
一個非常簡單的頁面就能驗證：http://frontend overflowstack.com/。加載時，它會嘗試將websocket連接到訪客計算機上2000到10000之間的每個端口（除了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秒重新加載(reload )鏈接所有websocket的客戶端。如果啟動嗅探器站點，將顯示以下內容：
因此，前端overflowstack.com可直接竊聽重載消息，這些消息從本地開發服務器發送到本地瀏覽器。在這個階段，我們可以坐下來數一數每個訪問我們網站的人對本地JavaScript代碼進行了多少次更改。
但是，可以用這種方式來獲取更多信息嗎？
情節更復雜了
目前大多數的前端開發似乎都會使用React，通常這涉及到運行webpack dev服務器，其中包括它自己的，以及更繁多的web socket接口。該服務器通過其websocket可共享更多數據，只是更有趣些：
- $ npxcreate-react-app test
- $ cd test/
- $ npm start
運行這些代碼之后，再來看看我們的惡意網站：
馬上就會有更多的數據顯示出來，得到散列式和狀態式的消息，以及所有無用的信息。當開發人員輸入錯誤時，會發生什么？webpack dev服務器通過其websocket連接，嘗試將一堆調試和堆棧信息發送到開發人員的屏幕上。這些信息在惡意網站也能看到：
現在，我們有了代碼片段、文件路徑、位置等各種有用的信息。甚至當開發人員最終意外地在包含有用數據的代碼行上鍵入錯誤時，得到的結果會更好：
現在你可獲得一份開發人員的AWS開發人員證書副本。
沒有圖表，任何技術設計都是不完整的。這里展示了圖像化的代碼運行：
為了簡化圖表，此處省略了正在運行的本地web服務器，并假設websocket服務器直接來自于編輯器中。
某些瀏覽器選項卡上的惡意網頁會自動連接到用戶計算機上打開的WebSocket。當敏感數據通過該套接口發送時（從希望通過僅本地通道進行通信的進程發送），網站可以接收該消息數據，并將其轉發到任何外部數據庫。
限制因素
值得注意的是，該攻擊向量很小。必須誘使不知情的用戶訪問網站，并在他們開發JS代碼時繼續使用它。然后，必須等待在較為幸運的情況下從他們的編碼錯誤中收集一些數據，這也許有助于找到從這些數據中獲利的突破口。
圖源：unsplash
綜合考慮
然而，許多網站已經在使用websocket端口掃描技術，而沒有太多開發人員能意識到這一點。考慮到JS工具傾向于使用那些眾所周知的端口的小部分，編寫一個腳本來巧妙地過濾react Dev通信量并不是特別困難。
想象一下，一個為Twitbook工作的內部開發人員只需在其編輯器中按save鍵，就會導致訪問令牌或內部服務器地址被泄露給錯誤的訪問者。
這有點嚇人，正常開發人員通常會希望在他們選擇的代碼編輯器中按下save鍵時，是不會將數據泄漏到第三方web服務的。而這增加了這種風險，足以讓人有點擔心。
補救
筆者的建議是這種嘗試攔截JavaScript熱加載機制的方法，它是筆者所熟悉的websockets的唯一通用方法。Discord也使用websockets，但匆匆一瞥并不會產生任何明顯的效果，因為該通道以公共互聯網為設計目標。
令人擔憂的是，僅僅這一個用于重新加載的單向通信簡單用例，就將如此多的潛在信息暴露給了那些惡意網站。websockets的其他用途（對于不是為公共互聯網設計的數據）也可能受到類似的威脅。
圖源：unsplash
爭論在于，webpack dev服務器應該進行一些身份驗證，或者使用備用的瀏覽器通信通道進行熱重載。瀏覽器/web標準為websockets實現源代碼策略的方式無疑令人驚訝。導致那些專為本地開發而設計的軟件以一種難以預料的方式暴露在公共互聯網上。
很期待針對瀏覽器中額外控制功能部分的修復。
