作者: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安全風險中的順序進行以下討論。
現代的網頁程式框架支援自動將使用者輸入內容與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,如上所示。
攻擊者通常會試圖找到未修補的漏洞、進入點或未受保護的文件和目錄,以獲得未經授權的存取權限,或對要攻擊的系統進行了解。不安全的組態設定不僅會暴露敏感的使用者資訊,還有可能暴露可能導致伺服器完全受損的系統詳細資訊。
攻擊情境範例:
舉例來說,攻擊者使用像Shodan這類型的搜尋引擎,搜索直接與網際網路相連的電腦和設備的資訊。例如:攻擊者發現一台運行中的資料庫管理系統的伺服器,正在監聽預設的TCP端口。資料庫管理系統使用的是預設配置,在默認情況下會解除身份認證,因此攻擊者就可以存取數百萬則具有PII與個人喜好。
注入漏洞導致系統潛在地處理攻擊者所放入的惡意資料。簡而言之,攻擊者將程式碼注入易受攻擊的軟體中,並更改了執行軟體的方式。注入攻擊可能會導致一定程度的災難性影響,因為注入攻擊通常會導致資料遭竊、丟失、損壞或阻斷服務等。
攻擊情境範例:
假設攻擊者開始檢視網頁瀏覽器的網路流量,並識別出以下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注入攻擊。利用注入漏洞,攻擊者就能夠獲得未經授權的系統存取權限。
舊版本的API通常尚未修復與更新,因此可能淪為破壞系統的一個簡單方法,透過攻擊尚未修復與更新的舊API,而無需與最新的具安全性的新版API作鬥爭。攻擊者可能會存取敏感數據,甚至通過連接到同一資料庫尚未修復的舊版API來接管整個伺服器。
攻擊情境範例:
例如,若一個組織在重新設計其應用程式時,忽略了舊版API(api.someservice.com/v1),並使其未受保護,並可以存取使用者資料庫。在針對最新發布的應用程式時,攻擊者找到了API地址(api.someservice.com/v2)。將URL中的v2替換為v1,使攻擊者可以存取舊的未受保護的API,從而導致暴露了數百萬使用者的個人身份資訊(PII)。
如果記錄日誌和監視有所欠缺或是不足,幾乎無法追蹤API的可疑活動並及時做出反應。由於無法了解正在進行的惡意活動,因此攻擊者有足夠的時間潛在地破壞系統並竊取資料。
攻擊情境範例:
想像一下,一個影片共享平台遭到「大規模」帳號登錄攻擊。儘管記錄了失敗的登錄,但在攻擊持續時間內未觸發任何警報,所以攻擊得以持續進行而未引起任何注意。在使用者資料外洩投訴的反應,事件發生之後,對API日誌進行了分析並檢測到攻擊,但為時已晚。公司必須發布公告,要求使用者重設密碼,並將事件報告予監管機構。
上述的五種風險情況,可以很輕易想像出許多類似的攻擊情境。以上的範例只是各種API攻擊的冰山一角。希望您能看出上述風險主要是由錯誤或疏忽所導致,特別是現今組織使用API的方式。
GSS資安電子報0173期【解析OWASP API Security Top 10 - Part 1】
Erez Yalon帶領Checkmarx安全研究小組。身為一名獨立的安全研究人員,他擁有豐富的防禦和攻擊經驗,能提供寶貴的知識和技能。Erez Yalon憑藉過去多種程式語言的開發經驗,負責維護Checkmarx的漏洞檢測技術。