以資安治理角度理解 OWASP Top 10 2021

2022/12/09

這次要講的 OWASP TOP 10 除了細項介紹之外,其實會講比較多會是以資安治理的角度去看這十項風險的部份。


這邊的話我會帶到的細項項目的介紹會比較快帶過,比較多會講修補跟預防的部份,這是去年 OWASP 公佈的 TOP 10 十大項的風險,跟早期的 OWASP TOP 10 不太一樣,它其實必非每一個都是純技術性的弱點,像是第四點的 Insecure Design,或者是第六點有漏洞或是過舊的元件,或者是像第九點 Logging 或是 Monitoring 的問題。其實很多像這類的風險,其實跟管理面向會比較接近,它並非純技術的部份。


這是 2017 到 2021 之間風險的變化,但因為時間有限的關係,所以這邊我不會做太多的介紹,對於它的風險提升、降低或者是合併、新增這塊,有興趣的話可以去 Youtube 果核數位那邊,這邊有做影片去詳細介紹這一塊。那這邊的話就可以直接進入第一個風險,是 Broken Access Control。


所謂的權限控制失效的部份,那所謂的存取控制措施,它是一個就是讓使用者,應該說開發者覺得使用者只能讀取,那他就只能讀取,所以他不可以去做新增、修改、刪除,這些都不行,那今天如果使用者可以做的話,就叫做『存取權限控制措施失效』。像這類的問題其實像在上次測試遇到的

很多的風險類別,例如說提權的部份就有水平提權跟垂直提權,垂直提權的意思就是,我今天是一個使用者,但是我可以使用管理者的權限,這就是一個垂直提權,那水平提權的部份,就是今天我是使用者,我只能看到我自己的資料,或是我只能修改我自己的資料,今天我可以去修改別人的資料或者是看到別人的資料內容,這就是一個水平提權的問題。

那水平提權的問題可以衍生到有 IDOR 流水號的問題,今天就是如果你的會員資料是用流水號去做存取,那它可以是 1、2、3、4、5 就是序號的方式去做存取,那有可能是一些可以猜測的方式去做存取,但這其實流水號的問題不在於你用序號去做存取,它是因為你的存取權限控制沒有做好,所以才導致說他可以,因為我又可以猜測你下一個會員是哪一個會員,或下一個訂單是哪一個訂單。因為沒有做好存取權限控制,會導致個資外洩的部份

那當然還有像 Cookie、JWT Token,或是 CORS HTTP Header 這些的都是屬於權限控制失效的問題。那 JWT Token 的部份,其實現在很常被運用在一些公有雲,或是一些新建的開發案中,那其實它有一個舊的 library,是可以允許它 Algorithm 使用 none 的,所以其實你如果是使用者想要搞事的話

那你就把它改成 none,然後後面的 signature 去把它刪掉,它其實就直接繞過存取權限,那其實這同時有兩個問題,一個是繞過存取權限,因為它原本 library 就有問題了。

另外一個問題就是它是舊的,所以也就是說其實應該要更新它的 library 這塊,這個是之後等一下會講到的別的風險問題,如何修補跟預防呢? 其實企業所要做的事情,就是將你的使用者權限做分級,那分級之後不同級別的權限,就要套用不同的存取權限,但是其實這樣的分級機制,應該要在 QA 階段就先做了,而不是到資安檢測階段之後,有問題了才開始做。

因為有問題之後開始做的話,就變成有洞補洞的問題,或者是你可能要單一頁面或逐一頁面,或是一個一個去套用它的設定,所以一開始先把它的分級做好,然後設定套用好的話,其實是一個比較好的管理的方向,那當然這個漏洞還有一些像是目錄存取,備份檔案等等的,其實這都是一些資訊洩露的範圍,還有一個是提到 API 的存取流量限制這部份,這個部份其實你可以透過 WAF,或者是一些第三方的套件去達到流量限制,因為這樣可以比較,其實這是一個類似緩解的問題。

那再來就是 JWT Token 的問題,因為它是一個 stateless 的 Token,所以洩露了就等於可以直接被使用,那這樣的狀況下,存取時間當然是越短會越好

因為像之前有遇過一個在測試環境跟偵測環境上,都使用了相同演算法跟相同 key 的 JWT,這樣的話它是一樣的 Token 就可以直接拿去使用,這些都是企業可以去注意的地方。

接著講的是第二個項目,是加密機制的失效,實作加密機制的話,首先是要先去盤點核心系統到底有多少機敏資料,機敏資料的話例如說你可能密碼還有信用卡卡號,金融業可能會有信用卡卡號的部份,那醫療業可能有健康紀錄的部份,那除了個資法之外,其實現在依照不同的行業別來講,每個行業都要遵守不同的,像 GDPR 或 PCIDSS 的標準或者是法律,這樣其實沒有遵守的話出了問題,基本是會有法律上的問題。那像這個問題,第一個當然一定是傳輸通道一定要做加密,那你在傳輸通道做加密這件事情的話,就會遇到憑證跟金鑰這兩個問題,那憑證的管理、驗證還有金鑰的管理

還有你加密演算法的選擇跟是否已經棄用,因為你選擇了使用最新的加密演算法,跟你允許使用哪些加密演算法是兩回事,你選擇使用最新的但你可能允許使用以前被淘汰的,那還是會有風險存在,你要去禁用淘汰的東西,那修補及預防的部份,像剛才提到的,像傳輸通道跟演算法的部份,就像最後兩點一樣,就是現在比較推薦就是 TLS 1.2、1.3,演算法的部份會希望是有迭代方法的,那還是一樣要搭配加鹽的方式來儲存,實作金鑰管理部份的話,可能就需要導入 HSM 的部份,像現在有很多的服務是上雲的,那在雲端上面其實有屬於雲端的 HSM 是可以去參考的。

但是這個部份大家可能要注意,就是因為不同的企業要去遵守不同的法規,或者是過不同的稽核,有一些法規目前還是不接受雲端的 HSM,所以這個部份是可以去參考的。

再來就是第三點的 Injection,那 Injection 這個應該是大家最熟悉,然後也已經聽到不要再聽了,所以這邊就快速的做介紹,那它就是一個攻擊者可以在參數裡面輸入一些指令,然後讓目標去執行這個指令,這就是一個所謂的 Injection 的攻擊。包含 XSS 也被納入這個攻擊裡面了,那 XSS 的差別就是前端,前端執行那其它是後端執行,修補跟預防的部份,除了命令跟查詢這兩個東西是要分開之外,目前其實比較多人使用的是正規表示式,或者是白名單的方法,但是其實在臺灣開發角度而言,其實因為有些參數相較比較複雜,所以你要去做正規表示式或者是去做白名單,有點難做到,那就會選擇使用 Prepared Statement或者是使用 ORM 的方式去做預防。

那其實這邊 OWASP 還有提出一個方式,是用 LIMIT 去控制輸出量這點,但這點其實不叫做修補也不叫做預防,它只是叫做緩解,就是你被打的時候

它可能打一次輸出量會比較少,那多打幾次或者是那個人夠厲害的話,駭客夠厲害的話其實還是有可能被繞過的。

那再來是第四點的 Insecure Design,這塊其實我這邊可以直接做舉例來講的話,像 OTP 這個部份大家都已經,沒有實作過應該也用過,那這個部份其實你說有實作過,實作了 OTP 的流程,但是實作了怎麼樣,那你的 OTP 是不是真的是隨機數,如果我在做滲透測試的時候多按幾次重送,發現數字都一樣,那就代表說你根本就不是隨機數產,或是可能資料庫的有去對應使用者,那也有可能是隨機數,但是它從來沒有過期,你就算重產了 10 組 OTP,結果這 10 組都可以用,那當然還是也有發生過就是像你的回應,就是 OTP 的回應是在 response 的封包裡面,那我也根本不需要去用裝置去收

像這類的其實就是,你以為你做了 OTP 的流程,但是你的流程有缺陷,那你的流程有缺陷這就是屬於一個不安全設計的問題。

那這邊還可以再舉一個例子就是去年網銀的部份,因為去年的時候有很多簡訊釣魚的部份,那駭客可能就會騙這三個資料,身分證字號、用戶代碼跟網銀的密碼,那其實現在手機轉帳這個風險,比較沒有問題的原因是因為,手機在 App 轉帳的時候它是會認裝置的,所以它基本上有些 App 轉帳真的只需要輸入密碼,當然有些比較嚴謹的 App 它還是要去收 OTP,可是這個問題會發生在哪裡? 就是你用網站,它的網站去轉帳,那網站轉帳其實通常你要做到完整的話,你應該還是要做 OTP 或者是你要用晶片金融卡插入,或者是你要用你綁定的那個裝置去做驗證,如果只收這三個資料的話,其實靠釣魚駭客就可以去幫你轉帳了,這就是一個在一個身上設計的問題,你從雖然都是轉帳流程,但你一個用在 web 上面,一個用在 App 上面,它其實就是有不同的設計概念。

那這一部份要如何預防,其實還是需要一個完整的 SSDLC 或是 SSDF 的流程,那其實這部份預防的方式,其實都是一個在,需要在早期的架構去做評估,在你開發之前就應該要評估好這個流程該怎麼做,然後也需要做一個 modeling 的東西,但是其實要導入這個制度跟完整去做到這個流程,是需要人跟時間去達到的,所以這同樣成本相對比較高,但是基本上是一個很好推薦可以去參考的方式就是,可以知道有這個方式去做預防。

第五點是安全設定缺陷,那安全設定缺陷的部份,例如說我們今天開了不必要的 port,跑了不必要的 service,或者是頁面帳號特權等等的,假設說你今天的一個營運環境在安裝好的之後,它就會預設開啟哪些 port 跑起哪些服務,但其實你根本就沒有需要用到,你沒有需要用到你一定不會去注意到它,也不會去 maintain 它,那它如果哪一天有風險了,或是它本來就有風險的話,其實它就會變成一個目標,所以其實沒有用到的東西基本上是不需要去開啟的。或者是像你可能原本是在用某一個廠商的服務好了,那今天這個企業不用這個廠商了,要換一個,換一個服務或是去做別的事情,那原本的東西你也沒有把它關掉,就接著直接去做其它的服務了,那像這樣的話其實都可能會有問題。

像是例如說,你網站開啟的時候會有預設帳號,或是一些 default page,這些其實都是要去做刪除的,還有一些怎麼預設帳號密碼等等的,那其實像這些的安全設定,例如說後面的未使用安全設定,未設定安全參數等等的,其實都是需要一個自動化流程,那自動化流程會比較方便,比較不會說過程比較不會那麼繁瑣,或者是比較不會漏掉,不管是企業要以合規性來講,還是要用標準化的方式來制定,都是需要這個流程的,不然的話可能會有高風險的危機。

像是這個 Spring Boot Actuator 這個監控點設定,它這個是一個開發在用的東西,他在測試環境上開基本上有一點類似 debug mode,但是它可能在部署上去正式環境的時候,就已經用相同的設定在正式環境上開啟了。那開啟了之後可能,第一是他開發本身,不管開發知不知道,因為有可能開發知道他不覺得它可能成為攻擊的目標,那再來就是這個 Actuator 它在本身就已經有 XXE 這個漏洞,而 XXE 這個漏洞在去年早就被合併,就是 A5 的安全設定缺陷了,這個漏洞又可以導致 RCE,所以它就是一個屬於安全設定導致比較嚴重風險的問題。

那修補及預防其實跟 A4 有一點像,它還是需要自動化流程,因為它都是設定問題,它都是設定上的問題,所以需要自動化的流程會比較,它要設定的東西太廣了,你可能框架、可能 OS、可能一些 Header 什麼的,所以其實用一個流程去擬定好那個範圍,是會一個比較好的方式。那其實現在很多大型企業會實作一個方式,用 Secure by default 的方式去做,例如說他們會做一個 OS 的 image,然後那個 image 本身就已經是有安全設定的狀態

所以企業內部如果要用到這個 OS,不是去官網下載,而是去用公司內部做好的那個 image 去灌,然後接著就是像現在有些雲端服務,它本身就是 Secure by default 的設定。

那再來是第六點的部份,那第六點就是在講危險或過舊的元件,那危險或過舊的元件其實很多地方都會用到第三方元件,作業系統其實本身也會有用到一些元件是被淘汰的,那軟體、套件、函式庫、框架等等的,這些東西使用的官方。你如果是使用了官方已經淘汰的版本沒有去更新,或者是開發者可能抱持著先求有再求好的心態,你根本就不知道自己使用了哪一個版本,或是哪一個地方的東西。那接著是可能你用了,但是並沒有去執行定期與執行掃描,或者是執行了掃描了,但是沒有去安排修補的時間或是沒有立刻修補,那修補後也沒有去測試它的相容性。或者是你用了沒有去使用某些安全設定這些,那其實這樣的話就會造成一些到時候遇到風險的時候,就會要去仰賴第三方套件去做檢查。

這邊有一個很有名的案例就是 LOG4J,那 LOG4J 本身應該是前年釋出來的,那它當初一出來就是一個 RCE 的大洞,這時候很多企業就會開始很緊張馬上開始去盤點說,到底有多少資產用到了這個元件,跟這個相關的元件或基於這個元件開發的其它的東西。那其實這是一個你平常如果沒有在做控管的話,那這是一個非常困難的事情,就這時候發生了再去盤點其實很難,加上這個漏洞,這個 LOG4J 套件又是一個非常老舊,然後只要用到的話其實要做 LOG 就會用到的套件。那第一個做法你可以說用黑箱,可是黑箱有問題就是你必須去判別,因為它 payload 相對複雜,那它的結果也相對複雜

你必須判別說這個漏洞的真偽或是有沒有誤判,或者是是不是你要找的這個問題點。

那再來就是也可以做白箱,那白箱的話可以做一些 Dependency Check,或者是用工具去把它的 jar 檔拆開來,看你裡面到底用了什麼套件等等的那其實這個問題當初出現的時候,就是把很多企業都搞得雞飛狗跳,那對於修補及預防的話,可以參照 NIST 去年 release 的 SSDF,那其實會推薦去導入 SBOM 來做,但是 SBOM 是一個相對高成本的東西,所以稍微降低成本的話可以用 open source,就是 OWASP 的 Dependency Check,這個部份其實因為是,這就是要引用它的 SDK 去做套入開發流程裡面,然後去做套件版本的統計,這個是相對於來講成本較低,但是就是要開發者可能需要去學會使用這個套件,那這個是目前比較新型態對於這個風險的做法。

再來是第七點,第七點是認證與驗證的機制失效,這塊有些部份可能會跟 A01 有些相似,但它這塊非常 focus 在對於 session 的保護,還有帳密的保護跟密碼 hash 等等的,像帳密的保護的話就是保護被暴力破解或是被撞庫,那密碼 hash 的部份當然就是,第一是不存明碼,第二就是你有沒有用太弱的演算法,因為像其實很多營運很久的環境,它可能很早以前就已經用了,就有在把密碼做 hash 了,但其實那個 hash 現在已經被淘汰了,可是可能也沒有發生什麼事情,還可以繼續營運,就沒有去把它更新密碼 hash 的演算法。

那這其實就是一個潛在的風險,那當然還有繞過忘記密碼流程的部份,例如說可能可以猜測,他忘記密碼會寄 email 到你的信箱,那它信箱裡面的網址可能可以猜測,你多寄幾次你可能就猜出來說,又是一個可以猜測不是亂數。或者是你可以改變他 email 的地址,可以寄到我自己這裡等等的這些流程,那這些都屬於 A4 的不安全設計的部份。那對於 session 的保護,當然就是 session 不可能,session ID 不可能放在 URL 上面,那還有就是登入後會重新派送,當然還有就是登出之後要正確的註銷,或者是需要有時效性,很久沒有用你就應該要把它登出,那修補及預防的部份當然就是導入多因子驗證,open ID 或者是 single sign on。

接下來下面的部份比較多都是屬於一些 policy 的問題,例如說登入失敗的次數,你要不要限制他的次數,很多的金融業都有限制,像你 iPhone 解鎖也會有限制,或者是你登入失敗到一定次數的時候,是鎖住還是延遲五分鐘後才可以再試,一個小時後才可以再試,或者是像登入失敗的 response 的內容,到底是帳號打錯還是密碼打錯,還是帳號或密碼打錯,如果回覆的內容有差異的話,會讓攻擊者是可以推測出自己的錯誤導致帳號被列舉的部份

那其實像這類型的設計。其實都可以在開發初期的時候就先設計好,就是不需要到出了問題之後再回去修補,那這方面的話就是一些也是開發初期要做到的事情。

再來是第八點的軟體跟資料的完整性失效,那這一塊就是在講完整性驗證的問題,那它就是一個對於來自外部的套件,或者是從外面回來的資料都要去確認內容有沒有被竄改過。那使用不信任的第三點的使用不信任的來源套件跟函式庫那個問題,它就是在講供應鏈攻擊,就是因為現在駭客很喜歡去攻擊 repository,他很喜歡去打向套件的位置,函式庫的位置跟模組的位置,那他會去把他的有問題的 code 去放在第三方套件裡面。那這時候你如果使用了他的第三方套件的話,你這個軟體早就有問題了,到時候出去的產品就是有問題的產品,所以這方面的話也是企業需要去注意的地方,那這個項目主要就是在講反序列化的問題,跟第三方套件信任的問題。

那修補跟預防,完整性當然是透過壓碼的方式去做驗證,當然是防止篡改、防止重送、防止反序列化的問題,那信任來源取得,函式庫跟相依套件

其實現在很多有些行業已經開始做,就是自建 repository,自己企業內部的 repository 除了自己自幹的 library 之外。你如果要引用外部的話,也是外部最 stable 的版本,確定現在是安全的版本之後,直接拉進來企業內部存放,在企業內部就可以做完整性驗證的部份。

接著就是 A9 的,A9 的資安監控及紀錄失效的部份,首先就是你在運行的時候一定要有 LOG,很多時候都是沒有 LOG 的問題。再來就是有 LOG 紀錄的內容不足,或者是一些出事了沒有觸發資安告警等等的。那這一部份可能就需要 SOC 去監控這些 LOG,當然也有 open source但是臺灣比較常見的話是導入 SOC,那這就是看目前,目前各單位是有沒有在做這方面的告警跟預防。

那對於存放 LOG 跟監控這一塊需要做到的,第一就是日誌要完整紀錄並且保留充足的時間,因為我們常常遇到的問題就是,今天出事了我要看過去的 LOG,結果 LOG 只存了一個月,只有最近一個月,所以其實前面完全都沒有辦法去回溯。那再來就是它需要符合一般日誌的常用格式,這個原因是因為像剛剛說的,其實以臺灣現況來講,比較常導入 SOC比較不會去選擇用 open source 去另外實作它,那如果要導入 SOC 的話,就必須是通用格式

會比較容易介接,果核這邊是有提供 SOC 相關服務的,所以有興趣的話可以到果核攤位去詢問 SOC 這一塊。

對於 LOG 的保存,當然還是要去防止 A03 的注入攻擊,還有就是你還是要做完整性驗證,防止被篡改,然後適時地監控跟告警,要有監控跟告警機制,所以也就是說你要會你要寫符合你們企業的 Rules 去對做告警跟監控,那當然還有資安事件應變等等的這些。


那接下來是講到最後一點的是 SSRF 的部份,那其實 OWASP 已經蠻久沒有把單獨的一個技術項目,去做成一個弱點了,就是像以前可能 XXE 獨立在外面,或者是 XSS 獨立在外面,那其實已經很久沒有去特別拉出一個新的,以前沒有出現過的把它單獨成一個項目,那表示這其實是接下來會比較需要重視的地方。那其實伺服器請求偽造這一塊,需要注意的地方是即使你已經有防火牆了,或者是有 VPN 或是其它 ACL 的保護情況下,他還是可以達成攻擊的,因為他發出的請求是合法的,那對於他的攻擊的方式的話,我們這邊直接帶一個例子,這是一個我們把果核官網貼到 Line 的頁面上去那其實現在大家有在用 IG、Messenger、Line 這些,就會知道 Facebook 的事情,你把網址貼上去它會自動去拉一個縮圖,那這是因應行銷的關係會去做這件事情,那畫面就是我們把官網縮圖拉下來。

所以像我剛剛那個畫面的流程,就是從左邊進了防火牆之後,到中間虛線往下就是一個正常的拉縮圖的方式,但是如果他有 SSRF 的問題的話,你可以達成 SSRF 的攻擊的話,你可以去嘗試看他內部,你可以去猜測內部有什麼服務,或者是你可能已經知道這個企業內部有什麼服務了。那像這些服務,其實它都會有一些 default URL 在,你可以去猜可能 Mongo DB 或是 redis 這些,看看有沒有可不可以從裡面拉出資料出來,那當然也有可能去假如說裡面有 Amazon EC2 的話,那 169.254.169.254 這個 IP,他可能就可以去針對這個 IP 再往雲上去做攻擊。

所以這個 SSRF 攻擊,有點類似說你把 AP 去當跳板去做,對內部做攻擊,那他其實除了存取內部的資源之外,也可以把指令往內部塞進去。那對於如何修補跟預防的部份,這可以分成網路層跟應用層。那網路層的部份,第一個就是切 VLAN,就是把 VLAN 切開來然後確定它,控管好它的 outbound

或者是你去實作另外一台 AP,然後把它放在最前面,那只有那台 AP 可以對外,其它就是只能連那台 AP,就限制他能連線的位置去做防禦,又或者是在應用層上去做。

那應用層上做的這塊,它其實我們現在目前最推薦,就是使用白名單的方式去限制,你用白名單的方式去限制他只能連哪裡,千萬不要使用黑名單,因為在 SSRF 這一塊,黑名單可以繞過的手法太多了,所以非常不推薦使用黑名單,黑名單這部份跟 SSRF 比較詳細的介紹,可以去參考 Orange 在 2017 年發表的 paper,因為它那時候就是對 SSRF 這個攻擊做了非常深的研究,所以才有造成了 2021 它這個 SSRF 直接被發揚光大。那這個問題其實如果是到雲端上的環境來講的話,也會有更深入的問題,所以可能是需要越來越被重視的部份。

最後是結論,結論第一點就是,像我剛剛介紹到現在你可能會發現說,OWASP TOP 10 不是每一個都是技術性問題,很多是治理、管理面向的問題

那這些問題導致應該可以理解,弱掃是沒有辦法去解決全部 TOP 10 的問題,不是你要執行弱點掃描的時候,選擇我要掃的範圍是 OWASP TOP 10

它就可以解決這個全部的問題,那再來就是後續企業應該要怎麼做,那其實通常會建議去實作 SSDF 的流程,就是剛剛一直有提到 NIST 在去年發佈的那個 SSDF。那這個流程除了提到的黑箱、白箱、第三方套件的檢查,這些都是原本 DevSecOps 有的東西之外,它還包含了開發環境架構管理,那或是工程師怎麼操作等等的,它是一個相對 DevSecOps 跟 SSDLC 更完整的一個流程,是可以去參考的。

那最後一行的 SAMM 其實也有包含在,剛才提到的 SSDF 流程裡面,那再來就是開發工程師會需要更多的,因為可能開發工程師大部份,除了剛剛提到的可能先求有再求好之外,在學習開發的過程中也沒有學習太多資安相關的東西,所以其實是需要有更多的安全程式碼的教育訓練,去訓練這些開發工程師。

那最後就是 SOC 的部份,那 SOC 的部份當然還是建議導入 SOC,甚至是延伸到收 AP 層面的 log,以上是我今天的演講。


其他動態