U3 檢查結果：首次安裝精靈＋版本資訊（登入前就打得到）

檢查日期 2026-09-25｜對應卡片 CM-2155（母卡 CM-2152）｜檢查範圍 9 個檔案 930 行｜工具 run ID wf_7cfdaa3f-a72

沒有能讓外人搶先建管理員、或在系統開通後重新打開精靈的洞。 卡片最擔心的三件事——設定碼能不能猜、用過會不會失效、把使用者刪掉精靈會不會重開——逐條開檔核對後都不成立，程式裡有明確的防範。

掃描工具這一棒零發現（沒有提出任何候選，所以三人面板沒投票）。我依卡片逐支開檔、再手做惡意輸入實測，另外找到三件低度問題，都不需要緊急處理：

1. 在設定碼欄位塞一個非英文字元（例如 é），伺服器會回 500 錯誤而不是「設定碼不正確」——擋得住，只是擋的姿勢難看，而且會在錯誤收集站留一筆假警報。
2. 程式註解說「兩個人同時送出開通時，資料庫會擋下第二個」，但資料庫實際上沒有這條規則——擋不住。要打到這個窗口必須先拿到只印在裝機終端機上的設定碼，所以實際風險很低，但註解是錯的。
3. 免登入的「前端設定」端點會回傳錯誤收集站的連線字串，裡面有站台位址（可能是客戶內網 IP）。這是前端要能回報錯誤的必要設計，不是程式寫錯，列出來讓決策者知道有這回事。

一般的功能都要先登入，這一棒的 9 支程式不用登入就打得到，攻擊面在所有功能的最前面：

• 首次安裝精靈（5 支）：客戶剛裝好系統時，系統裡一個帳號都沒有，沒辦法用帳號密碼登入。所以安裝程式 install.sh 會在終端機印出一組一次性設定碼（32 個英數字元的隨機碼），客戶把它貼進瀏覽器的精靈畫面，證明「我人在這台機器旁邊、看得到安裝畫面」，精靈才讓他建立第一個公司（租戶）跟這家公司的管理員帳號。建好之後，這條通道要永久關閉。
• 版本資訊（4 支）：/api/1.0/version 回傳產品版本號，/api/1.0/client-config 回傳前端要用的設定（錯誤收集站連線字串、環境名、版本）。兩支都完全不用登入。

要回答的核心問題是：沒有身分可以驗的時候，這扇門靠什麼關？關得牢不牢？

現況（2026-10-01）：本棒各條後來的處理結果如下（過程紀錄保留，不改）。

• U3-1（設定碼特殊字元回 500）＝總表第 183 項，✅ 已修（CM-2215，commit 822216b6c，1.21.0 出貨）。
• U3-2（開通沒上鎖）＝總表第 184 項，✅ 已修（CM-2216，commit a02409392，1.21.0 出貨）。
• U3-3（免登入端點回傳錯誤收集站連線字串）：標「設計使然」，SUMMARY／M24 頁沒有對應條目，查不到修正卡。

工具報的：零條。

無。工具派了兩位研究員（一位讀全部範圍、一位專找寫死在程式裡的密碼金鑰），兩位都交回空清單，所以三人面板沒有東西可投。

① 設定碼怎麼比對？是不是「常數時間比對」？——✅ 是，不成立

白話：「常數時間比對」是指不管你猜對幾個字，系統回應的快慢都一樣。如果用一般的字串比對，猜對的字越多、回應越慢，攻擊者量時間就能一個字一個字試出來。

common/setup/setup_token.py:92 用的是 hmac.compare_digest，這是 Python 專門做常數時間比對的函式，符合要求。設定碼本身是 openssl rand -hex 16（scripts/installer/install.sh:2097）＝ 128 位元隨機數，暴力猜不可能猜中。

但實測發現一個副作用 → 見 U3-1：hmac.compare_digest 碰到非英文字元會直接拋錯。我在本機用實際的 verify_token 放一組假設定碼檔實測：送英文錯碼回 False（正確）、送正確碼回 True、送 é 組成的字串拋出 TypeError。再用 Flask 測試客戶端把同樣的比對放進網址入口，對方收到的是 HTTP 500。這支程式沒有自己接住這個錯誤，會一路冒到全站的「未預期錯誤」處理，寫一筆 ERROR log 並回 500。結果仍是「不放行」，所以不是繞過。

② 用過一次後真的失效嗎？——✅ 會失效，而且有兩道，不成立

第一道（真正的鎖）是資料庫事實：開通成功後，資料庫裡就有了「非原廠公司底下的使用者」，精靈每次開通前都會查這件事（setup_wizard_service.py:302-307），查到就回 409「已開通」。這道鎖存在資料庫裡，重開機、多台機器、重送同一個請求都一樣擋得住。查不出來（資料庫掛了）時也當成已開通擋下，失效方向是安全的。

第二道（額外保險）是清空設定碼檔：開通成功時把磁碟上的設定碼檔內容清空（setup_token.py:95-113）。清空後讀出來是空的，比對直接失敗，連 409 都走不到，一律 403。

特別確認了「刪檔失敗」的情況：程式註解明確說清空失敗不算開通失敗，因為真正的鎖是第一道。我同意這個設計——如果反過來以「檔案在不在」當鎖，刪檔失敗就會留下一條永久可建管理員的通道。安裝程式重跑時也只在檔案「非空」才沿用舊碼（install.sh:2093），已清空的檔不會被當成可用碼印出來。

③「已開通」之後再打 POST /setup/provision，會不會再建一個管理員？——✅ 不會，不成立

順序是：網址入口先驗設定碼（setup_route.py:117）→ 精靈主邏輯先查「開通了沒」（setup_wizard_service.py:167）→ 才開始建。已開通時：

• 設定碼檔已清空 → 在第一步就 403。
• 就算清檔失敗、設定碼還對 → 第二步 409。

兩條路都到不了「建帳號」那一行。既有測試 test/test_setup_wizard_one_shot.py（34 項）涵蓋了這幾條，本棒實跑全數通過。

④「是否已開通」的判據能不能被繞？把那個使用者刪掉，精靈會不會重開？——✅ 從產品介面刪不到，不成立

判據是 infra/setup/setup_state_reader.py:73-79：「users 表裡有沒有任何一筆屬於原廠公司（tenant 1）以外的使用者」。刻意不看帳號是否停用——停用的管理員仍算「開通過」。

我追了所有能讓這個判據變回「否」的路：

而且即使精靈重開了，攻擊者還是需要設定碼——開通時已清空，要重新產生只能在主機上以 root 重跑安裝程式。換句話說，能讓精靈重開的人，本來就已經是系統的主人。

DEV 唯讀查證（2026-09-25 11:30 +08，BEGIN READ ONLY … ROLLBACK，沒有寫入）：tenant 1 有 1 位使用者（原廠 root admin），tenant 102／131／158 各有使用者 → 判據回「已開通」。users 表沒有「已刪除」欄位，只有 status，確認刪除走的是改狀態。

⑤ 版本與前端設定端點（完全免認證）有沒有夾帶環境變數、主機路徑、內部 IP？——🟡 部分成立，見 U3-3

• GET /api/1.0/version：只回 version（版本號）與 commit（程式碼識別碼）。版本號來源是打包時寫死的常數檔或 pyproject.toml，commit 是 git rev-parse HEAD 的輸出；兩者都不是使用者輸入、不含路徑或 IP。✅ 乾淨。
• GET /api/1.0/client-config：回 sentry_dsn、environment、version、commit。
  • environment 是 ENV 環境變數的值（例如 DEVELOP_PREMISE），只是一個部署型態名稱，不含機密。
  • sentry_dsn 是錯誤收集站連線字串，格式 http://<公開金鑰>@<站台位址>:<埠>/<專案編號>。站台位址如果是客戶內網的自架站，就會是內網 IP；公開金鑰讓人可以往站台送事件。→ 列為 U3-3。這是前端錯誤回報的必要設計（瀏覽器要直接送事件到站台），Sentry 官方文件本來就把它當公開值；出貨預設不設定、回空字串。
  • 沒有夾帶其他環境變數、主機路徑、資料庫連線或密碼。✅

⑥「有人守了一半」共通疑點

另外順手確認：精靈網址被加進了「授權過期唯讀模式」的豁免名單（common/middleware/license_readonly_mw.py:74，屬 U2 範圍，本棒只讀不報）。豁免的理由是「裝機當下一定沒有授權」，而精靈另有設定碼＋開通後永久 409 兩道門，豁免沒有擴大攻擊面。請求 log 會記錄標頭，但 X-Setup-Token 不在可記錄白名單內，值會被遮成 ***；開通請求的 body 裡的密碼欄位也有遮罩。✅

U3-1 — 非英文字元的設定碼讓比對函式當掉，回 500

• 嚴重度：🟢 低
• 位置：common/setup/setup_token.py:92（hmac.compare_digest(candidate.strip(), expected)）；兩個呼叫點 api/setup/routes/setup_route.py:70、:97
• 白話說明：Python 的常數時間比對函式只接受純英數的文字，碰到 é、中文這類字元會直接報錯。這支程式沒接住這個錯誤，於是一路冒到全站的錯誤處理，回給對方 500。
• 影響：不會放行，也不會洩漏設定碼。實際影響是：①任何人都能讓 /setup/status 和 /setup/provision 回 500；②每一次都會寫一筆 ERROR log，有接錯誤收集站的話還會送一筆假警報（站台每分鐘有 60 筆上限，不會被打死，但真的錯誤可能被淹掉）。
• 觸發前提：連得到網站；系統尚未開通（或開通時清檔失敗）——開通後設定碼檔是空的，程式在比對前就回 False，走不到這行。已開通的正式環境打不到。
• 實測：本機放一組假設定碼檔，直接呼叫 verify_token('éééééééé') → TypeError: comparing strings with non-ASCII characters is not supported；用 Flask 測試客戶端把同樣的比對掛成網址 → HTTP 500。沒有對正在跑的服務實測（本機 BE 當時未啟動）。
• 建議修法：比對前先確認輸入只含英數字（不符就直接回 False），或把兩邊都 .encode() 成位元組再比——hmac.compare_digest 對位元組不挑字元。

U3-2 — 註解宣稱的「資料庫唯一約束」不存在，並發開通擋不住

• 嚴重度：🟢 低
• 位置：app/setup/service/setup_wizard_service.py:37-41（註解）；實際的判斷在 :167（先查未開通）與 :249（建帳號）之間
• 白話說明：精靈的流程是「先查開通了沒 → 沒有就建」，中間沒有上鎖。程式作者知道這個窗口，並在註解寫「不另加鎖的理由是：帳號名稱與 email 在資料庫是全域唯一，第二個請求會撞到約束而整批作廢」。但查了資料庫，users 表只有 uid 有唯一約束，帳號名稱只有一般索引（不擋重複），email 什麼都沒有（DEV 與出貨基線 scripts/init/02-schema.sql 都一樣）。帳號重複的檢查只在程式層做（先查有沒有同名、再寫入），這個檢查本身也有同樣的並發窗口。
• 影響：兩個請求同一瞬間送出時，可能建出兩家公司、兩個管理員；若帳號名稱相同，甚至會出現兩筆同名帳號。
• 觸發前提：必須持有設定碼（只印在裝機終端機、存在只有 root 讀得到的檔案裡），且兩個請求要在同一瞬間送出。拿到設定碼的人本來就能直接開通，所以這個窗口沒有多給攻擊者新能力——實務上比較可能發生的是裝機者自己在瀏覽器連點兩次。
• 建議修法：擇一。①最小：改正註解，寫清楚「並發窗口存在，因需持有設定碼而接受」。②補鎖：在「查開通了沒＋建立」外面包一個資料庫層的鎖（例如 PostgreSQL 的 advisory lock），讓第二個請求排隊，排到時查到已開通就回 409。

U3-3 — 免登入端點公開錯誤收集站連線字串（設計使然）

• 嚴重度：⚪ 資訊
• 位置：api/version/routes/client_config_route.py:40
• 白話說明：前端程式是「一顆映像檔賣所有客戶」，沒辦法在打包時寫死每個客戶的錯誤收集站位址，所以改成開站時向後端要。前端在登入前就可能出錯，所以這支必須免登入。
• 影響：客戶有設錯誤收集站時，任何連得到網站的人都能拿到站台位址（自架站就是內網 IP＋埠號）與可以寫入事件的公開金鑰，可以往站台灌假的錯誤事件。拿不到讀取權限（讀事件用的是另一組權杖 GLITCHTIP_API_TOKEN，不在這裡）。
• 觸發前提：客戶有設定 SENTRY_DSN（出貨預設沒設）。
• 建議修法：不需修程式。若決策者介意，可在站台端限制「只接受來自本系統網域的事件」（GlitchTip／Sentry 的 Allowed Domains 設定），部署文件補一句。

第一層：工具正式報告（經三人面板驗證）

• 驗證章：verified（stamp CLAUDE-SECURITY-REVISION-3f6290400be3-dirty.json）
• 候選數 0、面板投票 0、研究員派出 2／交回 2、失敗 0、續跑 0。
• 「零發現」代表工具的研究員讀完這 9 支沒提出任何疑點，不代表這 9 支乾淨——工具擅長找「程式寫錯」，不擅長找「註解跟現實不符」「輸入格式讓函式當掉」這類需要實測或查資料庫才看得出的問題。

第二層：runner 自行開檔核對（未經三人面板投票）

• 範圍 9 支逐支通讀；卡片「重點看什麼」五條＋「有人守了一半」八種樣式逐條答完。
• 跨讀了範圍外的相關程式（只讀不報）：install.sh 的設定碼產生段、license_readonly_mw.py 豁免名單、request_context_mw.py 身分歸零、app_mw.py 標頭遮罩、jedi-iam 的使用者刪除路徑與建帳號重複檢查、jedi-common 的全站錯誤處理。
• 實測：U3-1 用真的 verify_token 與 Flask 測試客戶端重現；既有測試 test/test_setup_wizard_one_shot.py 34 項全過。
• DEV 資料庫唯讀查證（2026-09-25 11:30 +08，全程 BEGIN READ ONLY … ROLLBACK）：開通狀態、各公司使用者數、users 表的約束與索引。
• 打折處：U3-1 沒有對正在運行的服務實測（本機 BE 當時未啟動），是用同一支函式＋Flask 測試客戶端模擬；U3-2 的並發窗口是讀碼＋查約束推論，沒有實際並發打兩個請求。