作者:Erez Yalon
翻譯及整理:叡揚資訊 資訊安全事業處
由於威脅範圍不斷擴大,加上業界對API的使用與日俱增,因此OWASP API Security Top 10 Project應運而生。這個計畫希望幫助組織、開發人員和資安團隊更了解API相關的風險。在去年9月,OWASP API Security Top 10最終測試版本已在OWASP官網上發佈。
在之前的文章中,提供了API端點、現代應用程式和後端伺服器溝通方式的高層次視角,並說明它們與傳統在瀏覽器執行的應用程式有何不同。另外,也討論為什麼這個計畫對貢獻者和整個產業如此重要。在本文中,我重點介紹一些潛在的攻擊情境來闡明前五大風險,幫助組織和最終使用者了解API實作不足的相關危險。此處將依照OWASP API Security Top 10中的弱點依序進行討論。
攻擊者可以通過操作客戶端發送的Object ID request,進而利用不安全授權的ObjectAPI。這表示客戶端可以從API存取不該存取的資訊。這種攻擊通常會導致未授權的資訊洩露、資料被竄改或破壞。
攻擊情境範例:
假設有一個電子商務平台,提供財務和託管服務給各式各樣的線上商店(商家)。這個平台提供一個API來存取每間託管商店的收益圖表,而每間商店都只能存取自己的收益圖表。每次商店在查詢資料時會利用識別碼進行查詢,而攻擊者可以利用這資料識別各家所使用之URL,例如:/shops/{shop name}/revenue_data.json。攻擊者只要使用電子商務平台上託管的其他商店名稱,建立一個簡單的script來修改{shop name}這個ID執行後續請求,就能任意存取其他商店的收益圖表。
與上述所討論的授權不同,身分認證在API中是另一個相對複雜且混亂的機制。由於在設計上,身分認證端點是向所有人公開的,因此使用者身份認證的端點必須與一般API端點有所區別。除了暴力破解法和猜測token攻擊之外,還應針對密碼填充(Credential Stuffing)攻擊進行額外保護。
攻擊情境範例:
假設因其他組織資料外洩,攻擊者獲得洩露的使用者帳號/密碼組合列表。如果API端點在處理身份認證時,未針對暴力破解法或密碼填充攻擊法進行保護,例如:CAPTCHA、速度限制、帳號鎖定等,則攻擊者可以運用使用者帳號/密碼組合列表反覆嘗試來取得權限,就可以判定出正確的組合。
由於設計原因,API端點經常會暴露機敏資訊,因為它們經常依賴客戶端應用程式執行資料過濾。攻擊者可以透過網路監聽流量對response進行分析,來尋找不應公開的敏感資料。資料應先在後端應用程式上進行過濾,再傳遞給使用者。
攻擊情境範例:
思考一下,物聯網攝影機監視系統允許管理員添加新進的保全人員為系統使用者,且管理員希望確保新使用者僅能存取特定攝影機。保全人員在工作時可用行動應用程式存取攝影機。行動應用程式向終端發出API請求接收攝影機的相關資訊,並仰賴行動應用程式來過濾保全人員可以存取的攝影機。儘管行動應用程式只顯示保全人員可以存取的攝影機,但實際的API回應包含「所有的」攝影機。攻擊者可以利用網路監聽來略過行動應用程式的過濾與限制,操作API請求顯示所有攝影機。
API常設計用來供查詢回傳資料,但往往未對API請求數量進行任何速率或資源的限制,但可能導致消耗大量網路、CPU、記憶體和儲存空間。一般來說使用者輸入和業務邏輯決定了請求所需的資源量。攻擊者利用這些問題造成阻斷服務攻擊(DoS)和相關端點中斷。
攻擊情境範例:
假設攻擊者想對有大量使用者的特定API進行阻斷服務攻擊。攻擊者可以查詢使用者列表,但是應用程式會限制使用者顯示數量為100個。該程式的正常請求如下所示:/api/users?page=1&size=100。在這種情況下,該請求會和前100個使用者一起返回首頁。如果攻擊者將size這個參數從100更改為200000,會因為目前的參數太大,導致後端資料庫效能出現問題。因此,API就會變得毫無反應,且無法處理來自客戶端或其他客戶端的額外請求。
儘管與上述的API1不同,在這邊攻擊者需要將API請求發送到他們不應該存取,但暴露給匿名使用者或沒有權限的一般使用者的端點。攻擊者很容易能發現此類型的漏洞,且可以存取未經授權的功能。例如:管理功能是此類型攻擊的主要目標。
攻擊情境範例:
為了進一步說明,假設某個應用程式僅允許受邀使用者加入。在進行註冊時,行動應用程式觸發了對GET/api/invites/{invite_guid}的API請求。GET是一個標準HTTP method,用於向特定資源請求資訊。在這種情況下,GET的response涵蓋了invite相關的詳細資訊,包括使用者的角色和電子郵件地址。
現在,假設攻擊者複製請求,並將GET更改為POST來操縱HTTP方法。POST是一種用於發送資訊以建立或更新資源的HTTP方法。URL如下:POST /api/invites/new/{“email”:”hugo@malicious.com”,”role”:”admin”}。 在這種情況下,攻擊者可以輕鬆利用此漏洞,發送電子郵件邀請自己建立管理員帳號。
上述的五種風險情況,可以很輕易想像出許多類似的攻擊情境。以上的範例只是各種API攻擊的冰山一角。希望您能看出上述風險主要是由錯誤或疏忽所導致。我認為,當組織使用安全的程式撰寫方式後尤其是使用API的方式,就可以輕鬆管理風險或甚至將風險排除。
GSS資安電子報0174期【解析OWASP API Security Top 10 - Part 2】
Erez Yalon帶領Checkmarx安全研究小組。身為一名獨立的安全研究人員,他擁有豐富的防禦和攻擊經驗,能提供寶貴的知識和技能。Erez Yalon憑藉過去多種程式語言的開發經驗,負責維護Checkmarx的漏洞檢測技術。