VAmPI 漏洞 API 實戰：初學者如何進行 API 安全測試與漏洞檢測

今天要來聊聊 VAmPI。嗯，它是一個… 故意寫得很爛的 API，專門用來練習 API 安全測試。算是一個靶機吧，可以讓你合法地搞破壞，去理解一個 API 到底能怎麼被玩壞。

我自己是覺得，這東西不只是給想做滲透測試的人玩，如果你是開發者，花點時間玩一下，會對你寫出更安全的 Code 很有幫助。你會知道，原來一個小疏忽，後果會這麼嚴重。

重點一句話

簡單講，VAmPI 就是一個 API 安全的練功房，它把 OWASP API Top 10 的經典漏洞都做出來了，讓你在一個安全的環境裡，實際體驗駭客是怎麼思考和攻擊的。

環境設定：先把靶場架起來

這個很簡單，前提是你要有 Docker。有 Docker 的話，一行指令就搞定了。

sudo docker run -d -e vulnerable=1 -e tokentimetolive=18000 -p 5000:5000 erev0s/vampi:latest

這行指令就是… 啟動 VAmPI，然後把它放在背景執行（-d），最重要的是 `-e vulnerable=1`，確保所有漏洞都是開啟狀態。然後把服務開在 port 5000。

跑起來之後，我習慣用 `curl` 測試一下它是不是真的活著。

curl http://localhost:5000

有看到 JSON 回應，就表示成功了。可以開始了。

所以，到底找到哪些洞？

環境好了，接下來就是好玩的部分。我沒有照順序，大概就是想到什麼就試什麼。這邊記錄幾個比較經典的。

BOLA：你的就是我的，不分你我

BOLA，全名叫 Broken Object Level Authorization，物件層級授權破損。這在 OWASP API 風險清單上排第一名，不是沒原因的，因為它真的太常見了。

白話講就是，系統只檢查你「有沒有登入」，卻沒檢查「這東西是不是你的」。

我先用 `edward` 這個帳號登入，新增一本書，書名叫 "My Secret Book"，裡面寫了一些秘密。
然後，我登出，改用另一個帳號 `sam` 登入。
理論上，`sam` 應該看不到 `edward` 的書，對吧？
結果我直接去猜 URL... `GET /books/v1/My%20Secret%20Book`，伺服器就把 `edward` 的秘密內容給我了。完全沒擋。

這問題超大。想像一下，購物網站的訂單、社群網站的私人訊息… 只要猜對 ID，就能看到別人的資料。

Mass Assignment：我自己幫自己加權限

這個也很好笑，叫「巨量指派」。通常發生在註冊或更新資料的時候。

我去看註冊 API (`/users/v1/register`)，它需要你傳 `username`, `password`, `email`。但我就手癢，多加一個欄位上去：

{
  "username": "eviladmin",
  "email": "evil@vampi.local",
  "password": "hunter2",
  "admin": true
}

我多送了一個 `"admin": true` 給它。一個設計良好的後端，應該要忽略這個它不認識、或不該由使用者設定的欄位。結果… VAmPI 就照單全收了。我就這樣創造出一個有管理員權限的帳號。這就是開發者懶惰，直接把整個 JSON 物件對應到資料庫模型會發生的慘劇。

JWT 偽造：你的 Token 不只是你的 Token

VAmPI 用 JWT (JSON Web Token) 來做身份驗證。登入後，你會拿到一長串的 token。我把這串 token 拿去 jwt.io 這種網站解碼，發現它的加密演算法是 `HS256`。

HS256 是對稱加密，意思是簽名和驗證用的是同一把「秘密鑰匙」。如果這把鑰匙被猜到… 那就完蛋了。

很多開發環境，為了方便，都會用很弱的鑰匙，像是 `"secret"`, `"123456"` 之類的。我就賭它用 `"secret"`。

用 Python 的 `PyJWT` 函式庫，自己簽發一個給 `admin` 帳號的 token，鑰匙就用 `"secret"`。結果… 登入成功。我變成了 admin，可以存取所有受保護的資源。這說明，JWT 的安全性，完全取決於那把鑰匙的強度，還有後端有沒有好好驗證。

SQL Injection：都 2024 了還有這個

對，就是 SQL 資料隱碼攻擊。老掉牙但還是超有效。

我發現有個端點是 `GET /users/v1/{username}`。很明顯，它是把使用者名稱直接拼到 SQL 查詢裡。我在 username 的地方塞了一個單引號 `'`，伺服器就回我 `500 Internal Server Error`。這是一個非常強烈的信號，表示後端資料庫被我的輸入搞混了。

接下來就不用手動了，直接開 `sqlmap` 這個自動化工具。指令大概長這樣：

sqlmap -u "http://localhost:5000/users/v1/*" --headers="Authorization: Bearer <你的JWT>" --dump

然後… 就等著看它把整個資料庫的內容，使用者帳號、密碼（而且還是明文）、書本的秘密，全部倒出來。真的是一覽無遺。

漏洞排個優先級看看

老實說，找到一堆漏洞，如果都要修，開發者會瘋掉。所以通常要排個優先級。我自己是覺得可以這樣看：

漏洞類型	攻擊難度 / 普遍性	造成的衝擊
BOLA (權限繞過)	很低。只要有帳號，到處亂試 ID 就有機會。超級常見。	高。可以直接偷看別人的個資，訂單、訊息什麼的。
Mass Assignment (特權提升)	也很低。註冊時多塞個欄位而已，猜對欄位名就行。	嚴重。如果能把自己變成 admin，那基本上就是拿下整台主機了。
SQL Injection (資料隱碼)	中等。需要找到注入點，而且現在很多框架會自動防禦。但一但找到，就…	毀滅性的。整個資料庫被看光光，甚至被刪除或修改。
JWT 弱金鑰 (偽造身份)	難度不一定。完全取決於能不能猜到或偷到那把 secret key。但如果用的是預設弱密碼，那難度就是零。	嚴重。跟 Mass Assignment 差不多，可以直接偽裝成任何人，包括管理員。

一些常見的誤解

玩完 VAmPI 後，有幾個想法，我覺得可以釐清一下。

首先，API 安全不只是滲透測試人員的事。如果你是開發者，這些漏洞幾乎都是「設計或實作階段」的疏忽造成的。與其等著被駭客打，不如一開始就養成好習慣。例如，更新資料時，不要整個物件丟進去更新，要明確指定哪些欄位可以被使用者修改。

再來，OWASP Top 10 是一個很棒的起點。不過呢，這只是個全球性的指南。像在台灣，如果你服務的對象是政府機關或關鍵基礎設施，那你還要考慮到《資通安全管理法》的要求。這時候，發現漏洞不只是「修好就好」，還可能牽涉到通報、鑑識等法律流程。這點跟我們在國外論壇看到的情況很不一樣，法規的壓力會讓整個處理方式完全不同。

最後，不要以為用了很潮的框架就安全了。框架能幫你擋掉一些像 SQL Injection 的基本攻擊，但沒辦法解決 BOLA 這種邏輯上的漏洞。權限控管，終究還是要靠開發者自己去仔細思考和實作的。

總之，花點時間玩玩 VAmPI 或類似的靶機，真的會讓你對 API 安全有更深的體悟。不是看文章，而是親手把它打穿的那種感覺。

討論一下：看完這幾個漏洞，如果你是開發者，你會覺得哪個最可怕，最想優先防堵？是 BOLA 還是 Mass Assignment？在下面留言聊聊你的看法吧。