🔒 ibeindeed.net Worker 資安強化 Spec

一、現況架構（六支 Worker）

二、已發現、須優先處理的問題

三、目標架構：三層信任分類

原則：同一信任層級才合併，不同層級不共用 Secret／不合併 Worker

為何抽換 ibe-publish-worker： 現況用一組長效 GitHub PAT 常駐 Worker 直接寫檔案，爆炸半徑最大。 改用 GitHub Actions 後，Worker 只觸發 workflow_dispatch，實際寫入由 Actions 內建短效 GITHUB_TOKEN 處理，且有完整 log。 觸發入口仍須 Cloudflare Access 保護。

四、各層級 Token／驗證機制設計

核心概念：token exchange — 先證明資格，換一張短效通行證，之後請求都用這張證。 就算演算法被看光，沒有有效 token 也打不進來；就算 token 外流，損害範圍只在效期內。

1. 免費公開層

Cloudflare Turnstile：進頁先過人機驗證，前端拿 token 呼叫 API，Worker 驗證有效性。搭配既有 IP 限流。

2. 付費層

票券密碼驗證通過 → Worker 簽發短效 token（30-60 分鐘）→ 後續對話帶 token，過期用同組密碼重新換發。

3. 金流層

/notify 沿用 CheckMacValue 簽章（現有作法正確，已含冪等處理）。管理端點改用 Cloudflare Access 核發 JWT。

4. 部署/管理層

觸發入口掛 Cloudflare Access，實際寫入交給 GitHub Actions 短效 Token。

五、純 API／滲透防禦清單

CORS 只擋瀏覽器，不擋 curl／腳本直接呼叫。依投報率排序：

• Cloudflare Rate Limiting Rules — 邊緣層限流，比自刻 KV 更穩
• 停用 *.workers.dev — 關掉不設防後門入口
• 管理端點簽章化／Access 化 — 不再用共用密碼比對
• Service Bindings — Worker 對 Worker 內部呼叫不經公開網路
• Turnstile — 公開端點加人機挑戰
• WAF Managed Rules — 擋已知攻擊 payload
• 每支 Worker 內部輸入驗證 — 金額/權限/票券一律回頭查資料庫
• 錯誤訊息乾淨化 — 不吐 stack trace／Secret
• Logpush + 異常告警

六、優先處理順序總表

1. 移除 IBE-TEST 萬用密碼
2. 移除或鎖住 test=1 免驗證測試模式
3. 金額／票券／管理權限一律由 Worker 端重新判定
4. 拆掉共用 ADMIN_SECRET，改獨立最小權限憑證
5. admin 密碼從 URL 參數改為統一方式，最終改用 Access JWT
6. 停用公開 workers.dev，管理型 Worker 加 Access
7. 對 ecpay / oracle 系列 / agent-worker 加限流與成本上限
8. ibe-publish-worker 評估改用 GitHub Actions
9. 免費層兩支 Worker 評估合併
10. 確認 Supabase 敏感資料表 RLS（尤其 orders）
11. 確認 GitHub Token 效期與 scope
12. 完成剩餘三支 Worker 完整程式碼審查
13. 清除舊 Netlify 專案

七、心態備註

資安沒有「一次修完就結束」的狀態，只有「當下風險降到可接受」。此文件列出的是目前已知的問題與強化方向， 完成後代表「沒有已知的高風險漏洞」，不代表未來新增功能或第三方平台出現新漏洞時可以不用再檢查。 建議之後每次改動 Worker 邏輯或新增端點時，順手比對本文件的分層原則與驗證模式。