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

作者：Erez Yalon

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

      由於API的廣泛使用，攻擊者意識到API會是新的攻擊領域，故OWASP API Security Top 10 安全風險計畫應運而生。此項計畫希望能夠幫助組織、開發人員和AppSec團隊能夠更加了解API的相關風險。2019年12月OWASP API Security Top 10的第一版已完成並且發佈在OWASP。

      在本文章的第一章節裡，從更高的角度去觀察API之間的端點、現代應用程式和後端伺服器之間互動的關係，並說明它們與傳統基於瀏覽器的網頁應用程式之間的差異。另外說明了OWASP API Security Top 10這項計畫對於貢獻者甚至整個產業的重要性。在第二章中，我重點說明介紹前五個風險，並強調了在這些風險範圍內可能出現的攻擊場景。本章我將闡述最後五個風險，來幫助組織了解使用有缺陷的API的危險性。以下依OWASP API Security Top 10安全風險中的順序進行以下討論。

API6：2019－Mass Assignment(批量配置不當)：

      現代的網頁程式框架支援自動將使用者輸入內容與Function Object的內部變數綁定在一起的功能，一般來說使用者應該能夠更新他的名稱、聯絡資料等（例如個人資料）但他們無法更改權限，如調整帳號餘額或操作類似於管理者權限的功能。但如果API端點自動將用戶端輸入的內容轉換為內部物件屬性，卻不考慮這些屬性的敏感度和可暴露度等級，則該API端點就很容易遭到惡意的攻擊，這將使得攻擊者可以非法更新他們不應該存取的內容。

      攻擊情境範例：

為了進一步說明這一點，想像一個共乘應用程式，其中提供了可以讓使用者編輯個人基本資料的功能。舉例來說，他們可以調整使用者名稱、年齡等基本資料。在這種情況下，API的請求如下所示：

PUT /api/v1/users/me並附上以下合法資料{“user_name”:”john”,”age”:24}
但是，攻擊者透過測試判定請求GET /api/v1/users/me中包括一個額外的credit_balance屬性（欄位），如下所示。
{“user_name”:”john”,”age”:24,”credit_balance”:10}.
攻擊者希望增加自己的信用餘額，因此使用以下的payload重複了第一個請求：
{“user_name”:”john”,”age”:24,”credit_balance”:99999}
由於API易受大規模的批量攻擊，因此攻擊者可以輕鬆調整自己的credit_balance。例如：將10更改為99999，如上所示。

API7：2019－Security Misconfiguration(不安全的組態設定)：

      攻擊者通常會試圖找到未修補的漏洞、進入點或未受保護的文件和目錄，以獲得未經授權的存取權限，或對要攻擊的系統進行了解。不安全的組態設定不僅會暴露敏感的使用者資訊，還有可能暴露可能導致伺服器完全受損的系統詳細資訊。    

      攻擊情境範例：

舉例來說，攻擊者使用像Shodan這類型的搜尋引擎，搜索直接與網際網路相連的電腦和設備的資訊。例如：攻擊者發現一台運行中的資料庫管理系統的伺服器，正在監聽預設的TCP端口。資料庫管理系統使用的是預設配置，在默認情況下會解除身份認證，因此攻擊者就可以存取數百萬則具有PII與個人喜好。

API8：2019－Injection(注入攻擊)：

      注入漏洞導致系統潛在地處理攻擊者所放入的惡意資料。簡而言之，攻擊者將程式碼注入易受攻擊的軟體中，並更改了執行軟體的方式。注入攻擊可能會導致一定程度的災難性影響，因為注入攻擊通常會導致資料遭竊、丟失、損壞或阻斷服務等。

      攻擊情境範例：

假設攻擊者開始檢視網頁瀏覽器的網路流量，並識別出以下API為幫助使用者恢復密碼的請求。攻擊者確定負責啟動恢復密碼過程的API請求，如下所示：

POST/api/accounts/recovery {“username”: “john@somehost.com”}

然後，攻擊者使用不同的payload重複請求：

POST /api/account/recovery {“email”: “john@somehost.com’;WAITFOR DELAY ‘0:0:5’–“}

通過添加;WAITFOR DELAY ‘0:0:5’–”，利用等待時間攻擊者發現，來自API的響應確實額外花費了大約5秒的時間，此有助於確認API容易受到SQL注入攻擊。利用注入漏洞，攻擊者就能夠獲得未經授權的系統存取權限。

API9：2019－Improper Assets Management(版本控管不當)：

      舊版本的API通常尚未修復與更新，因此可能淪為破壞系統的一個簡單方法，透過攻擊尚未修復與更新的舊API，而無需與最新的具安全性的新版API作鬥爭。攻擊者可能會存取敏感數據，甚至通過連接到同一資料庫尚未修復的舊版API來接管整個伺服器。

      攻擊情境範例：

例如，若一個組織在重新設計其應用程式時，忽略了舊版API（api.someservice.com/v1），並使其未受保護，並可以存取使用者資料庫。在針對最新發布的應用程式時，攻擊者找到了API地址（api.someservice.com/v2）。將URL中的v2替換為v1，使攻擊者可以存取舊的未受保護的API，從而導致暴露了數百萬使用者的個人身份資訊（PII）。

API10:2019－Insufficient Logging & Monitoring(紀錄與監控不足)

如果記錄日誌和監視有所欠缺或是不足，幾乎無法追蹤API的可疑活動並及時做出反應。由於無法了解正在進行的惡意活動，因此攻擊者有足夠的時間潛在地破壞系統並竊取資料。

      攻擊情境範例：

想像一下，一個影片共享平台遭到「大規模」帳號登錄攻擊。儘管記錄了失敗的登錄，但在攻擊持續時間內未觸發任何警報，所以攻擊得以持續進行而未引起任何注意。在使用者資料外洩投訴的反應，事件發生之後，對API日誌進行了分析並檢測到攻擊，但為時已晚。公司必須發布公告，要求使用者重設密碼，並將事件報告予監管機構。

上述的五種風險情況，可以很輕易想像出許多類似的攻擊情境。以上的範例只是各種API攻擊的冰山一角。希望您能看出上述風險主要是由錯誤或疏忽所導致，特別是現今組織使用API的方式。

相關API Security文章：

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

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

了解更多關於Checkmarx

作者介紹

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