運行Node.js應用程序的開發(fā)者需要檢查他們是否在使用pac-resolver JavaScript庫，如果最近沒有更新，建議及時進行更新。
一個非常流行的NPM包，被稱為“pac-resolver”的JavaScript編程語言已得到修復，以解決一個可能影響很多Node.js應用程序的遠程代碼執(zhí)行缺陷。
pac-resolver依賴項中的漏洞是由開發(fā)人員Tim Perry發(fā)現(xiàn)的，他指出，只要操作員嘗試發(fā)送HTTP請求，本地網(wǎng)絡上的攻擊者就可以在Node.js進程中遠程運行惡意代碼。Note.js是流行的JavaScript運行時用于運行JavaScript Web應用程序。
Perry解釋說:“這個包在PAC - proxy - agent中用于PAC文件支持，然后在proxy - agent中反過來使用，然后在Node.js中用作HTTP代理自動檢測和配置的標準首選包?！?/p>
Perry指出，PAC或“代理自動配置”指的是用JavaScript編寫的PAC文件，用于分發(fā)復雜的代理規(guī)則，這些規(guī)則指示HTTP客戶端對給定主機名使用哪個代理，這些規(guī)則在企業(yè)系統(tǒng)中被廣泛使用。它們分布在本地網(wǎng)絡服務器和遠程服務器上，通常通過HTTP而不是HTTPs不安全。
這個問題影響范圍很廣，因為Proxy-Agent被用于Amazon Web Services Cloud Development Kit (CDK)、Mailgun SDK和谷歌的Firebase CLI。
Perry 在博客文章中指出，該軟件包每周有300萬次下載，并在GitHub上擁有285,000個公共依賴存儲庫。
該漏洞最近在所有這些包的v5.0.0中被修復，并在上周被披露后被標記為CVE-2021-23406。
這意味著大量使用Node.js應用程序的開發(fā)人員可能會受到影響，需要升級到5.0版本。
在Node.js應用程序中，它會影響到任何依賴于5.0版本之前的Pac-Resolver的人。如果開發(fā)人員做了以下三種配置中的任何一種，它就會影響這些應用程序:
顯式使用PAC文件進行代理配置
在啟用WPAD的系統(tǒng)上閱讀和使用Node.js中的操作系統(tǒng)代理配置
使用代理配置(env vars、配置文件、遠程配置端點、命令行參數(shù))，從您不能100%信任的任何其他源代碼自由地在計算機上運行代碼
佩里表示，在任何一種情況下，只要您使用此代理配置發(fā)送HTTP請求，攻擊者(通過配置惡意 PAC URL、使用惡意文件攔截 PAC 文件請求或使用 WPAD)都可以在您的計算機上遠程運行任意代碼。
代碼安全要加強重視
管理者應該留出時間來處理漏洞及其他安全相關(guān)事項。在添加一個新的代碼庫時，開發(fā)人員通常將功能和許可視為重要的考慮因素，而并不認為安全性同等重要。63%的人表示他們在評估新代碼庫時總是考慮許可，84.2%的開發(fā)人員在評估第三方代碼庫時不總是考慮安全性。
大量調(diào)查顯示，幾乎所有現(xiàn)代企業(yè)應用程序中都不同程度地存在易受攻擊的第三方代碼庫和開源代碼。如今企業(yè)應用程序中平均包含多達528個開源組件，在每個代碼庫中平均發(fā)現(xiàn)158個漏洞，其中很多是關(guān)鍵漏洞。
因此，當應用程序中的第三代碼方庫不能保持在最新狀態(tài)時，對企業(yè)來說后果可能很嚴重。首先，違規(guī)風險可能會更高，其次是增加了補丁的復雜性。漏洞時間越長修補就越復雜，打補丁所需的時間就越長，破壞應用程序的風險也就越大。
對于既是直接依賴又是傳遞依賴的庫，修補可能需要長達2.5倍的時間。這同樣適用于復雜的漏洞，例如任意代碼執(zhí)行缺陷，與典型問題相比，修復這些漏洞可能需要兩倍的時間。遠程代碼執(zhí)行和拒絕服務錯誤也需要更長的時間來解決。
在敏捷開發(fā)的今天，越來越多的開源代碼及組件被開發(fā)人員引入到應用程序中來，代碼安全關(guān)系著系統(tǒng)安全，影響著網(wǎng)絡安全。隨著DevsecOps的實踐，安全逐漸從一個專有的檢測部門貫穿到整個開發(fā)流程當中，并且第三方庫的不及時更新更為代碼安全帶來重大隱患。一方面，在靜態(tài)代碼階段應及時通過靜態(tài)代碼安全檢測工具及開源代碼安全檢測工具對編寫的代碼進行安全監(jiān)控，另一方面加強開發(fā)人員對安全的重視，制定一定的安全規(guī)范在一定程度上能減少問題代碼的產(chǎn)生。Wukong(悟空)靜態(tài)代碼檢測工具，從源碼開始，為您的軟件安全保駕護航!
參讀鏈接：
www.woocoom.com/b021.html?i…
www.zdnet.com/article/thi…
