U7 檢查結果：任務入口與批次

檢查日期 2026-09-25｜對應卡片 CM-2158（母卡 CM-2152）｜檢查範圍 7 個檔案 1,908 行｜工具 run ID wf_14dcf3f9-ca2｜掃描版本 159a2fff（feature/review）

決策者點名的「批次完成把呼叫者當管理員」，寫在程式裡的那條預設走不到；真正的洞在隔壁：批次完成拿「網址上的專案」判斷你是不是管理員，卻不核對勾選的任務屬不屬於那個專案。 這跟本批其他五個入口是同一個病：只認網址專案，不認任務歸屬。

• 批次完成（卡片最重要的一條）：is_manager = True 這個預設值，只在「守門零件沒接上」或「網址沒帶專案編號」時才會生效。實際上零件有接，網址也一定帶專案編號，所以這條預設在正式路徑上走不到（第 59 項當年寫的「待核對」，核對結果是不成立）。但我手做實測（未經三人面板）發現另一個洞：你是專案 A 的管理員、又是專案 B 的旁觀者（viewer）時，網址填 A、勾選 B 的任務，系統就用「你是 A 的管理員」直接跳過「這張任務是不是指派給你」的逐筆檢查。DEV 上真的有這種身分組合的帳號。目前分支上這招換不到新能力，因為第 59 項的洞本來就讓 viewer 單筆完成任務；等修正分支（CM-2147）合回來，內層守門會擋住它。所以我建議不另計、併進第 59 項那張修正卡的驗收項。
• 批次匯入（卡片第二條，「任務編號誰給的」）：任務編號是呼叫者自己填在 Excel 或 JSON 裡的。「確認」那一步只查「這個任務存不存在」，不查「是不是這個計畫的」（第 156 項，工具 F3 這次再度 3:0 命中）。前兩步「上傳驗證」與「重新驗證」完全沒有身分檢查（第 158 項）。
• 🟠 新發現（中風險，runner 實測、未經面板）：「上傳驗證」那一步零守門，而且整份 Excel 直接展開成記憶體裡的物件。實測 9.8MB 的特製 Excel 檔，開檔花了 22 秒、記憶體衝到 1.46GB。同一家公司任何有專案模組的登入帳號都能打，連送幾份就能把服務撐爆。這是第 130／176 項「壓縮炸彈」的第五個入口，之前沒被記錄過。
• 工具報 8 條全部 3:0 通過：6 條中風險都是既有項目重現（第 45／155／156／157 項），淨新增 2 條低（匯出任務 Excel 沒過濾公式、批次完成通知信沒跳脫 HTML）。
• 「我的任務」與儀表板：查詢條件永遠是「登入者本人」，是從登入憑證取的，不是從請求內容取的。資料庫檢視表也開了隔離保護。不成立。

帶著前棒的形狀來看：U5／U6 的病是「背景工作用系統身分跑、沒核對專案歸屬」。U7 沒有背景工作，但同一個問題換了個入口出現：每個入口都只問「你是不是網址那個專案的人」，沒人問「你要動的這張任務是不是那個專案的」。

「任務」是稽核流程裡最小的工作單位（例如「上傳防火牆設定截圖」），掛在某個專案的某個控制項底下。這 7 支程式是任務的所有對外入口：

要回答的核心問題：任務編號是誰給的？系統有沒有核對這個編號屬於呼叫者有權限的專案？

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

• U7-1（匯入 Excel 壓縮炸彈）＝總表第 198 項，✅ 已修（CM-2203，commit eb4ff79cd／040c3c827，1.21.0 出貨）。
• U7-2（匯出 Excel 公式）＝總表第 199 項，✅ 已修（CM-2213，commit a5804a990／bde8f9d16，1.21.0 出貨）。
• U7-3（暱稱塞進通知信）＝總表第 200 項，✅ 已修（CM-2213，同上 commit，1.21.0 出貨）。
• U7-4（批次完成用網址專案角色）：併總表第 59 項（viewer 不可完成任務，該項 ✅ 已修）；U7-4 那條「逐筆用任務自己專案查角色」是否一併落地，查不到單獨記錄，保留待核。

1. 🔴 job_batch_complete_service.py:50-56「預設把呼叫者當管理員」——預設走不到；真正的缺口在第 58～62 行

先回答卡片的問題：不成立。 程式一開始設 is_manager = True，只有三個條件同時滿足才會去查真正的角色：守門零件有接、專案服務有接、網址有帶專案編號。我逐一核對：

• 兩個零件在 di_containers/flow_control/flow_control_containers.py:579-585 都有接。
• 網址是 /project/<project_uid>/jobs/batch-complete（套件 jedi-task-platform 的 routing.py:68），專案編號是網址的一段，不可能是空的。
• 唯一的呼叫點是套件的 job_batch_complete_route.py:31-38，永遠把 project_uid 傳進來。

所以「預設是管理員」那條路在正式環境走不到。它的問題在寫法：「零件沒接就放行」。將來有人改接線或加第二個呼叫點，就會默默變成全部放行。建議改成沒接就擋（修正分支上 job_import_service.py 已經這樣做）。

真正的缺口（U7-4，runner 實測）： 第 58 行用「網址上的專案」查你的角色。只要你在那個專案是管理員，第 62 行就把「逐筆核對指派」整段跳過。但勾選的任務編號是呼叫者自己填的，沒有任何一行核對它屬不屬於網址上的專案。

• DEV 唯讀查詢（2026-09-25 14:00 前後）：租戶 102 的 user 17 在專案 323 是管理員、在專案 642 是 viewer。642 有一張進行中的任務 70bba021… 指派給 user 19，不是 17。
• 手做實測：照 DEV 這組真實身分寫單元測試，直接呼叫批次完成服務，網址填 323、勾選 642 的任務：逐筆指派核對完全沒被呼叫，直接進入完成任務，回傳「成功 1 筆」。對照組把網址老實填 642：回 NO_PERMISSION。
• 為什麼目前換不到新能力：真正完成任務的 complete_job（workflow_execution_service.py:660）會再查一次「你是不是任務所屬專案的參與者」，任何角色都過。這就是第 59 項：viewer 本來就能從單筆完成的網址完成別人的任務。所以在目前分支，這招能做到的事，單筆入口早就做得到。
• 修正分支會怎樣：fix/security-b1 的 CM-2147 把 complete_job 內層改成「只有被指派人或管理員能完成」（app/flow_engine/service/job_operator_guard.py，拿任務自己的專案判斷）。合回來以後，這招會被內層擋下，錯誤會變成那一筆的失敗原因。批次那層的過濾仍然是假的，只是內層兜住了。
• 建議：不另計，併進第 59 項那張修正卡，驗收項加一條「A 管理員＋B viewer，網址填 A、勾 B 的任務，要被擋」。修法是逐筆用任務自己的專案查角色，不要用網址的。

2. job_import_service.py「匯入三步只有最後一步有守門」——成立（第 158 項），而且多一個炸彈入口

任務編號誰給的：「上傳驗證」從 Excel 的 A 欄讀，「重新驗證」和「確認」從前端送來的 JSON 讀，全部是呼叫者給的。

前兩步不會直接吐出別專案的任務內容，但能確認某個編號存不存在、屬不屬於某計畫，這正是第 156 項攻擊需要的材料。

新增（U7-1）：「上傳驗證」在零守門的狀態下，第 203 行 load_workbook(file, data_only=True) 把整份檔案展開成記憶體物件。唯一的大小檢查（:194，10MB）量的是壓縮後的大小。實測如下：

一個請求就佔住一個處理程序超過 20 秒、吃掉將近 1.5GB。預設四個處理程序同時被打，就是將近 6GB。落地版單一容器、沒設記憶體上限（第 130 項已查）。修正分支已把守門搬到開檔前（要是專案成員才能上傳），門檻變高，但開檔方式沒變，炸彈本身還在。

3. my_grc_jobs_query.py、flow_control_dashboard_repo_impl.py：WHERE 有沒有限定「是我的」——不成立

• 「我的任務」：my_grc_jobs_query.py:113-115 第一個條件永遠是 user_id == user_id，而這個 user_id 在 job_route.py:246 取自 get_user_context().id（登入憑證），請求內容改不到。project_uid、round_uid 等篩選只會在自己的任務裡再縮小。另一支 get_user_task_queue_by_sp 也一樣（flow_engine_route.py:184）。
• 資料庫這層：public.vw_user_job_queue 開了 security_invoker=true（DEV 唯讀查詢確認），代表查詢時會套用底下各張表的客戶隔離規則，不會用建立者的權限繞過。
• 輸入安全：關鍵字用 ilike 加參數綁定，沒有字串拼接 SQL；排序欄位走白名單（:174-182），不在名單裡的直接忽略；每頁筆數有上限（jedi_common 的 PagerSchema，MAX_PAGE_SIZE）。
• 儀表板：可見專案 = 自己是擁有者或任一層參與者的專案（:56-67、:110-121），user_id 同樣來自登入憑證。套件的儀表板路由把 is_admin 寫死成 False（dashboard_route.py:36），連管理員都只看自己參與的專案。原生 SQL（:188-214、:247-253）全部用參數綁定，而且只在「可見專案」清單裡查。

4. job_route.py：有沒有哪支方法沒走到 _require_manager——有兩支

修正分支（CM-2039、CM-2191）已補上查看、修改、刪除、清單四支，目前分支上都還開著。

5. 「有人守了一半」共通疑點逐條對照

工具交回 9 條候選，三人面板 27 票全投，8 條 3:0 通過、1 條 0:3 被否決。

F9 為什麼被否決、我怎麼看：面板三票一致認為，寫資料庫的錯誤不會走到這一行，所以吐不出 SQL 語句。我的實測也證實：except Exception 會把 str(e) 原樣放進回應（我在測試裡丟一個假的資料庫錯誤，回應就帶著 [SQL: ...]）。機制存在，但面板認為正常路徑上觸發不到，我同意不立項。修第 59 項時可以順手把 :117 改成固定錯誤碼。

F7 補充：CM-2189（895db0ef8，修正分支）修了範本下載那三支，沒修這支。我在修正分支查過 job_import_service.py，沒有任何公式中和。

F8 補充：暱稱本人可以隨意改（見第 150 項）。同一型寫法在範圍外還有兩處：workflow_execution_service.py:1219（每日待辦通知，塞收件人自己的暱稱，傷害較小）和 project_service.py:776（專案通知）。修的時候三處一起做。

• 「這幾條存在嗎」：工具那 8 條都經過三人面板完整投票（27 票全投、零漏投），驗證章 verified。卡片點名的四條是我逐支開檔回答的；U7-1 和 U7-4 是我手做實測，未經三人面板投票。
• 「只有這幾條嗎」：範圍 7 支我逐支通讀完。範圍外我讀了追下去需要的檔：job_service.py、job_batch_complete_query.py、job_import_lookup_query.py、workflow_execution_service.py 的完成任務段、common/authz/workflow.py、project.py，以及套件 jedi-task-platform 的四支路由。打折處：
  • 實測都是單元測試層直接呼叫服務，沒有起後端打真的 HTTP 請求（本機後端沒在跑）。
  • 炸彈實測是在本機用同一行 load_workbook 寫法開檔，沒有經過 gunicorn，也沒量多個處理程序並發的情形。
  • DEV 查詢是唯讀的，時間點 2026-09-25 14:00 前後；平行修正線可能改變資料。