全文共2122字，預計學習時長9分鐘
圖源：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實現原始碼策略的方式無疑令人驚訝。導致那些專為本地開發而設計的軟體以一種難以預料的方式暴露在公共網際網路上。
很期待針對瀏覽器中額外控制功能部分的修復。
我們一起分享AI學習與發展的乾貨