什麼是 API 邏輯漏洞？
API 邏輯漏洞是近年企業最容易忽略的資安破口。攻擊者不需要植入惡意程式，只要照著「看似正常」的流程操作，就能取走不屬於自己的資料與金錢。本文以豐田汽車與全國繳費網兩個真實案例，說明 API 邏輯漏洞如何發生、為什麼現有網路設備擋不住，以及企業可採取的防護實務。
本文重點摘要
- API 邏輯漏洞指的是 Request 與 Response 之間沒有做關聯性確認。
- 豐田汽車 GSPIMS 案例：後端只驗證電子郵件，未驗證密碼與電子郵件的關聯性。
- 全國繳費網案例：「繳納貸款」項目未檢查身分證字號與銀行帳號的關聯性。
- WAF 與 API Gateway 不足以抵禦 API 邏輯漏洞的濫用，需要基於 ML/AI 的資安產品。
- 防護四要素：API 資產盤點、API Auth 辨識、阻擋 Injection、關聯性學習與持續監控。
什麼是 API 邏輯漏洞？
所謂的 API 邏輯漏洞，指的是 Request 與 Response 之間沒有做關聯性確認。也就是說，後端系統雖然檢查了「有沒有填」，卻沒有檢查「填的內容彼此是否相符」。以下分享兩個真實案例，豐田汽車與全國繳費網。
案例一：豐田汽車 GSPIMS 的後門登入機制
研究人員在探索 Toyota 的子域名時，找到多個安全漏洞。發現 Toyota 的 Global Supplier Preparation Information Management System（GSPIMS）存在一個後門登入機制，只需知道用戶的電子郵件即可登入，通過修改 JavaScript 程式碼，繞過了登入頁面，並生成有效的 JSON Web Token（JWT）來獲取系統存取權限。
會出現這樣的漏洞在於後端系統只驗證是否輸入電子郵件以及是否為豐田企業的電子郵件，而忽略了是否輸入密碼以及密碼是否與電子郵件有關聯性。
案例二：全國繳費網的「繳納貸款」項目
在「全國繳費網」的「繳納貸款」項目裡，發現只需掌握他人的銀行帳號，接著填入自己的身分證字號與銀行帳號，就能將他人的存款轉至自己的帳戶，且被害人不會收到銀行通知。
在繳納其他項目時，填上非本人的銀行帳號，都顯示「交易失敗」、「身份證字號或營利事業統一編號錯誤」的訊息，但明顯「繳納貸款」沒有執行該項檢查。同一套系統中，只要有一個項目漏掉關聯性驗證，就足以構成完整的資安事件。
現有的 WAF 與 API Gateway 無法防禦 API 邏輯漏洞嗎？
透過上述的真實案例，我們可以知道現有的 WAF（Web 應用程式防火牆）與 API Gateway 不足以抵禦 API 邏輯漏洞的濫用。API 安全需要一個基於 ML/AI 的資安產品，來保護企業的 API 資產。
WAF 主要的角色是阻擋惡意 Injection，透過規則來阻擋惡意特徵碼。API Gateway 則是扮演驗證授權的角色，需要攜帶有效的 API Auth 才能成功將 Request 送至後端 Server。
當駭客的 Request 沒有違反 WAF 與 API Gateway 的規則就可以輕易地抵達後端 Server，而後端 Server 回傳了什麼資料就不被 WAF 與 API Gateway 保護。這正是邏輯漏洞的關鍵：攻擊行為在規則上完全「合法」。
ML/AI 如何偵測 API 邏輯漏洞被濫用？
一套基於 ML/AI 的資安產品可以有效地偵測出漏洞被濫用的情形，做法是先學習正常的呼叫行為，再找出與多數流量不一致的異常。
延續豐田汽車的案例，當 ML/AI 發現有少部分的流量在登入豐田汽車的後端平台時，沒有填寫密碼且 Response Code 為 200，這樣的情形與大多數流量並不相符，進而發出告警。
若是像全國繳費網的案例，假設 ML/AI 學習到每個來源 IP 呼叫「繳納貸款」時只輸入一種「轉帳帳號」。這時發現有 IP 呼叫時多次變更「轉帳帳號」，嘗試將他人的存款轉至自己的帳戶，ML/AI 發現這與過往的行為不一致，進而發出告警。
防止可疑 API 流量的最佳實踐有哪些？
企業可從資產盤點、授權辨識、Injection 防護、關聯性學習與持續監控五個面向著手。搭配 Akamai API Security 提供全面的 API 可視性和保護：
● 定期盤點 API 資產 : Akamai API Security 能夠找出企業內部的所有 API，特別是對外開放、金流相關、客戶個資相關的 B2B API，提供一份清晰的 API 資產清單。
● API Auth 辨識 : Akamai API Security 能夠辨識出每支 API 的認證授權，提醒用戶需要授權機制的 API，給予授權機制可以有效的預防絕大多數的 API 安全問題。
● 阻擋 Injection : 除了 WAF 與後端 Server 要把關之外，Akamai API Security 也會檢查每個欄位是否有填寫惡意的 Injection。
● 關聯性學習 : Akamai API Security 透過使用者呼叫行為，關注有哪些 Request 的參數影響了 Response，當 Request 與 Response 之間的關聯性發生錯誤時，會告知使用者。
● 持續的監控和偵測 : Akamai API Security 落實強大的監控和偵測機制，企業可以主動識別和回應安全威脅，最大限度地降低資料外洩、財務損失和聲譽損害的風險。
常見問題 FAQ
Q：API 邏輯漏洞和 OWASP API Security Top 10 有什麼關聯？
A：API 邏輯漏洞多半對應到 OWASP API Security Top 10 中的授權類風險，例如物件層級授權失效（BOLA）與身分認證失效。這類風險的共同特徵是「請求本身格式正確」，因此難以用特徵碼規則辨識，必須從行為與參數關聯性的角度檢查。
Q：企業應該多久盤點一次 API 資產？
A：建議至少每季盤點一次，並在每次版本更新或新服務上線時同步更新清單。因為開發團隊改版後常留下未下架的舊版 API，這些「被遺忘的 API」不在維運清單上，卻仍可被外部呼叫，是攻擊者最常鎖定的入口。
Q：導入 API 安全方案需要修改既有的應用程式或 API 程式碼嗎？
A：通常不需要。這類方案多以流量或日誌的側錄分析為主，不介入應用程式邏輯，因此不需要改寫既有 API、也不會影響線上服務的回應時間。若企業已使用 Akamai 相關服務，可直接由既有服務收集 API 日誌進行分析。
Q：只有對外開放的 API 需要保護嗎？
A：不是，內部與 B2B 介接的 API 同樣需要保護。豐田汽車的案例正是發生在供應商管理系統上，屬於企業內部與合作夥伴使用的平台。內部 API 常因為「假設呼叫者可信任」而省略驗證，反而讓邏輯漏洞更容易存在。
Q：做過滲透測試或原始碼掃描，還需要 API 行為監控嗎？
A：需要，兩者的檢查時機不同。滲透測試與原始碼掃描屬於上線前的點狀檢測，涵蓋範圍取決於測試當下已知的 API 清單；而邏輯漏洞往往是在營運過程中被反覆濫用，需要持續監控實際流量才能在事件擴大前發出告警。
下一步：盤點你的 API 資產，找出看不見的破口
API 邏輯漏洞的難處在於，它不會觸發任何一條既有規則，企業往往是在資料外洩或金流異常之後才發現問題。第一步，是先確認你的企業究竟有多少支對外開放、金流相關與個資相關的 API。
想了解 Akamai API Security 如何適用於你的環境？歡迎聯繫叡揚資訊顧問團隊，我們提供免費的初步 API 安全需求評估，協助你釐清目前的 API 曝險範圍與優先處理順序。
或者，你也可以先瀏覽叡揚資訊的資安解決方案頁面，了解完整的防護架構。