Open API 的安全威脅與防護個案討論
這篇文章主要用一個實際個案說明 Open API 可能造成的風險
藉由這個例子討論Open API 的威脅與安全防護建議.
什麼是 Open API?
Web 服務的開放整合, 服務之間以 HTTP/HTTPS為基礎相互溝通
透過開放的 API 讓整個Web 服務生態創造許多新的服務
我們最熟悉的一種 Open API 就是按”讚’
透過 API 的方式, 該程式碼輕易的在每個網站上嵌入
讓來訪的使用者可以按讚, 把讚透過 API 傳送回社交網站服務
開放與服務的便捷, 當然也帶來安全的風險
讓我們來看一個著名的個案
iCloud FindMyPhone個案討論
iCloud提供 Find My Phone 的 API, 呼叫方式如下
[pastacode lang=”markup” manual=”%0A’https%3A%2F%2Ffmipmobile.icloud.com%2Ffmipservice%2Fdevice%2F’%2Bapple_id%2B’%2FinitClient’%0A%0AAuthorization%3A%C2%A0base64.encodestring%20(apple_id%2C%20password)%0A%0A%7B%20%C2%A0%0A%0A%C2%A0%20%C2%A0…%0A%0A%22appName%22%3A%20%22FindMyiPhone%22%2C%0A%0A%22deviceUDID%22%3A%20%220123456789485ef5b1e6c4f356453be033d15622%22%2C%0A%0A%C2%A0%20%C2%A0…%0A%0A%7D%0A%0A” message=”” highlight=”” provider=”manual”/]
這個 API 只要提供 Apple ID 與密碼就可以存取
因此, 這個個案中, 駭客就透過密碼字典的方式,
將大量雲端儲存的隱私數據竊取
那麼針對這個個案中, 比較好的 API 安全防護設計為何呢 ?
這個個案主要缺少幾個安全設計
- 存取速率限制. 讓駭客可以用字典密碼的方式不斷的嘗試
- API 的呼叫沒有進行認證與授權, 筆者指的不是個案中所提供使用者密碼的認證, 而是API 的來源呼叫, 也就是每一個API呼叫應該帶有 Secret Key簽章的機制, 這樣到後端服務才能夠針對該 API 所對應的權限加以限制
- 明文密碼傳送, 讓駭客可以準備常見的密碼字典傳送來猜測
由於 Web API 多半是程式對後端服務的呼叫所以衍生的安全問題與安全設計會與
傳統人與Web服務互動的安全威脅有所不同, 衍生的相關安全問題常見的說明如下
- DoS Attacks: API的開放也容易導致有心人士對特定API 進行 DOS 攻擊
- Cross-Site Scripting (XSS) , SQL Injections :對於open API這依然是主要的攻擊方式
- HTTP Parameter Pollution (HPP) : 由於每一個API都有相對需要的參數輸入, 因此這個攻擊方式變成是 API一個主要來源
- Malicious Code Injection: 主要透過後端服務的特性SQL, LDAP, XPATH, or XQuery等, 惡意輸入
- Business Logic Attacks (BLA): 透過商業邏輯上的檢查漏洞進行攻擊, API直接的呼叫,跳過許多商業的邏輯,例如跳過購買與付款, 直接送貨
- Session Attack: API 的呼叫由於缺少 session 的控制, 造成駭客取得 token 或是 SessionID之後就可以任意存取後端資源
- 缺少速率限制: 這是一個常見的安全防護缺失, 例如上述個案中, 由於缺少速率訪問限制, 造成該API短時間內被大量訪問猜測使用者密碼
- API敏感資訊: API Secret Key, Token 等, 由於用戶端或是開發商APP位妥善的安全儲存, 造成駭客利用這些資訊
根據 OWASP Web Hacking Incident Database, API 最常受到的攻擊如下
https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project
提到這些威脅, 那麼安全防護的建議有那些呢?
API身任認證 — API Secret Key
API的呼叫如何辨識身分呢?
常見的方式就是在每一個API呼叫帶上 API Key
如此一來, 當特定API呼叫有異常行為或是需要進一步終止該API使用時候
就可以透過 API Key 來辨別
服務間授權與認證
常見的方式有下列三種
- Oauth 2.0: 服務間的代理授權 (並非身分認證)
- SAML 2.0 : Identity Provider 間的相互身分認證
- Open ID Connect 互聯網服務間的身分認證
Oauth2.0場景: 兩服務間授權存取
SAML 2.0 VS OpenID Connect
SAML 2.0: 多半應用在企業內部 LDAP與外部服務的身分認證
OpenID connect: 基於 Oauth2.0 的基礎上, 對於互聯網服務間的相互身分認證, 未來將逐漸取代 SAML 2.0
OWASP Top 10 威脅防護
傳輸訊息加密
API安全日誌審計與分析
API Gateway安全防護
API安全設計思維
