防止對 JavaScript 生態系統的供應鏈攻擊

供應鏈攻擊是 JavaScript 生態系統的大問題。在這篇短文中，我將概述一個簡單的安全措施，可以由所有 JavaScript 運行時（瀏覽器內和瀏覽器外）實現。這將防止當今困擾 JavaScript 生態系統的大多數供應鏈攻擊。

問題：權限繼承

這是最近發生的網站被駭客攻擊的事件：

• 研究人員將 Polyfill 供應鏈攻擊與龐大的模仿賭博網站網路連結起來

問題的核心是JavaScript 模組繼承了呼叫它們的應用程式或模組的權限。這對於瀏覽器內運行時和瀏覽器外運行時都是一個問題。

應用程式所依賴的模組版本可能會在應用程式作者不知情的情況下發生更改，這一事實使問題變得更加複雜。因此，即使所有依賴的程式碼都已經被徹底審查（這本身就是一個巨大的努力），如果依賴版本沒有被鎖定，這個努力就會被浪費。

為什麼不鎖定版本並使用基於 semver 的依賴項？嗯，這主要是因為如果模組發布者發布了錯誤修復，那麼最好使用修復的程式碼。這也是 esm.sh 等 JavaScript CDN 支援 semvers 的重要原因之一。

？網站如何受到影響

網頁瀏覽器是沙盒執行環境，因此網站匯入的第三方 JavaScript 模組 (3JM) 不會對最終使用者的裝置造成任何損害。

儘管如此，3JM 可以在未經網站同意的情況下使用設備的計算資源並發出網路請求進行比特幣挖礦等。

？脫離瀏覽器的 JavaScript 應用程式會受到怎樣的影響

某些瀏覽器外執行時間（例如 Deno）確實實作了限制 JavaScript/TypeScript 應用程式權限的措施。但由於以下原因，這些措施還不夠：

• 即使強制執行諸如 Deno 之類的權限系統，它們仍然允許 JS 模組不受限制地繼承呼叫者的權限。這意味著，如果應用程式具有完全寫入權限，則不應存取計算資源以外的任何資源的電子郵件地址驗證器可以在作業系統使用者不知情的情況下刪除使用者檔案。
• 應用程式通常以作業系統使用者的完全權限運作。例如，對於在 MDRB 等工具下執行的程式碼，目前無法限制正在執行的程式碼的權限。

目前的解決方案

目前，安全團隊已經建立了自動化流程，用於尋找在 NPM 等知名註冊表上發布的模組中的漏洞。這種安全措施有幾個缺點：

• 掃描已發布的所有已知模組的所有版本都非常耗費資源。
• 無法保證所有可用的模組都已掃描。

？解決方案：每個模組的權限

為了解決這些問題，我提出了一個新的每模組權限系統，該系統向後相容於 JS/TS 應用程式目前的工作方式。

這涉及一個新的可選權限配置，每個應用程式和模組都可以在其deno.json / deno.jsonc / package.json 文件中聲明。權限有 2 部分：

• requests.self — 這是應用程式或模組聲明它及其依賴項所需的權限的地方。
• requests.imports — 這是應用程式或模組聲明其同意分配給其依賴項的權限的地方。這是每個依賴項允許需要的權限的超集。

以下是 JS/TS 運作時如何使用權限：

• 當應用程式或模組導入模組M時，運行時會檢查M的permissions.self是否在導入器對M 。如果不是這種情況，導入會拋出錯誤（例如 PermissionError）。
當模組或應用程式嘗試執行不允許執行的操作時，也會引發執行時間錯誤（例如 PermissionError）。可以捕獲並處理此運行時錯誤，而無需中止應用程式。

權限的值將是這樣的：

與目前的解決方案相比，我提出的解決方案有幾個優點：

• 輕量級 — 發布的模組不需要掃描。
• 徹底 — 權限是在運行時強制執行的，因此如果使用正確的 JS/TS 引擎，那麼即使是未知的模組也不會被漏掉。

這看起來非常簡單。 JS/TS 語言無需修改。如果沒有權限配置，那麼我們會回到目前的情況，即應用程式及其依賴關係圖都具有命令列參數提供的權限 ∎

以上是防止對 JavaScript 生態系統的供應鏈攻擊的詳細內容。更多資訊請關注PHP中文網其他相關文章！