API安全漏洞實測：VAmPI環境從零開始操作教學

讓我們從零開始認識這個故意設計成漏洞百出的VAmPI測試環境

這次想聊聊VAmPI這個小工具，基本上算是種專門設計來「帶點漏洞」的API環境，拿來練習API安全測試還挺方便。說它有點像個沙盒，差不多就是這種感覺——反正你也不用擔心會誤觸什麼大麻煩，就Docker跑起來就好。常見那些現實裡API容易出包的地方，大致都能在裡面找到些影子，例如權限沒鎖死、資料亂給、JWT設定怪怪的，類似這樣。

如果要說目標，其實主要就是動手體驗一下OWASP那套API漏洞清單提到的情境。例如有些人會把對象授權搞得鬆鬆散散，也有人直接把欄位全開（mass assignment），或者是token憑證處理時遺漏細節。我自己倒不是每一條都照著來，而是邊玩邊記錄過程，順便熟悉一些常用工具，比方Postman、Burp Suite這幾個老朋友，再加上ffuf、sqlmap還有Python腳本。有時候環境部署會花點時間，但只要習慣了Docker操作流程，大概半天內就能摸出頭緒。記下每一項測到的洞與嘗試過的方法，不只是為了技術層面的理解，有時候也是訓練怎麼撰寫報告，把發現講清楚。

至於API到底怎麼回事？大家應該或多或少聽過，就是讓不同軟體之間可以溝通彼此。其實它比較像橋樑，有人說很像轉運站也不算太離譜啦——某個系統想要資料、功能或其他資源，就透過API去請另一邊幫忙。舉例嘛…比方平常登入網站用Google帳號，那背後其實就是網站調用了Google那一串API流程；你的請求送出去後，Google那端會回傳一些東西，有時是身份資訊、有時可能只是驗證票據，看狀況而定。

不曉得是不是因為行動裝置爆發，加上一堆雲服務跟物聯網產品出現，現在API好像變成無所不在。不管手機App還是企業級平台，只要牽扯到資料交換或自動化協作，大多繞不開API介面。而安全問題往往就是從這裡冒出來——尤其當架構複雜度拉高、維護又分工，各種疏忽累積下來，很容易被攻擊者鑽空子。有不少觀察認為，如果沒有對API做足夠檢查和防護措施，其實風險遠比表面看起來高上一大截。

為什麼API安全在現代網路世界裡超級重要？

API之所以在資安領域裡受到重視，部分原因大概跟它們經常牽涉到某些比較敏感的功能和資料有關。這些介面一旦被設計得不夠周全，或是哪個設定沒弄對，像是權限、驗證流程、資料傳遞等等，就可能會變成攻擊者下手的目標。畢竟不少API都是直接讓外部存取，有時候甚至整個入口都擺在網路上，也就很容易被各種人發現、嘗試。如果以近年來的情況來看，隨著越來越多網站把處理邏輯搬去前端，只留一個RESTful之類的後端API給前端用，攻擊焦點好像也慢慢偏向這種介面。所以說現在要顧資安，不太可能再忽略API這塊。

有時候測試環境會搭一套VAmPI出來。那天我是用Docker拉了一下映像檔，大概執行了如下指令：

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

這樣子啟動以後，它會開啟所謂「易受攻擊」模式，把JWT存活時間拉長到大約五小時上下，再把服務丟在本機的五千號埠口。基本上只要用curl打一下`http://localhost:5000`，回應如果還過得去，看起來API大致沒問題，是可以開始玩玩看的。

不過正式測漏洞之前，一般都還是建議先做點情報收集吧。像是在黑箱測試（就是你啥原始碼或內部細節都拿不到）場景下，誰也說不準哪裡會漏掉什麼洞，所以多查查有哪些出口、多打聽一下每個端點能幹嘛、規則長怎樣，其實滿有必要。有些人習慣先跑Nmap掃描本地，就是想知道現在主機上頭究竟有什麼服務、有哪幾個埠口開著……總之先摸清楚基礎狀況，有助於後續操作。

有時候掃描結果也不一定那麼明顯，要嘛少掉一些預期中的東西，要嘛偶爾多冒出奇怪的新門戶，好像也算常見吧。

Comparison Table:

結論類別	具體結論
API安全問題	許多API存在基本的安全漏洞，且開發者常忽視權限控管與資料驗證。
認證機制風險	JWT若使用弱密鑰，容易被偽造並造成未授權存取。
資料暴露問題	不當設計的除錯接口可能導致敏感資料洩漏，如用戶密碼等。
SQL Injection風險	部分系統對輸入參數缺乏防範措施，使得SQL Injection攻擊成為可能。
建議與改進方向	強化API的存取控制、資料驗證及加密技術，以提升整體安全性。

手把手教你用Docker快速架設VAmPI實驗環境

有時候在測試API的時候，會有人想要徹底檢查一下到底開放了哪些服務。像這次，有人透過一個指令去掃描本地端，大致上就是想知道是不是還藏著什麼奇怪的東西。有些旗標啦，什麼預設腳本、服務版本偵測、作業系統判斷，然後全部連接埠都翻一遍——其實也沒幾個人會真的耐著性子全掃一遍，大概只有對風險比較敏感才這樣吧。

你說為什麼要這樣？大部分API都跑在網頁用的協定上，但偶爾也會有不小心把資料庫或者某種內部調試介面也一起開出來。這種情況不能說很常見，可是誰又敢保證沒有。

結果其實沒那麼複雜，最後好像就只看到五千多號那個TCP埠是亮著的，而且還是用Python那套Werkzeug架起來的。換句話說，那個VAmPI應該就在這裡動作，於是注意力自然就被吸引到這裡。

確定API真的能打得通以後，接下來就是找那些「可能被遺漏」或根本沒寫進文件裡的路徑。ffuf這種工具就蠻適合丟一些自訂單字表進去亂撞看能不能戳出什麼新花樣。不過嘛，不是每個API都乖乖掛Swagger或類似說明介面給你看，有時候只能靠自己土法煉鋼慢慢摸索。

指令大意差不多啦，就是把網址最後留一格FUZZ給它替換成各種可能的路徑，再加上一份自己準備的清單；結果只挑HTTP回傳碼像兩百、四百零一或四百零三那幾種，也就是正常、有權限問題或者限制存取之類。有人認為只要出現這些回應，就表示某些端點存在，只是不一定讓你直接玩到手。

其實很多開發測試環境都會悄悄多放一些路由點，也未必會特別提醒大家。不過找到之後是不是真的有用，要再一步步確認才行。有時候只是名字響亮但內容空洞，也不是沒遇過。

駭客的第一課：如何用Nmap和ffuf摸清API底細

在用那種涵蓋不少 RESTful 常見路徑的字典去試探時，像什麼 /login、/register、/users/v1 這些都被納入考慮裡，結果發現各式端點的機率確實高了不少。其實一開始只是想碰碰運氣，沒想到還真的找出幾個蠻特別的 API 路徑。有些印象比較深的，大概像是 /users/v1 這類處理使用者相關操作的主路徑，也看到跟書本和某些秘密資料有關的 /books/v1。還有一條很容易讓人忽略，就是 /users/v1/_debug，看起來似乎開發階段留下來的小後門，結果意外把使用者資訊全給曝光了。甚至有那種會重設資料庫（包括測試帳號）的 /createdb，也就是說資料庫內容可能隨時被清空重建。以及那條能直接查目前登入者資訊的 /me，再往下細看，註冊新帳號和登入驗證分別在 /users/v1/register 和 /users/v1/login，只要認證通過還會拿到 JWT。

每一條端點感覺都隱約帶著點風險，有時候是設定不當，有時候乾脆就是資料曝光或檢查邏輯太鬆。後續打算把這些列進 Postman 裡，一條一條慢慢摸清楚它們到底怎麼跑、有哪些地方可以動手腳。

再來就換成直接用 Postman 跟 API 互動了。在前面大致掃出 VAmPI 有哪些路徑後，其實接下來也沒有太複雜，就是靠著 Postman 去組合請求、搞懂認證流程、順便管一下 token，用起來比寫腳本方便多了。話說回來，如果只是想初步摸清 API 行為和驗證規則，用這工具倒是挺順手——測試一些極限狀況或不正常請求也輕鬆。

說到怎麼導入 API 文件，VAmPI 那邊其實直接公開了一份 OpenAPI 3.0 的說明檔（openapi3.yml），大家可以從 GitHub 找得到。我當初好像就先打開 Swagger Editor 把 yml 檔載進去，再轉存成 Postman Collection 格式（JSON），省得自己慢慢加每個路徑。不過步驟大概也不是唯一正解啦，只是這樣做對我來說比較快。如果記憶沒錯，好像也有人會用其他工具導入，不過方法其實差異不大。

Postman實戰教學—從註冊帳號到竊取JWT令牌的全過程

當初匆匆把這套 API 匯進 Postman 之後，一開始其實沒什麼太大期待。那時候只是順手設了個 baseURL，對應到自己本地的測試環境——網址大概就是 localhost 那種。不知道為什麼，設定好沒多久，整個介面就突然冒出一堆分門別類的 endpoint，像是「使用者」、「書籍」那些資料夾，看起來還滿好找的。這樣分類下來，要逐步測試反而方便不少。

有趣的是，正式玩功能前，好像得先初始化一下資料庫才行。在首頁有個叫 /createdb 的接口，只要用 GET 去打它，就會自動塞進一些預設帳號、幾本書還有管理員。差不多等了一下子，那些帳戶和基本數據就都建好了。有點像是給新人鋪路，不然後續怎麼測安全問題嘛。

註冊新用戶倒也沒有想像中複雜。跑去 /users/v1/register 打個 JSON，把名字、信箱、密碼隨便填一填（欸，有人很愛拿 hunter2 當密碼喔），API 馬上回說註冊成功，大約就是建立完成這種訊息吧。

至於登入流程，比較常見那種，需要輸入剛剛創好的帳號和密碼；結果伺服器回傳過來，不只有認證成功訊息，還附上一串 JWT 標記（長得頗亂，但很關鍵）。這東西啊，如果以後要存取受保護資源，就一定得放到 Authorization 標頭裡，用 Bearer token 格式帶著。懶得每次貼 token，所以有人會直接存在 Postman 環境變數裡面，把授權 tab 設成 Bearer Token，每次打 request 就不用煩惱重複貼上了。

等權杖都準備妥當，大致就能逛遍需要登入才能看的地方。例如說 /me 可以查自己的小檔案；但奇怪的是，有個 /users/v1/_debug 路徑竟然直接把系統所有用戶清單丟出來，而且連密碼明文都看得到（還包含管理員標示）。遇到這種情況，很難不懷疑是不是開發階段留下來的漏網之魚，本來只想給內部 debug 用，卻忘記收掉。有些人看到會覺得毛骨悚然，也算是一種暴露過量敏感資訊吧。

話說回來，各項 API 行為到底如何，其實細節還是蠻值得再慢慢咀嚼的。有些地方藏著意外驚喜，也可能混雜著點風險。不確定哪天又會發現什麼新花樣。

當開發者忘記刪除_debug端點會發生什麼可怕的事？

在那一段探索時，好像發現了不少端倪。API那邊，對於送進來的JSON內容，幾乎全收，也沒特別去理會那些意外出現的欄位。然後檢查權限這件事，看起來除了有個令牌（token）外，沒見到什麼其他的把關機制。說起來，之後還真有發展空間。錯誤訊息和狀態碼也滿一致，這點在之後做枚舉測試時變得挺方便。當時手上已經有個測試環境，登入帳號也搞定了，可以碰觸一些內部的敏感資料。接下來，大致就輪到找API裡頭那些邏輯上可能卡住或配置怪異的地方——大概就進入實際利用階段。

跳到比較深一點的第四階段吧：算是漏洞摸索期。有了基本結構、認證流程這些東西底子在，就開始動手一點一滴去挖洞。主要還是參考OWASP API那份排名靠前的清單，有時候人肉測，有時候交給工具跑跑看，看能不能揪出VAmPI系統裡面那些容易被忽略的小縫隙。不外乎包裝各種請求、改payload、換token——總之就是去挑戰API原本以為自己「一定會怎麼運作」這種假設。

其中一項觀察是關於資料暴露問題，差不多屬於OWASP提過那類「資訊洩漏」風險。有個接口，路徑好像是
GET /users/v1/_debug
打下去回來的是用戶清單的大雜燴，包括帳號名、信箱，再甚至連密碼都直接明文帶出來，不分你是不是管理員，只要有登入身份就能看到全部細節。有趣的是，那個admin標記（真假）也跟著曝光。在某些開發環境裡頭，也許會留下這種除錯接口，但如果忘記收掉，就很容易讓資料直接攤開給不該看的人碰巧撿到。不光只有基本身份資訊，有時候連密碼都一起洩出去，要是哪天有人用同樣密碼登別的平台，那麻煩可能會一層層擴散開——雖然目前看起來受影響的人數不到太多，但對某些使用者而言應該還是頗值得警覺。

看我如何用JSON小技巧把自己變成管理員

那時候在註冊新使用者的環節，有個情況還挺怪異。有人隨手往請求內容多塞了一個本來應該不能讓一般人控制的欄位，像是「admin」這種敏感屬性，然後直接傳給伺服器。好像只花了幾分鐘，伺服器就接受了全部資料，也沒檢查那些不該被動到的東西。據說，不少系統其實會漏掉去篩選用戶提交的字段，結果造成有些人能改變重要狀態，比如原本只是普通帳號卻莫名其妙多了管理權限。有時候這類問題發生得很隱晦，用戶甚至沒察覺，但長期下來可能引發一連串預料不到的狀況。

另一頭，有個跟資源存取相關的小插曲。有次，有人用自己的身份建立了一本書，裡頭放了一些只有自己知道的小秘密。過沒多久，他換成別人的身分登入，同樣帶著授權憑證，結果隨便猜一猜或搜尋一下那本書的名稱，就能看到原來設計給其他使用者專屬看的內容，包括那段秘密。當時API端好像也沒特別管是哪個使用者擁有哪份資料，只要請求格式對了就都送出去了。這種現象其實在某些服務上偶爾會遇見，如果沒有把關好，很容易讓其他非擁有者讀到不該讀到的資訊，看起來跟物件授權機制鬆散有點關聯。

還有一次，那也是挺令人摸不著頭緒的一幕。一名用戶拿著別人的JWT（比如叫sam），想試著替另一位叫edward的人更改密碼。他直接送了一筆更新密碼的請求，好像流程也沒啥阻礙——新密碼順利就套用了。這種操作如果沒有額外驗證身分或限制功能等級，總讓人覺得風險藏在細節裡。有些系統可能只是單純判斷是否已登入，而忽略了進一步檢查執行動作的人是否真正具備這項權限，所以才會出現這類看似無心但影響不小的漏洞。

不用密碼也能看別人的秘密？BOLA漏洞實測演示

那時候在檢查帳號密碼相關功能時，發現有些地方沒做什麼存取權限的檢查。只要有人手上握有一組JWT，不管是不是管理者，都能隨意去動別人的帳戶密碼。想像一下，如果有心人士拿到一個合法憑證，搞不好就能幫每個用戶改掉密碼，把別人都鎖在門外——這種情況其實並不罕見。

說到API裡的漏洞，有個跟資料庫操作有關的問題也跳出來。比如查詢使用者資訊的那條GET路徑，看起來像是用username當作參數。我順手丟了點奇怪內容進去，好像「sam' OR '1'='1」這類東西，結果伺服器直接報錯，看起來後端處理SQL語句時根本沒防範特殊字元。有些工具，比如sqlmap，大致測試了一下，就把某些表格抓了下來──那些用戶名稱、電子信箱、加密過的密碼和管理權限之類，好像也包括書本相關的記錄。整體感覺，對資料庫保護顯得相當鬆散。

其實到了那個階段，也沒怎麼使出什麼太複雜技巧，只是簡單繞著API走一圈，就看到不少算嚴重的破口。不少問題好像都圍繞著缺乏細緻存取控制、設計預設過度樂觀或是輸入驗證做得不夠仔細等等。

說回安全性，有時候會想看看認證機制到底牢不牢靠。這次稍微摸了一下JWT驗證流程，以及登入嘗試次數方面到底有限制沒有。如果這部分設計太寬鬆，其實滿容易讓攻擊者找到空子，比如暴力破解或假冒身份之類。在OWASP API常見風險裡，這兩塊一直被提到。總之，如果疏忽了，很可能出現帳號被奪走或者其他麻煩狀況，不過還是要看具體應用場景啦……

破解JWT令牌的黑暗藝術—偽造admin身份全記錄

JWT 這東西啊，其實在不少 API 裡被拿來做身分驗證，VAmPI 也不例外。用戶只要登入，API 就會回傳一串看起來挺像亂碼的 token，裡面大概包含使用者名稱、產生時間和失效時限。這類 token 基本上都是三段組合起來，有點像某些網路密碼學文件提到的格式，只是全部都經過 base64 編碼，看起來沒那麼好讀。

有件事蠻微妙，就是它採用 HS256 這種對稱式加密，也就是說簽名時只靠一個「大家知道就能用」的共同秘密。頭部那區解出來很單純，大致寫著演算法是 HS256、型態 JWT，那種很常見的格式。不過話說回來，如果那個 secret 設定得太簡單，比方說有些開發環境直接用英文「secret」，幾乎誰都能猜得到，那偽造 token 的門檻其實比想像中低很多。

舉例講，我看到有人隨手用 PyJWT 寫了小段程式，把使用者改成「eviladmin」，時間設成現在多個小時，不知怎地還真就弄出一顆看似正規的 token。token 打印出來之後，加到 HTTP 請求標頭裡，「Authorization」欄位貼上去，再丟給 API 試試。

然後就有點奇怪了，用這種自製 token 去查 `/me`，回應內容居然是 eviladmin 的資料；再問 `/users/v1/_debug`，整包用戶清單好像也直接給你看。有點像系統根本沒細查這份 token 合不合法，只要簽章對得上、內容格式差不多，就讓人進去了。

整件事情其實滿值得注意：光是一把弱密鑰（據說不少測試環境預設值都很陽春），配合基本驗證步驟，就可能讓攻擊者輕鬆假冒任何帳號，包括管理員帳號。這漏洞感覺不是什麼新鮮事，但還是有人忽略了。如果真的遇到類似情況，多半要重新審視 JWT 秘密金鑰強度，以及 API 對於身份資訊是否有額外把關，否則風險恐怕一直都在那邊悄悄等人踩坑。

從這次實驗我學到的五個血淋淋的API安全教訓

這次在VAmPI這個帶有漏洞的API上摸索一陣，倒也算是讓人實際碰過API安全測試了。原本只是想隨便了解一下RESTful API大概長什麼樣，結果後來發現不少問題，其實和外面常見的系統漏洞好像差不了多少。有時候進度不是很順利，不過陸陸續續做下來，大致算是碰到了幾個環節：像用nmap、ffuf之類工具亂試端點位置，也慢慢看懂JWT那種驗證流程在幹嘛；還有一些設計上的小缺失，例如權限控管沒有管到、資料欄位任意賦值那些，都能找到些端倪。SQL Injection就…本來以為不會出現，沒想到還真的能撈到後台資訊。至於加密機制也挺單純，一時好像都能自己組裝出假的權杖。快結束前其實開始想，要不要乾脆來個暴力破解，畢竟發現系統根本沒有限制連續請求。

不知是不是最近太多API產品冒出來，不只手機App，連雲端服務啥的都得靠它們溝通吧？但這樣一來風險也跟著增加，如果管理上沒把安全列為核心考量，有人惡意利用某個接口，只要湊對HTTP請求格式，好像就能搞到不少麻煩事，比如特權升級或拿到整包數據。VAmPI這東西感覺滿適合當作練習場啦，畢竟真實情境會遇到的那幾項OWASP API Top 10弱點，它大概都有模擬。不過說到底，我覺得最大心得應該就是——很多漏洞不用靠什麼高深工具或冷門技巧，多半只是開發人員有地方疏忽、或者某些防護機制壓根兒沒上而已。

回頭看其實每一步都有讓人學到東西。不僅摸清楚API怎麼搭建與運作，也慢慢理解攻擊者若想利用系統缺口會從哪邊下手。有些細節以前書上唸得死板板，用起來卻完全兩回事。現在再碰類似案子，大概就比較知道該怎麼規劃檢查重點了。不過這領域變化蠻快，有時候舊招式突然又重新流行起來，也未必適用所有情境，所以還是要保持彈性才行。如果真要說結論嘛，那大概就是——API安全問題離日常並不遠，而且只要基礎做不好，再複雜的防禦措施反而可能派不上用場吧。