如果只是產完 SBOM 就結束,那差不多就是去醫院健檢,拿到一疊報告後就收進櫃子,只是單純花時間精力,沒有真正獲得想要的結果 安全。
這篇要講的是拿到 SBOM 之後,怎麼從這一大堆文字中找出有風險的元件,並且安排下一步的更新計畫。
如果你是還不知道 SBOM 是什麼,或是不知道怎麼從你的軟體專案中產生SBOM,可以看我之前寫過的另一篇 使用微軟開源工具 sbom-tool 自動產生 SBOM軟體物料清單 先產出 SBOM,再回頭來看這篇。
OSV-Scanner 是一個 Google 提供的自動掃描工具,可以自動檢查的 SBOM,是否和 OSV database 這個開源漏洞資料庫內的紀錄相符,幫助開發人員更新有風險的元件。
可以在 OSV-Scanner官方網站下載 命令列執行工具(CLI) 進行掃描。
我這邊使用的方式是把使用微軟sbom tool產出來的 sbom 檔案 spdx.json 當作來源檔,用 -S 檔名 的參數,完整指令如下
C:\Downloads> osv-scanner_1.3.2_windows_amd64.exe -S manifest.spdx.json
2024年重測,發現預設結果會有附上 CVSS 分數
可以看到有 OSV URL 代表使用到的套件在資料庫中有記錄,可以點擊網址,看看風險影響的程度以及要更新到哪一個版本才是安全的。
我以其中一個掃到的風險舉例,我上面掃描檢測後看到使用的 jQuery.Validation 是 1.11.1 版,對應的網址是 https://osv.dev/vulnerability/GHSA-jxwx-85vp-gvwm ,打開後看到有說明
The project contains one or more regular expressions that are vulnerable to ReDoS (Regular Expression Denial of Service)
專案包含一個或多個易受 ReDoS(正則表示式拒絕服務)攻擊的正則表達式
最下方則是說明要更新到哪個版本 Fixed 1.19.3。
直接更新套件這種粗暴的作法通常很可能發生問題,建議還是去看一下官方網站是否有要注意的事,或是跨版號有沒有哪些功能不能使用。
剛好 jQuery Validation 我只有 2個網頁有使用到,可以事先評估更新後到時候要檢查的範圍不算太大。
我使用的是 Visual Studio 的 nuget 套件,因此更新也從這個方式更新,可以看到我在搜尋已安裝套件時, nuget 也幫我做了有漏洞的黃色驚嘆號標示,提醒我需要更新了。
更新很簡單,就用下拉選單拉到 1.19.3 以上,既然要升級就直接拉到最新版的 1.19.5
更新後,在操作畫面上檢查功能是否正常,這樣這一條就修復完畢了。
這個 jQuery Validation 的風險是 ReDowS (Regular Expression Denial of Service),他是什麼呢?
這是當使用者輸入正規表達式 (Regex)給伺服器做檢測時,可能會增加伺服器負擔,花費更多時間處理驗證,藉以消耗伺服器資源的攻擊。更多完整訊息可以參考微軟的 安全性簡報 規則運算式拒絕服務攻擊與防禦
可以看到攻擊類型是針對伺服器,換言之,如果你能確保你傳給的後端驗證程式碼沒有使用到 regex 驗證,那這個風險就真的只是風險,並不會造成立即性的威脅。
如果是很老舊的專案已經不再進行變更了,這也是一個修補方式,但要記得留下說明文件,提醒後面想要接手修改的人有這個風險,不要某天加入了 regex 驗證到後端,到時候就出事了。
在 Net Framework 4.5 之後,Regex 建構式中加入了一個選用的 TimeSpan 參數, 讓開發者可以自行決定 timeout 時間,例如把秒數設定為很短例如2秒,也可以防止攻擊。但必須要針對每個 regex 驗證的地方進行設定
說明與範例如下
如果前端程式碼使用的範圍非常大,但都是統一呼叫後端固定的一個位置,也可以選擇更新後端的部分,避開前端一大堆頁面,加快修補的速度。
自此,我們有了至少 3 種方式進行修補,分別為
更新直接受到影響的前端元件,並檢查是否可以正常運作
優點:掃描不會再跳這個風險有問題
缺點:有使用到的前端畫面要去檢查
確認風險影響範圍,做好風險評估,了解這個風險不會造成立即威脅並留下文件紀,防止後人誤觸。
優點:不須異動程式碼
缺點:要去檢視程式碼,評估這個攻擊是否能夠利用(得會攻擊手法)
從風險攻擊目標的後端程式下手,切斷可能的攻擊手法。
優點:不須更新直接元件
缺點:需要改動後端程式程式碼
這3種方法都是因應風險做出的處理方式,並不一定只有更新才能夠防範,挑選最適合的方式即可。
資安