Open API 的安全威脅與防護個案討論

Open API 的安全威脅與防護個案討論

Image result for apple find my phone hack

這篇文章主要用一個實際個案說明 Open API 可能造成的風險

藉由這個例子討論Open API 的威脅與安全防護建議.

什麼是 Open API?

Image result for rest api

Web  服務的開放整合, 服務之間以 HTTP/HTTPS為基礎相互溝通

透過開放的 API 讓整個Web 服務生態創造許多新的服務

我們最熟悉的一種 Open API 就是按”讚’

透過 API 的方式, 該程式碼輕易的在每個網站上嵌入

讓來訪的使用者可以按讚, 把讚透過 API 傳送回社交網站服務

Image result for 讚

開放與服務的便捷, 當然也帶來安全的風險

讓我們來看一個著名的個案

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

 

most-api-security-risk-in-2014

提到這些威脅, 那麼安全防護的建議有那些呢?

API身任認證 — API Secret Key

API的呼叫如何辨識身分呢?

常見的方式就是在每一個API呼叫帶上 API Key

如此一來, 當特定API呼叫有異常行為或是需要進一步終止該API使用時候

就可以透過 API Key 來辨別

 

服務間授權與認證

常見的方式有下列三種

  • Oauth 2.0:  服務間的代理授權 (並非身分認證)
  • SAML 2.0 : Identity Provider 間的相互身分認證
  • Open ID Connect 互聯網服務間的身分認證

Image result for OpenID connect 場景

Oauth2.0場景: 兩服務間授權存取

Image result for oauth 微信

SAML 2.0 VS OpenID Connect

SAML 2.0: 多半應用在企業內部 LDAP與外部服務的身分認證

OpenID connect: 基於 Oauth2.0 的基礎上, 對於互聯網服務間的相互身分認證, 未來將逐漸取代 SAML 2.0

SAML OpenID Connect Comparison

 

 

OWASP Top 10 威脅防護

security-api-exp


security-for-api-consumer

傳輸訊息加密

 

API安全日誌審計與分析

 

API Gateway安全防護

Image result for API Security

API安全設計思維

Image result for open aPI security definition

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *