[技術解析] 003 API 滲透測試：API 黑箱測試教學與實作指南

本篇文章將以「完全不具資訊背景的新手」為出發點，介紹什麼是 API 以及如何從「黑箱測試」(Black-Box Testing) 的角度進行初步檢測。文中會用最簡單易懂的方式，帶領你一步步了解 API 滲透測試(API 黑箱測試)，以及測試 API 時常用的流程與工具。

一、什麼是 API？

• API (Application Programming Interface)：簡單來說就是「應用程式之間交換資料的管道」。
• 舉例：假設你在手機上使用地圖 App 查詢天氣，它的背後會去找「天氣服務的 API」拿到天氣資訊，再把結果顯示給你。你不用知道天氣服務的程式細節，只要能透過 API 拿到需要的資料即可。

為什麼要測試 API？

• 安全性：API 若沒有做好防護，駭客可能透過它拿到機密資訊。
• 正確性：確保 API 回傳的資料正確並符合預期。
• 穩定度：避免因為出錯導致系統或服務中斷。

二、什麼是「黑箱測試」？

• 黑箱測試 (Black-Box Testing)：測試者不需要知道系統的內部程式碼或技術細節，僅透過「使用者能看到或能接觸到的介面 (API Endpoint)」進行測試。
• 核心精神：
  1. 假裝自己只是一個「使用 API 的人」，不知道背後的程式長什麼樣子。
  2. 用各種方法（正確的/錯誤的參數、不同的 API 路徑等）來嘗試呼叫 API，觀察它的回應是否符合預期。

三、進行 API 黑箱測試前的準備

1. 確定測試範圍
   • 先了解要測試哪些 API。若 API 有官方文件 (如 Swagger/OpenAPI) 或者是簡單的使用者說明，就先看一下它的 Endpoint (網址路徑)、參數與回傳格式。
   • 若沒有任何文件，可以先透過「瀏覽器 + 開發者工具」或「攔截 Proxy (例如 Burp Suite、OWASP ZAP)」來找出可疑的 API 路徑。
2. 安裝必要工具 (選擇其一或多個搭配)
   • 瀏覽器開發者工具 (Chrome、Firefox)：可以在「Network」面板觀察網頁與伺服器之間的溝通，找到可疑的 API 請求。
   • Postman：最常使用的 API 測試工具，透過圖形介面設定請求(HTTP method、參數、Body等)。
   • Burp Suite / OWASP ZAP：專業安全測試人員常用，可攔截、修改請求與回應，也能自動掃描。
   • 指令列工具 (cURL、HTTPie)：若習慣終端機，可以使用指令行來發送 API 請求。
3. 測試帳號或測試環境
   • 若有需要登入的 API 功能，預先準備好測試用帳號。
   • 在可行的情況下，儘量在「測試環境」上測，不要直接在正式線上環境測試，以免不當操作造成系統或資料異常。

四、黑箱測試的基本流程

以下介紹一個簡單易懂的「五步驟」流程，幫助你在不懂程式細節的情況下，仍然能對 API 進行初步的測試與檢驗。

步驟 1：收集或發現 API Endpoint

1. 閱讀已公開的文件：
   • 尋找是否有 /swagger.json、/openapi.json 或 /api-docs 之類的文件。
   • 若文件中標示了 /api/v1/user 這樣的路徑，就代表該 Endpoint 用來處理與「user」(使用者) 相關的操作。
2. 瀏覽器 F12 (開發者工具)：
   • 進入網站後，在「Network」面板觀察流量，找出含有 api 或 graphql 的 URL。
   • 這些 URL 很可能就是 API 的 Endpoint。
3. 使用攔截工具 (Burp / ZAP) 或爬蟲功能：
   • 自動幫你掃描網站並列出所有呼叫的路徑，也常能抓到隱藏的 API Endpoint。

步驟 2：嘗試發送各種請求

1. HTTP 方法
   • 常見方法：GET（讀取資料）、POST（新增資料）、PUT（更新資料）、DELETE（刪除資料）。
   • 測試時可嘗試把原本應該是 GET 的請求換成 POST 看看能否導致錯誤、或得到非預期的資料。
2. 參數與查詢字串
   • 例如 GET https://example.com/api/v1/users?id=123
   • 可以嘗試：
     • 將 id=123 改成不存在的 ID (id=99999)
     • 使用不同型態的參數（文字、負數、特殊符號）
     • 故意輸入錯誤的格式（例如把數字欄位填入文字）
3. Header 與認證資訊
   • 一些 API 需要在 Header 裡帶 Authorization: Bearer <token>。
   • 可以測試不帶 Token、帶錯 Token、或帶過期 Token，觀察 API 的回應是否正確處理授權失敗的情況。

步驟 3：觀察 API 回應 (Response)

1. 狀態碼 (Status Code)
   • 200 OK：請求成功
   • 400 Bad Request：請求格式錯誤
   • 401 Unauthorized：無權限(需要登入)
   • 404 Not Found：找不到資源
   • 500 Internal Server Error：伺服器端程式出錯
   • 檢查是否有出現「不該出現的」或「描述不明確的」狀態碼，這些都可能是問題。
2. 回傳內容 (Response Body)
   • 確認是否符合預期格式（JSON、XML …），或是否出現機密資訊(如密碼、金鑰、內部錯誤訊息)。
3. 回應時間
   • 觀察速度過慢或錯誤次數過多，可能暗示伺服器效能或穩定度不足。

步驟 4：記錄與比較結果

• 建立測試表或使用測試工具的報告功能：
  • 每測一個 Endpoint，就把「測試條件、預期結果、實際結果」記下來。
  • 若有異常或可疑之處，拍下截圖或紀錄 HTTP 請求、回應詳細內容。
• 持續比較：
  • 若有官方文件，檢查 API 回傳是否和文件描述一致。
  • 若發現 API 與文件不符，要多嘗試一點變化，以確定是真漏洞、還是單純文件沒更新。

步驟 5：深入調查或尋求協助

• 當你發現某個請求可能會回傳「不該給你的隱藏資料」或「奇怪錯誤訊息」，先記錄下來。
• 若你有更進階的安全測試工具或能力，可以進一步測試。若沒有，也可以將觀察到的問題提供給開發團隊或資安團隊做更深入的檢查。

五、常用工具與簡單操作示範

以下列出幾種最受歡迎、且初學者也能很快上手的測試工具：

1. Postman

• 安裝：可在 Postman 官網 下載。
• 操作流程：
  1. 新增一個「Request」
  2. 輸入 API 的 URL 例如 https://example.com/api/v1/users
  3. 選擇請求方法（GET/POST/PUT/DELETE）
  4. （若需要）在「Headers」或「Body」中填入參數或認證資訊
  5. 點擊「Send」，觀察回傳結果

2. 瀏覽器開發者工具 (以 Chrome 為例)

1. 進到你要測試的網站或前端介面
2. 按下 F12，選擇「Network」面板
3. 在網頁上操作某些功能後，查看 Network 裏面是否有呼叫到 api/xxxx 或 graphql 之類的 Endpoint
4. 點擊對應的請求，可檢視 Request 與 Response 細節

3. Burp Suite (社群版)

• 適合想要深入測試、並對資安領域有興趣的人員。
• 基本概念：
  1. 將瀏覽器的「代理 (Proxy)」設定指向 Burp Suite
  2. 當你在瀏覽器進行操作時，Burp Suite 會攔截並顯示請求，你可以手動修改後再送出
  3. 觀察回應是否有安全問題或非預期的行為

六、黑箱測試常見檢查方向 (簡易清單)

1. 驗證與授權
   • 不登入或用錯的帳號去呼叫機敏資料看可否成功？
   • 用一般使用者的角色呼叫管理者端點，看看是否會錯誤地被允許。
2. 輸入驗證
   • 在需要數字的地方輸入文字或符號、在必要欄位留空值。
   • 檢查 API 是否回傳友善且正確的錯誤訊息，或直接崩潰 (500)。
3. 錯誤處理
   • 查看回應中的錯誤訊息是否洩露了伺服器內部資訊 (例如資料庫連線字串、原始堆疊訊息 Stack Trace)。
4. 舊版本或隱藏路徑
   • 嘗試在 URL 中改版號，如 /api/v2/、/api/old/ 或 /api/v1/deprecated 等，看是否真的還能存取。
   • 舊版本常常存在安全弱點。
5. 資料範圍與邏輯
   • 若 API 會回傳清單 (例如查詢訂單列表)，嘗試翻頁參數 (page=1,2,3…) 看是否能看到不該顯示的其他使用者資料。

七、測試完成後的總結與建議

1. 整理發現：
   • 把測試過程中所有「可疑結果」集中記錄下來，包含操作步驟、請求與回應範例。
2. 風險評估：
   • 根據可疑結果，初步判斷對系統或使用者的潛在影響程度。
3. 提出修復意見 (若你有初步資安概念)：
   • 如輸入驗證不足，可建議「加上欄位檢查」或「適當錯誤訊息處理」。
   • 如授權檢查不嚴謹，可建議「分層權限驗證 (RBAC)」或「強化 Token 驗證」。

八、結語

進行 API 黑箱測試最重要的是「保持好奇心，並勇於嘗試」。只要能按照上述流程，找出 API 路徑、嘗試不同參數與方法，再觀察回應的差異，就能在不需要讀懂程式碼的情況下，初步測出 API 是否有明顯的漏洞或錯誤。

當遇到複雜狀況時，也別害怕求助：可以詢問開發者、或參考專業資安社群的經驗。透過一次次的測試、紀錄與思考，就能一步步累積經驗，成為更熟練的 API 測試人員。

延伸閱讀與參考資源

• OWASP API Security Project
• OWASP REST Security Cheat Sheet
• OWASP REST Assessment Cheat Sheet
• 書籍：
  • Corey J. Ball – “Hacking APIs: Breaking Web Application Programming Interfaces”
  • Confidence Staveley – “API Security for White Hat Hackers”