OWASP Top 10 2021 十大常見的弱點與風險,如何做好企業資安防護?
今天介紹OWASP Top 10 2021 企業指南
第一章OWASP 組織與Top 10 的項目簡介
第二章 OWASP Top 10 2021 年度項目的變更狀況
第三章OWASP Top 10每一個項目的狀況及結果
OWASP 組織與 Top 10項目的簡介
OWASP 是一個網路安全的計畫,這個組織是一個全球性的非營利組織,
目前全球有82個分會,台灣目前也有一個台灣的分會,主要的目標是去解決目前網路軟體的安全標準,及工具和技術文件,所以整個 OWASP 的專案其實有囊括很多部份,除了Top 10網頁應用程式的安全標準之外,還有開發類似 ZAP 這樣的工具,它是一個很大型的非營利組織,在全球的資安業界有相當大的影響力!
而OWASP Top 10 是 OWASP 組織最知名的計畫,從 2003 年開始調查近年度各家資安公司或組織所執行的專案中所有漏洞的弱點與風險,包括 MICRO FOCUS、HCL、Bug Bounty 的 HackerOne、Contrast Security 、WhiteHat等公司,將其調查結果會總結出十大項的網站風險與弱點,則結果可以瞭解更多目前資安圈的狀況。
OWASP Top 10 2021 年度項目的變更狀況
我們先來看 OWASP Top 10這10 個項目的狀況,今年的有 3 項是新進榜的項目
分別新進榜的弱點是A04、A08 跟 A10 ,同時也有一些項目是被合併的,2017 的 Injection 跟 A07 Cross-Site Scripting 的部份這兩項是被合併的, 2021 與2017 相比變更情況說明:
A01 的 Injection 和A02 的 Broken Authentication 都有下降的狀況,其中 Injection 的部份下降之外,同時 A07 的 XSS 也被併進來 Injection 的內容,而Broken Authentication部份從 A02 降到 A07;A03 的 Sensitive Date Exposure 資料暴露將其它相關的一些加密問題合併了變成一個大的項目,所以從 A03 往上升到 A02;
Broken Access Control 從 A05 一次升到 A01,當中BAC 的項目從之前比較少的弱點大規模的合併了非常多 CWE 弱點;A06 的 Misconfiguration 設定錯誤的問題
從 A06 升到 A05;A09 的使用有問題元件的這個部份A09升到A06;A10 的 Insufficient Logging & Monitoring 的這個項目從 A10 拉到 A09,由此推論目前企業針對系統的紀錄及監控依舊相當重視。
接下來是合併的變化,A04 的 XML External Entities 從 A04 併進 A05 的原因是
XML 的 parser 的設定,目前是被視為一個 Security Misconfiguration ,因此從 A04 合併A05 為一個合併性檢視; A07 的 Cross-Site Scripting 的弱點是一個前端的 Injection以目前的情況是協會認定可以被合併去計算的,所以從 A07 合併 A03 做一個合併的檢視;A08 的 Insecure Deserialization反序列化的問題,是一個在傳輸的過程中完整性校驗不足,所以將反序列化的問題合併於軟體及資料的完整性失敗的問題,這是OWASP發布今年2021的Top 10 變更的狀況。
OWASP Top 10每一個項目的狀況及結果
A01 Broken Access Control 權限控制失效的介紹
A01 2021 權限控制失效的這個部份基本上會先去確認使用者的權限控制,存取控制措施讓使用者不能執行在預期權限之外的行動,意指所有的頁面都需要有權限的控制,包括伺服器上所有的資源都需要做存取控制的措施。如果這個措施的失效會不會導致資訊洩漏?或是資料被修改?或是資料會有損壞的情況?或者可以做提權?讓使用者可以執行超出原本自己權限的功能。
這個項目涵蓋很廣,從早期的 IDOR 這樣子的項目已經拉寬到除了一些驗證的問題之外,也包含 csrf的問題,以下列了幾點:
1.違反最小權限或是預設拒絕的,很常見的問題一個頁面可以讓任何人來存取。
2.透過修改 URL 或是 HTML 頁面過存取控制的檢查,開發者在前端做一些權限控制,或是在 URL用流水號的方式去記錄資料,讓攻擊者可以輕易的透過一些修改繞過存取控制的檢查。
3.竄改主鍵可以修改其他用戶的紀錄,在 IDOR的項目中的流水號的問題。
4.缺少存取控制的 API 是可以直接進行 POSTPUT ,或是 DELETE 的操作,指的是 API 是沒有權限可以直接做存取。
5.權限的提升
6.中繼資料操作,例如 :JWT 的 token 跟 cookie 都是可以被重送(篡改、修改)一些隱藏的欄位,而導致這項的狀況。
7. CORS 錯誤的設定,目前大部分網站的 Web API的 CORS 的 Header 都會有一些錯誤的設定。
8.未經身份驗證的使用者可以強制去瀏覽一些需要驗證的頁面,與第1點類似。
A01 Broken Access Control 如何做修補跟預防
首先需要確認所有的存取控制都應該在伺服器端,或是無伺服器的 API 做執行,因為有少數的開發者會在網頁前端做一些驗證的動作,攻擊者透過修改封包可以繞過這些驗證,所以很重要的觀念是在伺服器端須身份的確認。
逐項的說明如下
●除了公開的資源之外,預設為拒絕存取
例如: Amazon S3 的 buggin 的 resource通常是設定為公開的,如果有儲存一些機敏資料的時候,它應該要是拒絕存取的情況,所以網站的所有資源都應該一次性的做盤點,確認網站中的資源是公開,或者是私人的情況,預設應該是拒絕存取的情況。
●一次性的去建立你的存取控制的措施,後面在整個 Web 裡面重複的去使用透過 SDK 或者是 Library 的方式去建立 Access Control,每一個頁面可以去引用這一個功能,比較全面性的身份存取的驗證措施。
●模型的存取控制措施應該要去紀錄它的所有權每一次存取、創建資料,或是更新、刪除紀錄的時候,比對這個使用者跟紀錄之間的關係。
●獨特的應用程式的業務限制,應該要用領域模型做強化領域模型的部份可以去設定目前的業務流程應該要是什麼樣子。
●停用 Web 伺服器的目錄列表確認備份的檔案或是檔案中繼的資料不在 Web 的目錄中,例如:git 這樣子的檔案或是備份的檔案,如果被攻擊者抓下來之後,攻擊者可以確認整個 Web 應用程式中的所有程式碼的部份。
●紀錄你的存取控制失效,一個適當的時間內去警示管理員例如:一個重複性的登入失敗,可能是暴力破解的狀況,應該要做適當的紀錄跟警告。
●對 API 和 controller 進行流量限制重複性失效自動化工具做暴力破解的攻擊產生大量封包時,應該要有一個流量限制。例如:五分鐘內登入十次錯誤,會將使用者先暫時阻擋掉,讓他不能登入
這樣的情況應該要納入程式設計裡面
●Session網站辨識身份機制的狀態,分成兩個部分
(1)有狀態的 Session
例如: cookie的內容登出之後在伺服器端讓它失效。
(2)無狀態的 Session 的對話紀錄
例如: JWT 的 token設定一個最短存取時間,本身的內容去做完整性驗證,
以確認 token 的有效性,所以設定存取時間的時候,須設定一個最短可以使用的存取時間去最小化攻擊者的機會所;而JWT 的 token 需要做一個比較長時間存取的時候
應該要去遵循 OAuth 的標準,讓它會有一個失效的情況。
以上幾點Broken Access Control 修補方式的概念,開發工程師和QA 測試工程師在 QA 的期間應納入跟存取控制有關係的單元測試和整合測試,如果提早事前預防問題,或是遇到問題時可以盡快解決。
A01 Broken Access Control攻擊情境的範例
1.accountInfo
URL 的後面 acct 後面放入使用者的編號,透過使用者的編號可以去存取使用者的資料。通常使用者一開始進到頁面是看到自己的資料,當資料的細節在後端驗證的時候沒有去驗證目前這個 acct 編號與使用者本人是否為同一個人,故此在這情況下如果我去修改成別的使用者的編號,我就可以去存取其他使用者的資料,所以大部分應用程式中都有可能會有這樣的問題。
2.提權
appinfo是可以讓使用者去看到當下的一個頁面的狀況,或者是一個應用程式的狀況,假如說他去猜測到了另外一個管理員是admin_getappinfo的頁面,直接去存取而沒有去做驗證確認使用者是不是管理員,使用者就可以做一個垂直的提權,可以存取管理員所存取的資料。
A01 Broken Access Control對應的CWE 列表
Authorization Bypass 的項目包括了 CWE-566、CWE-639都是可透過一些 Key 的方式去修改資料,存取原本這個使用者不應該存取的資料,特別的是 CWE-352 CSRF 的部份列入了 Broken Access Control,這是一個比較特別的修改。再來,包括Path Traversal也列入了 Broken Access Control 的部份,所以OWASP 目前將 Access Control 的範圍擴大,其原本權限的限制變更到每一個部份。