• 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, 呼叫方式如下

    
    'https://fmipmobile.icloud.com/fmipservice/device/'+apple_id+'/initClient'
    
    Authorization: base64.encodestring (apple_id, password)
    
    {  
    
       ...
    
    "appName": "FindMyiPhone",
    
    "deviceUDID": "0123456789485ef5b1e6c4f356453be033d15622",
    
       ...
    
    }

    這個 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

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Posted by Tony @ 12:24 pm

  • Leave a Reply

    Your email address will not be published.