API OWASP APIM 資訊安全 security API security risk API gateway digiRunner

API安全風險大揭密 (下集) - OWASP Top 10 API Security Risk 2023

彭福彬 Willie Peng 2024/02/20 23:01:51

0 781

Open Worldwide Application Security Project (OWASP) 組織陸續於2019與2023年都發表了最新的10大API安全風險，在上集中，針對2023年所發表的版本來說明排名第10名到第6名的風險以及digiRunner產品所能提供的安全防護功能。在本篇文章中，將繼續說明排名第5名到第1名的風險，並針對2019年與2023年的版本進行比較，最後提出重點歸納，期望能協助大家掌握API安全風險的變化趨勢以及應注意重點。

Top 5 : Broken Function Level Authorization (無效的功能權限控管)

基本說明

若API存取控制方式與規則太過於錯綜複雜的 (通常是透過不同層級、群組與角色來進行API的存取控制)，且針對管理功能的API與常規功能的API沒有清楚地切分，反而容易變成攻擊者的攻擊漏洞，讓他們得以存取到其他使用者的資源以及管理功能。

風險情境

有一個API會回傳系統中所有使用者的詳細資料，其使用方式為「GET /api/admin/v1/users/all」。此API應為管理者才能使用，但卻沒有透過功能授權來管控API的使用對象，了解API結構的攻擊者就可以透過各種預先的猜測去設法攻擊存取此API，藉以竊取系統中使用者的機敏資料。

防護措施

系統中應該要有專門負責功能授權的模組，當執行所有業務功能時，可以呼叫此模組來進行控管。此模組要能提供一致性的授權控管，並且要易於分析與管理，通常我們會透過系統現有程式碼以外的元件來提供這種保護機制。

n 此模組的執行機制應該預設為拒絕所有存取，且必須要針對每個系統功能去明確指派能存取該功能的特定角色。

n 查核所有的API是否有功能授權漏洞，並同時確認其業務邏輯以及群組階層。

n 確保所有管理相關的控制機制與功能皆有具備授權檢查與控管，只允許被授權的使用者群組與角色才能使用。

digiRunner 的安全保護功能 :

n 具備API Gateway 與授權伺服器功能，可作為API存取的授權控管模組，預設即為拒絕所有存取，須被授權的用戶端方可存取API。

n 提供API管理作業的控管與審核機制，被授權的人員方可執行API管理作業，且須完成各種必要程序(如功能授權)並通過審核後，方可上架開放API。

Top 4 : Unrestricted Resource Consumption (無限制的資源耗用)

基本說明

執行API請求會需要用到許多資源，例如網路頻寬、CPU以及儲存設備。另外還可能會用到email、簡訊與電話，這則會隨著每次API請求而需要付費。成功的攻擊者可以藉此來阻斷服務或增加營運成本。

風險情境

某社群網站提供「忘記密碼」功能，並透過簡訊來寄送一次性密碼給使用者去重新設定密碼。當使用者按下「忘記密碼」按鈕，系統會透過該使用者的瀏覽器發送第一個API呼叫請求到後端的API。

POST /initiate_forgot_password

{

"step": 1,

"user_number": "6501113434"

}

接著，該社群網站會從後端發送API呼叫請求給第三方合作夥伴Willyo的API，透過其API來發送簡訊。每則簡訊要收費0.05美金。

POST /sms/send_reset_pass_code

Host: willyo.net

{

"phone_number": "6501113434"

}

攻擊者可透過script 程式來重複呼叫第一個API數萬次，導致第三方合作夥伴Willyo發送了數萬次簡訊，造成該社群網站在短時間內就損失數千美元。

防護措施

n 採用較容易限制資源的架構，例如容器(Containers)或無伺服器運算(Serverless)。

n 針對所有傳入參數以及要傳輸資料去定義並確保其資料大小的最大上限，例如字串最大長度、陣列最大元素數量以及檔案最大上傳大小。

n 透過速率限制 (rate limiting)來增加Client端呼叫API的限制，且應針對企業需求進行調整，某些特定API可能需要更嚴格的限制控管。

n 限制單一API 用戶端/使用者可以執行單一操作的次數或頻率 (例如可透過OTP驗證控管)

n 增加適當的伺服器端驗證機制，針對查詢字串與請求表身等參數進行驗證，特別是用來控制Response 中回傳筆數的參數。

n 針對所有的服務提供者或有整合使用的API來設定費用支出限制。若無法設定費用支出限制，則應該設定付款告警。

digiRunner 的安全保護功能 :

n 提供速率限制 (rate limiting)功能，可針對用戶端設定每秒可呼叫API次數 (TPS)，藉以限制用戶端對資源的存取。

n 提供 API配額限制功能，可針對用戶端設定可呼叫API的次數，藉以限制用戶端對資源的存取。

n 提供存取來源IP限制功能，可針對用戶端設定來源IP位址，此用戶端須從該IP位址的主機上才可存取API，藉以杜絕非法程式的攻擊。

提供存取時段限制功能，可針對用戶端設定可存取API的起訖日期與每天時段，藉以限制用戶端對資源的存取。

TOP 3 : Broken Object Property Level Authorization (物件屬性層面的無效授權)

基本說明

API 執行後的資料結果大多會以物件與屬性的形式來回傳，此風險是指針對物件中的各個屬性並沒有適當的存取授權驗證，導致其中的資訊被未授權者取用或竄改。

風險情境

某社群網站可讓使用者上傳短影片，但會強制執行限制性內容過濾和審查，短影片須通過審查後才能開放點閱。使用者上傳短影片時，可以修改影片的描述，此時系統將會執行以下的API。

PUT /api/video/update_video

{

"description": "a funny video about cats"

}

攻擊者可以嘗試執行此API，並在傳輸的資料中加入惡意資訊「"blocked": false」。若此API沒有針對原本僅限於內部使用的物件屬性「blocked」進行存取驗證，則攻擊者將可以把此物件屬性的內容值由「true」竄改為「false」，這會導致原本狀態為鎖定而無法點閱的短影片，其狀態變成開放而可以點閱了。

{

"description": "a funny video about cats",

"blocked": false

}

防護措施

n 透過API存取特定開放的物件時，必須確認該使用者是有權限可以存取您所開放物件的屬性。

n 避免使用to_json() 以及 to_string()等函數去存取物件的所有屬性資料，而是應該要透過指定明確物件屬性的方式，讓API回傳你所想要的物件屬性資料。

n 有些開發工具的功能可將使用者的輸入內容自動綁定對映到後端的程式變數、內部物件或物件屬性。若可以的話，儘量避免使用這種功能。

n 用戶端(Client)只被允許更改它應該由它更新的物件屬性。

n 建構驗證機制去檢核API的回應結果(Response)，此機制應該逐項定義所有API函數的回傳資料，並於API函數回傳資料時被強制執行來進行驗證檢核。

n 依照業務面或功能性的需求，讓API只保持回傳最少且必要的資料結構。

digiRunner 的安全保護功能 :

n 提供JWE/JWS功能，除可進行資料加密來預防側錄偷窺，亦可進行資料簽章來預防竄改。

n 可透過Composer模組來進行API加值開發，現有API不須改寫即可快速擴增過濾、轉換、遮罩、檢核等機制，也可以避免自動綁定(data binding)問題。

TOP 2 : Broken Authentication (無效的身分驗證)

基本說明

大部分的API執行時需要通過身分驗證後，方可取得回傳結果。此風險是指身分驗證機制若沒有被正確地建置，攻擊者將可以破壞身分驗證令牌(Token)或利用這種缺失來冒充其他使用者的身分，而破壞了系統去識別用戶端/使用者的能力，就會損害 API整體安全性。

風險情境

某系統的使用者可以更新其帳戶下的E-mail位址資訊，系統將會發出以下的API請求。

PUT /account

Authorization: Bearer <token>

{ "email": "<new_email_address>" }

因為此API並不需要由使用者透過提供目前密碼來確認身分，攻擊者可以透過盜取授權令牌 (auth token)的方式來將某個使用者的電子郵件地址變更為攻擊者所指定的電子郵件位址，再透過重設密碼的方式來取得該使用者的新密碼，即可盜用此使用者的帳戶來進行惡意行為。

防護措施

n 確認API驗證的所有可能流程，例如行動裝置、網站或其他管道。

n 了解您的身份驗證機制，確認您瞭解這些機制是什麼以及如何使用它們。OAuth 與 API keys都不是身分驗證機制。

n 針對身分驗證、令牌產生或密碼儲存等機制，不需要再開發自己特有版本，建議使用技術標準。

n 重取憑證、忘記密碼等功能應該比照登入功能一樣，也須具備暴力破解攻擊防護、限速防護、封鎖防護等保護措施。

n 針對較為機密與敏感的操作，須再次進行身分驗證。

n 儘可能採用多因子身分驗證。

n 針對身分驗證功能應具備反暴力破解機制來減少撞庫攻擊、字典攻擊與暴力破解攻擊。這種機制應該要比API上的限速機制還要更嚴謹。

n 採用帳戶鎖定/驗證碼機制，防止針對特定使用者的暴力攻擊。採用弱密碼檢查。

n 不應使用API keys來進行使用者身分驗證，API keys只能用於 API 用戶端的身份驗證。

digiRunner 的安全保護功能

n 提供API管理介面，可檢視所有API列表，包含運作中或已停用的API，並可檢視各個API的安全控管設定。

n 支援OAuth2.1與OIDC標準。

n 支援多因子身分驗證 (MFA)。

n 提供限速控管功能(Rate limiting)。

n 提供API用戶端分級控管。

n 支援API用戶端、前端使用者、後端APIM使用者等帳號鎖定功能。

TOP 1 : Broken object level authorization (物件層面的無效授權)

基本說明

所謂物件(Object)通常是指API要存取各種資源，例如某個商店的銷售營收資訊或是某個使用者所撰寫的文章，而物件層面授權則是一種存取控管機制，用來驗證控管讓使用者只能存取他們被授權的物件。此風險是指攻擊者可以透過攻擊行為取得未被授權的物件，導致資料洩漏、遺失或竄改。所以若API功能會透過傳送使用者ID來存取資料來源時，這些API功能都應該被考量加入物件層面授權機制。

風險情境

以線上討論區為例，使用者可以發布、編輯、檢視與刪除討論區的文章，而此類系統通常是透過傳送文章ID給後端API來完成各種使用者所執行的功能操作。攻擊者可以藉由偽造傳送的其他使用者的文章ID，來刪除別人的文章。

防護措施

n 依照使用者政策與階層，來建構適當的授權機制

n 當使用者從Client端操作系統功能，並透過表單輸入來存取資料庫的資料時，所有功能被執行前都必須透過授權機制來檢查使用者是否有足夠的執行權限。

n 優先使用隨機且無法預測的代碼值作為每筆資料的唯一識別代碼(GUID)。

n 撰寫測試案例來評估確認授權機制的漏洞。

digiRunner 的安全保護功能

n 支援OAuth2.1 標準與授權流程。

n 支援OIDC標準與身分驗證流程。

n 支援API授權範圍(Scope)，可針對API用戶端定義資源存取範圍，並進行存取授權控管。

n 支援URL動態路徑參數，例如/api/{id}，並提供隨機亂數Long ID流水號，可作為存取資源ID的GUID，而不需異動原API相關資料結構。

提供API測試功能與操作介面，可快速輸入API參數來測試物件層面授權是否有漏洞。

2019 與 2023版本的比較與歸納

OWASP 組織在2019年便有發表Top 10 API Security Risk，以下針對2019年與2023年的版本進行比較與重點歸納 :

版本比較

排名	2019	2023	異動
Top 1	Broken Object Level Authorization	Broken Object Level Authorization	保留
Top 2	Broken User Authentication	Broken Authentication	保留
Top 3	Excessive Data Exposure	Broken Object Property Level Authorization	合併更新Top 3+6
Top 4	Lack of Resources & Rate Limiting	Unrestricted Resource Consumption	更新
Top 5	Broken Function Level Authorization	Broken Function Level Authorization	保留
Top 6	Mass Assignment	Unrestricted Access to Sensitive Business Flows	新增
Top 7	Security Misconfiguration	Server Side Request Forgery	新增
Top 8	Injection	Security Misconfiguration	保留
Top 9	Improper Assets Management	Improper Inventory Management	保留
Top 10	Insufficient Logging & Monitoring	Unsafe Consumption of APIs	新增

重點歸納

1.授權仍是重中之重控管範圍與深度加大

2023年版本，合併了2019年的「API3:2019 - Excessive Data Exposure」與「API6:2019 - Mass Assignment」，更新變成「API3:2023 - Broken Object Property Level Authorization」，而授權相關的風險項目就佔了三個 (Top1、Top3、Top5)，需要授權控管的範圍從API的功能到物件，延伸到物件屬性，所以需要實作控管機制的深度也加大。舉例來說，要針對API所存取的物件資料進行授權控管，常見的做法就是以角色為基礎的授權，針對使用者去配置角色，再針對角色去授權可存取的物件，這通常就會需要搭配後端系統與資料庫來實作。

2.「項莊舞劍醉翁之意」

在2023年的十大風險中，「API4:2023 - Unrestricted Resource Consumption」、「API6:2023 - Unrestricted Access to Sensitive Business Flows」與「API7:2023 - Server Side Request Forgery」這三個風險都是全新的項目，這三個項目都有一個共通點就是攻擊者會透過「假裝正常」的方式來存取API，也就是模擬正常的方式來存取API，而實際上攻擊者則是另有目標，例如透過大量存取來耗用資源或金錢，從敏感業務流程中取得不當獲利，或是透過偽造請求方式去進行各種惡意操作來破壞內部伺服器。

而就API本身來說，除了本身所要提供的功能，主要控管機制則為授權與身分驗證，對於上述這些「假裝正常式」攻擊，其實比較難有效偵測與控管 (例如 :API本身通常不會知道現在有人大量在存取它)。所以除了API之外，還需要搭配其他的配套性控管機制，例如針對API用戶端進行檢核與驗證，確保是合法的用戶端方可存取API資源，或是去偵測是否有疑似「非人為」的系統存取與操作等，藉此來提供更完整的安全防護。

3.使用外部API也要注意！

「API10:2023 - Unsafe Consumption of APIs」風險也是在2023年版本首次出現的項目，這其實也反應了運用API已經是系統開發的普遍性做法，所以除了本身自行開發的API，可能也會使用到第三方夥伴的API，這種方式類似使用第三方的軟體元件或技術套件來進行開發。所以在評估使用第三方夥伴的API服務時，也需一併評估其API服務的資安風險，後續也應針對這些外部的API進行定期檢核，檢核重點除了API本身的安全風險，也應針對存取API所取得資料進行必要的檢核，因為這些資料往往是後續流程或其他系統的輸入資料，所以確認資料是安全可信賴之後再去使用它。

4.管理！管理！管理！

很感謝你有耐心看到這裡！如果你看完這10個風險的防護措施，可以發現其實許多的措施都是建立在API必須被明確管理的基礎上，也就是說你的API應該被系統化列管，可以透過API盤點程序，整理已知的API，找出不常用的影子API，並透過APIM管理系統進行登記與管理。這樣才能掌握有哪些API，每個API的授權與身分驗證流程與規則，有哪些API用戶端…等。當然，後端API程式開發與管理也是一個重要的議題，可以透過現在成熟的DevOps (CI/CD)技術與工具來協助。