I2 檢查結果：主專案的「意見回饋」功能

檢查日期 2026-09-09｜耗時 2 小時 16 分｜對應卡片 CM-1614

六棒裡最嚴重的一棒。 找到兩件事：資料庫密碼被寫進 249 個文件裡（其中一份還附上完整的連線指令），以及意見回饋的六個功能有五個沒有檢查權限——任何員工都能刪掉別人的回饋。

「意見回饋」是使用者在系統裡回報問題的功能。送出後，系統會：

1. 存進自己的資料庫
2. 如果管理員有開啟整合，還會拿公司的權杖去 GitHub／GitLab 開一張真的問題單
3. 使用者上傳的附件也一起送過去

這一棒檢查主專案這邊的 31 個檔案——誰能用這些功能、輸入的東西怎麼流出去。

問題 1：資料庫密碼散在 249 個文件裡（唯一的「高」）

白話：資料庫的管理員密碼，被寫進了 249 個會跟著程式碼一起散出去的文件裡。而且其中一份，把連線需要的所有資訊湊在一起：

# docs/analysis/2026-05-28-poc-db-migration-plan.md 第 71-73 行
export PGPASSWORD=<密碼>
PSQL="psql -h 192.168.50.189 -p 25432 -U cmmgr -d guidant_ai_poc ..."
#          ↑主機          ↑埠號    ↑帳號  ↑資料庫名

主機、埠號、帳號、資料庫名、密碼——五樣齊全，複製貼上就能連。

而 cmmgr 這個帳號的權限是「繞過所有客戶隔離」，也就是說連進去之後，所有客戶的資料都看得到、改得動。指向的那台機器是 POC，依專案規定「等同正式環境、對外 demo、客戶會試玩」。

首腦自己驗證的數字（不是採信報告）：

資料庫密碼   最新版 249 個檔 / 已推上遠端的主線 248 個檔
Redis 密碼   最新版 249 個檔 / 已推上遠端的主線 248 個檔   ← 和資料庫密碼是同一組字串

報告沒強調、但很重要的一點：Redis 和資料庫用的是同一組密碼。

這 249 個檔是什麼？為什麼會有？

全部是文件，沒有一支是會跑的程式碼：

根因：密碼總共出現 2,011 行，九成以上長這樣：

881 行   "command": "PGPASSWORD='<密碼>...
173 行   PGPASSWORD='<密碼>...
 38 行   **Bash**(command=PGPASSWORD='<密碼>...

不是有人故意把密碼寫進文件，是「工作過程被完整記錄下來」的副作用——每次要查資料庫打的指令，連同密碼被寫進對話紀錄，對話紀錄再依規定進版控；實作計畫和交接文件也照抄同樣的指令當成「怎麼跑」的說明。

🔴 這個機制已經是第三次了

1. 2026-09-08 .env.test 事件——四把 API 金鑰進版控，已撤銷重發
2. FR-079——登入憑證簽章金鑰散在 30 個檔
3. 這次——資料庫／Redis 密碼散在 249 個檔

所以只清檔案是治標。 修正卡 CM-1629 要求先做治本：改用 ~/.pgpass（psql 原生支援，指令裡就不必出現密碼）、對話紀錄歸檔前先遮罩，再清檔案。否則下次還會再長出來。

怎麼修：詳見 CM-1629。要注意的是換密碼這件事——DEV 和基線庫可以規劃，但 STG／POC 屬於環境異動，依專案鐵律要決策者當次明確指示才可以動。

問題 2、3：意見回饋的六個功能，只有一個檢查權限

白話：意見回饋有六個功能。只有「匯出」那個會檢查你有沒有權限，其他五個任何登入者都能用。 而且修改和刪除從來不檢查那筆資料是不是你的。

首腦逐條打開檔案核對：

api/feedback/routes/feedback_route.py

第 24 行  列表  只有「要登入」          ← 只有這個
第 42 行  讀取  只有「要登入」
第 50 行  新增  只有「要登入」
第 67 行  修改  只有「要登入」
第 85 行  刪除  只有「要登入」
第 95 行  刪附件 只有「要登入」
第 104 行 匯出  要登入 ＋ 要有「匯出」權限   ← 只有匯出有檢查權限

同一支檔案裡就有反例——這證明「這裡本來就該有權限檢查」不是猜測。

再往下追一層：

app/feedback/service/feedback_service.py

第 196 行  update_feedback(uid, ..., user_login_name=None)   ← 有收到「誰在操作」
第 233 行      feedback_issue.updated_user = user_login_name  ← 但只拿去填「最後修改人」欄位
第 239 行  delete_feedback(uid, login_user_name)            ← 有收到「誰在操作」

整支檔案沒有任何一行，拿這個人的身分去跟「建立者」比對。

攻擊情境很簡單：一個普通員工登入 → 打列表拿到別人的回饋編號 → 送出刪除請求 → 對方的回饋沒了，連帶關閉了 GitHub 上的問題單，而稽核紀錄記的是「這個員工合法操作」。

這是本專案第三次犯同樣的錯：CM-1585、CM-1589（都已修完）、FR-079 的公告功能（後已修，FR-114.1-5a）。修法可以直接抄 CM-1589。

問題 4、5、6：三把金鑰外洩，但性質不同

三把都是被寫進對話紀錄的（和問題 1 同一個根因），但處置方式不一樣：

這個對比很重要：同樣是「金鑰外洩」，問題 6 只影響我們自己的開發機，問題 4 卻影響所有客戶。判斷嚴重度時，第一個要問的是「客戶用的是不是同一把」。

「這十條是真的嗎」→ ✅ 可信度是六棒最高的

這是六棒裡唯一拿到完整 verified 標記的一棒。 十條發現每一條都經過三個獨立檢查員投票、三票全過，30 票全數投出、沒有漏投、沒有中斷。

而且檢查員主動把四條降級了（原本研究員判「高」的被降成「中」）——這代表他們真的在做對抗性判斷，不是橡皮圖章。

首腦也沒有只採信工具：

• 問題 1 的 249 個檔是自己數的（與報告吻合），還多發現「Redis 和資料庫共用同一組密碼」
• 問題 2、3 的六條功能守門形狀是自己打開檔案看的
• 249 個檔的來源分類是自己統計的

「是不是只有這十條」→ ❌ 不可信，有兩層原因

第一層：這是快篩模式，沒有全面盤點、沒有威脅建模。

第二層（這棒特有的）：五條「範圍外」的發現，不代表那些地方被檢查過。 那五條是「密鑰專項掃描」順手撈到的，而 docs/、scripts/ 這兩個目錄從來不是這次的檢查目標。也就是說，那兩處等於沒檢查過。