GSS資安電子報0173期【解析OWASP API Security Top 10 - Part 1】

2020年二月18日(二) PM 10:14

作者:Erez Yalon

翻譯及整理:叡揚資訊 資訊安全事業處

 

由於威脅範圍不斷擴大,加上業界對API的使用與日俱增,因此OWASP API Security Top 10 Project應運而生。這個計畫希望幫助組織、開發人員和資安團隊更了解API相關的風險。在去年9月,OWASP API Security Top 10最終測試版本已在OWASP官網上發佈。

在之前的文章中,提供了API端點、現代應用程式和後端伺服器溝通方式的高層次視角,並說明它們與傳統在瀏覽器執行的應用程式有何不同。另外,也討論為什麼這個計畫對貢獻者和整個產業如此重要。在本文中,我重點介紹一些潛在的攻擊情境來闡明前五大風險,幫助組織和最終使用者了解API實作不足的相關危險。此處將依照OWASP API Security Top 10中的弱點依序進行討論。

 

API12019Broken Object Level Authorization(不安全的物件授權)

      攻擊者可以通過操作客戶端發送的Object ID request,進而利用不安全授權的ObjectAPI。這表示客戶端可以從API存取不該存取的資訊。這種攻擊通常會導致未授權的資訊洩露、資料被竄改或破壞。

      攻擊情境範例:

假設有一個電子商務平台,提供財務和託管服務給各式各樣的線上商店(商家)。這個平台提供一個API來存取每間託管商店的收益圖表,而每間商店都只能存取自己的收益圖表。每次商店在查詢資料時會利用識別碼進行查詢,而攻擊者可以利用這資料識別各家所使用之URL,例如:/shops/{shop name}/revenue_data.json。攻擊者只要使用電子商務平台上託管的其他商店名稱,建立一個簡單的script來修改{shop name}這個ID執行後續請求,就能任意存取其他商店的收益圖表。

 

API22019Broken Authentication(無效身分認證)

      與上述所討論的授權不同,身分認證在API中是另一個相對複雜且混亂的機制。由於在設計上,身分認證端點是向所有人公開的,因此使用者身份認證的端點必須與一般API端點有所區別。除了暴力破解法和猜測token攻擊之外,還應針對密碼填充(Credential Stuffing)攻擊進行額外保護。

      攻擊情境範例:

假設因其他組織資料外洩,攻擊者獲得洩露的使用者帳號/密碼組合列表。如果API端點在處理身份認證時,未針對暴力破解法或密碼填充攻擊法進行保護,例如:CAPTCHA、速度限制、帳號鎖定等,則攻擊者可以運用使用者帳號/密碼組合列表反覆嘗試來取得權限,就可以判定出正確的組合。

 

API32019Excessive Data Exposure(資料暴露不當)

      由於設計原因,API端點經常會暴露機敏資訊,因為它們經常依賴客戶端應用程式執行資料過濾。攻擊者可以透過網路監聽流量對response進行分析,來尋找不應公開的敏感資料。資料應先在後端應用程式上進行過濾,再傳遞給使用者。

      攻擊情境範例:

思考一下,物聯網攝影機監視系統允許管理員添加新進的保全人員為系統使用者,且管理員希望確保新使用者僅能存取特定攝影機。保全人員在工作時可用行動應用程式存取攝影機。行動應用程式向終端發出API請求接收攝影機的相關資訊,並仰賴行動應用程式來過濾保全人員可以存取的攝影機。儘管行動應用程式只顯示保全人員可以存取的攝影機,但實際的API回應包含「所有的」攝影機。攻擊者可以利用網路監聽來略過行動應用程式的過濾與限制,操作API請求顯示所有攝影機。

 

API42019Lack of Resources & Rate Limiting(缺乏資源與速率限制)

      API常設計用來供查詢回傳資料,但往往未對API請求數量進行任何速率或資源的限制,但可能導致消耗大量網路、CPU、記憶體和儲存空間。一般來說使用者輸入和業務邏輯決定了請求所需的資源量。攻擊者利用這些問題造成阻斷服務攻擊(DoS)和相關端點中斷。

      攻擊情境範例:

假設攻擊者想對有大量使用者的特定API進行阻斷服務攻擊。攻擊者可以查詢使用者列表,但是應用程式會限制使用者顯示數量為100個。該程式的正常請求如下所示:/api/users?page=1&size=100。在這種情況下,該請求會和前100個使用者一起返回首頁。如果攻擊者將size這個參數從100更改為200000,會因為目前的參數太大,導致後端資料庫效能出現問題。因此,API就會變得毫無反應,且無法處理來自客戶端或其他客戶端的額外請求。

 

API52019Broken Function Level Authorization(無效功能權限控管)

      儘管與上述的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的方式,就可以輕鬆管理風險或甚至將風險排除。

相關API Security文章:

GSS資安電子報0174期【解析OWASP API Security Top 10 - Part 2】

GSS資安電子報0172期【為什麼API的安全極其重要】

 

了解更多關於Checkmarx

 

作者介紹

      Erez Yalon帶領Checkmarx安全研究小組。身為一名獨立的安全研究人員,他擁有豐富的防禦和攻擊經驗,能提供寶貴的知識和技能。Erez Yalon憑藉過去多種程式語言的開發經驗,負責維護Checkmarx的漏洞檢測技術。


相關文章

資安通報: Python 惡意套件-請儘速檢查與移除

近期專注於資訊安全的 Checkmarx 的供應鏈安全團隊追蹤到惡意攻擊的活動,其作業的手法比典型的資訊竊取操作更進一步,利用開發生態系與開發社群的供應鏈關係,將隱藏惡意行為的 PayLoad 藏身於合法的儲存庫(repository),近幾個月來,這種威脅不斷出現、不斷成長並不斷改變其樣貌,其攻擊的目標從特定應用系統、瀏覽器至使用者的資料,而這些藏有惡意之 Package 至今已累積 75,000 下載次數。
2023/12/08

新聞中心 - 叡揚資訊與 Checkmarx 助攻 關貿網路打通 SSDLC 安...

叡揚資安團隊鼎力支持,為關貿打造最佳檢測環境。受惠於叡揚團隊的專業服務能力,使 Checkmarx 導人過程極為平順。叡揚不僅依據關貿網路當下與未來檢測量能,針對主機容量進行最適規劃,也悉心安排教育訓練、系統安裝及使用諮詢等工作,讓使用者無痛接軌新環境。隨著系統上線至今,只要 OWASP 等規範出現更新,叡揚都會立即提供 Patch 檔,確使品保中心恆常套用最新安全程式碼撰寫規則。
2023/03/01

資安通報: Apache Commons Text 1.5~1.9版 發布新的高...

本次受 CVE 影響的軟體是 Apache Commons Text,這是一個由 Apache 提供的開源軟體,此套件是一個針對字串的相關運用的演算法(例如:字串替換、查找、匹配等等演算法)。目前所發現的漏洞 CVE-2022-42889 存在於 1.5 至 1.9 版本中,當不受信任的資料被處理或是在使用 Variable Interpolation 功能時,可能導致攻擊者能進行任意代碼執行(RCE, Remote Code Execution)。
2022/11/02

軟體供應鏈必學資安課題,如何拉近開發與資安的距離?

今年 IT 圈最熱門的話題之一,便是資本額達百億元以上的上市櫃公司須在年底前完成設立資安長及資安專責單位。以往資深資安人才本就難尋,如今更是炙手可熱。日前台灣資安主管聯盟的成立大會上,會長金慶柏曾指出,目前全台資安人才缺口超過 4 萬人!既然對外招募不容易,那麼從企業內部培養資安人才、提升人員資安意識便是另一途徑。
2022/06/17