O2 檢查結果：資源庫、公版範本、匯出

檢查日期 2026-09-21｜掃描耗時 3 小時 0 分｜對應卡片 CM-2002

派工時預判的那支「整支檔沒有任何權限檢查」的 530 行程式，確實有洞，而且是這批到目前為止最嚴重的一條。

一家公司的管理員，可以改掉、甚至清空另一家公司（或原廠公版）合規範本的控制項清單，並把該範本底下所有「我們公司怎麼做到這條」的文字記錄整批刪除。系統裡明明已經有一支專門防這件事的警衛程式，而且它的說明還寫明了「不能只靠資料庫擋」——但這條路徑沒有叫它。

另外還有一條高風險：一組正在用的資料庫帳號密碼，被完整寫死在一支受版控的腳本裡（主機、埠號、資料庫名、帳號、密碼五樣齊全）。

三塊功能，共 11 支檔、1,772 行：

• 資源庫：客戶自己建的合規範本庫（選一套框架 → 系統複製一份控制項目錄給你 → 你勾選哪些控制項適用）
• 公版範本：原廠預先做好、所有客戶都看得到的範本
• 匯出：把系統安全計畫輸出成 Word／PDF／ODT，其中包含整批唯一一支會去呼叫外部程式（LibreOffice）的檔

選這一棒先掃，是因為派工前已經 grep 確認 resource_library_app_service.py 這支 530 行的檔整檔找不到任何一個權限檢查關鍵字，而且裡面有 9 段手寫 SQL。結果證實這個預判是對的。

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

• 問題 1（改範本適用控制項不查歸屬）＝M11 第 5 條，✅ 已修（CM-2178，commit abf1cf8a4；CM-2040 60015232f，1.21.0 出貨）。
• 問題 2（資料庫帳密寫死）：✅ 已修（CM-2049，commit 5d4c14221）。
• 問題 3（建資源庫無權限檢查）＝M11 第 13 條，✅ 已修（CM-2179，commit 94275d72f，1.21.0 出貨）。
• 問題 4（Word 匯出未跳脫）＝M11 第 18 條，✅ 已修（CM-2055，commit f85a82edb，1.21.0 出貨）。
• 問題 5、6（Google 密鑰、雲端權杖加密金鑰）：✅ 已修（CM-2051，commit ccbb27148；原作廢卡 CM-1631）。
• 問題 7、8（AI 金鑰、簽章金鑰）：✅ 已修（CM-2048，commit e8e134a4e；原作廢卡 CM-1607）。

一到四號是這棒範圍內的。五到八號是掃描工具的「祕密金鑰搜查」順手在整個 repo 撿到的——它們是真的（每一條的檔案數都實際 git grep 數過），但那些目錄不是這次的掃描目標，不能因為只找到這四條就認為 docs/ 乾淨。這四條與 FR-081 的 I2 報告、FR-113 的 O1 報告高度重疊，是同一批舊帳。

問題 1：改別人家的範本（唯一的新高風險）

白話：合規範本就是「這套框架裡，哪些控制項我們公司要做」的清單，底下還掛著每一條的實作說明。範本有三種身分：

• 自己家的（TENANT）——你建的，你自己用
• 母公司分享下來的（SHARED）——集團母公司做好給子公司參考的，子公司看得到但不該改
• 原廠公版（SYSTEM）——我們出廠附的，所有客戶都看得到，誰都不該改

編輯範本的功能長這樣：

PUT /module-frame/<哪一份範本>     body: { "include_controls": [...] }

送出後系統會做三件事：更新這份範本的控制項清單、把被拿掉的控制項底下的實作記錄整批刪除、替新加的控制項建流程範本。

問題在於：這段程式從頭到尾沒有問過一句「這份範本是不是你家的」。

為什麼資料庫沒擋下來

系統其實有兩層防護，這次兩層同時失效，而且失效的原因彼此獨立：

第一層（資料庫層）：compliance.module_frames 這張表有設「不准改別人家的、不准改公版」的規則。但這次的請求只送了控制項清單、沒有改到這張表上的任何欄位，所以程式根本沒有對這張表發出任何更新指令——沒發指令，規則就沒有機會觸發。而真正被改被刪的那三張表（oscal.profile_imports、oscal.ssp_implemented_requirements、oscal.catalog_control_parts）根本沒有設這層防護。

這點是實際數過的，不是推論：

# 整個 oscal schema 只有 5 張表有這層防護，這三張都不在裡面
$ grep -c "ALTER TABLE oscal.profile_imports ENABLE ROW LEVEL SECURITY" scripts/init/02-schema.sql
0
$ grep -c "ALTER TABLE oscal.ssp_implemented_requirements ENABLE ROW LEVEL SECURITY" scripts/init/02-schema.sql
0
$ grep -c "ALTER TABLE oscal.catalog_control_parts ENABLE ROW LEVEL SECURITY" scripts/init/02-schema.sql
0

第二層（程式層）：系統裡已經有一支專門擋這件事的警衛程式——common/authz/sharing.py 的 assert_scope_writable。它的說明文字甚至直接寫明了為什麼不能只靠資料庫：

「RLS 的 update policy 判準是『資料租戶在我的 allowed path 內』，而母租戶的 allowed path 涵蓋整個子樹⋯⋯所以這一刀要顯式切在『作用租戶＝資源租戶』上。」

問題是它只有在「使用者要改範本的分享身分」時才會被叫到：

# app/module_frame/service/module_frame_service.py:110-118
new_scope = payload.get("scope")
if new_scope is not None and new_scope != mf.scope:
    assert_scope_writable(mf.tenant_id, new_scope)   # ← 警衛只站在這個 if 裡面
    mf.scope = new_scope
self.module_frame_domain_service.update_module_frame(mf, locale)
# 適用控制項增減 → profile + IR 同步
if payload.get("include_controls") is not None and ...:
    self._resource_library_app_service.update_applicable_controls(   # ← 這條路沒有警衛
        uid, payload["include_controls"], user)

只送控制項清單、不送分享身分，就完全繞過警衛。

攻擊怎麼進行

1. 攻擊者是自己公司的管理員——這是一般客戶就有的角色（scripts/init/04-seed-core.sql 預設就配了範本編輯權）。
2. 他打開資源庫列表，看到原廠公版範本（每家公司都看得到，這是設計如此）或母公司分享下來的範本，抄下編號。
3. 他送出 PUT /module-frame/<別人的範本編號>，內容只放 {"include_controls": []}。
4. 網址入口的權限檢查問的是「你有沒有編輯範本的權限」——他在自己公司有，通過。
5. 資料庫那層因為沒有欄位變動，連觸發的機會都沒有。
6. 那份範本的控制項清單被清空，底下所有實作記錄被刪除（說明文字因為資料庫的連鎖刪除設定一起消失）。

打原廠公版的話，影響的是所有客戶。

怎麼修

在 update_applicable_controls 動手寫任何東西之前，先把範本那筆重新撈出來，明確擋兩件事：

• 身分是原廠公版（SYSTEM）→ 直接拒絕
• 範本的所屬公司跟呼叫者的公司不同 → 直接拒絕

做法照抄 common/authz/sharing.py 既有的判斷方式即可。不要想著靠資料庫補——那三張表沒有防護，而且它們本來就設計成「跟著範本走」，補防護是第二道保險、不是這條的解法。

同一條路徑上的 _init_ao_workflows（處理新增控制項那半邊）需要同一道檢查。

問題 2：資料庫帳密寫死在腳本裡

白話：一支產生資料庫結構文件的腳本，把連資料庫需要的五樣東西全部打在程式碼裡：

# docs/system-design/scripts/generate_db_schema_docx.py:33-34
DB_CONN = dict(host="192.168.50.189", port=25432, dbname="guidant_ai_poc",
               user="cm_app", password=<密碼字面值>)

主機、埠號、資料庫名、帳號、密碼——複製貼上就能連。 指向的是 POC 機器，依專案規定「等同正式環境、對外 demo、客戶會試玩」。

更麻煩的是同一組密碼字串的散布範圍——實際數過：

$ git grep -l '<見 .env>' | wc -l
249

249 個受版控檔案，其中不少配的是 cmmgr 這個會繞過「每家公司只看自己資料」隔離機制的帳號。

這條與 FR-081 的 I2 報告第 1 條、FR-113 的 O1 報告第 4 條是同一件事，不是新發現，但這次是從另一條路徑再次撞到——代表它還沒被處理。

怎麼修：腳本改成跟主程式一樣從環境變數讀（config/config_loader.py 已經有現成的 DB_HOST／DB_USER／DB_PASSWORD），把 188／189 上 cm_app 與 cmmgr 的密碼換掉，然後清掉那 249 個檔裡的字串。注意：單純在後面的 commit 把檔案刪掉沒用——舊的 commit 裡還讀得到。

問題 3：建資源庫不檢查權限

白話：建立資源庫的入口只驗「有沒有登入」，沒有問「你有沒有建的權限」。而隔壁那支做同樣事情的入口（ModuleFrameRoute.post）是有要求權限的。

這個檔案裡有一段註解解釋為什麼放開：建立時一定會綁呼叫者自己的公司、不會碰到原廠公版，所以「一般登入者即可」。

這個理由對了一半——就「會不會動到別人家的資料」而言確實成立。但它沒回答兩件事：

1. 公司內部哪些角色該能建？ 唯讀帳號、一般稽核員是不是也該能建範本庫？
2. 每次呼叫的代價有多大？ 建一次資源庫 = 複製一整套框架控制項目錄 + 每個查核項目各產一張 BPMN 流程範本。這不是一筆小寫入。而系統沒有裝任何流量限制，所以重複呼叫就是用很小的代價把資料庫灌大。

怎麼修：補上跟隔壁入口一樣的權限要求。Excel 匯入、Word 匯入那兩條也會建資源庫，三個入口要一致，不然補了這個還是有其他路可以進來。

問題 4：匯出的 Word 檔可以被動手腳

白話：Word 檔（.docx）內部其實是一種標記語言寫的文字檔。系統匯出時，會把使用者填的「系統名稱」「系統描述」「網路架構」「資料流」等欄位填進 Word 範本。

填進去的時候沒有做「跳脫處理」——也就是沒有把使用者輸入裡的特殊符號轉成安全形式。所以如果有人在系統描述裡填入一段看起來像 Word 內部指令的文字，它就會被 Word 當成真的指令執行，而不是顯示成文字。

技術上的位置：

# app/oscal/service/export/ssp_docx_generator.py:60
tpl.render(context)          # ← 這裡少了 autoescape=True

用的那個套件（docxtpl）預設是關閉跳脫處理的，要自己明確打開。

可以造成什麼：

• 偽造段落——在匯出的稽核文件裡插入稽核員根本沒寫過的實作說明或標題
• 藏外部指令——Word 有一種「欄位指令」可以叫閱讀者的 Word 去抓外部檔案。閱讀者一開啟文件就會觸發

為什麼這條重要：匯出的 SSP 就是要交出去給稽核方的正式文件。內容能被動手腳，等於證據本身不可信。

怎麼修：tpl.render(context, autoescape=True)，一行。或者把每個從資料來的字串先包成套件提供的安全型別。在這個出口修比在每個輸入端擋好——因為 Word、PDF、ODT 三條路都走這同一個出口。

問題 5～8：舊憑證還躺在對話紀錄裡

這四條是掃描工具的祕密金鑰搜查在整個 repo 撿到的，不是這棒的掃描範圍，但既然撿到就照實報。每一條的檔案數都實際數過：

這四條跟 FR-081 的 I2 報告第 4～6 條、FR-113 的 O1 報告第 3 條指的是同一批東西。 從三個不同方向重複撞到同一件事，本身就是個訊號：這批舊帳還在原地。

特別注意前兩條：它們不在現有的 CM-1607／CM-1608 修正清單裡。前兩棒的報告雖然提過雲端硬碟相關的金鑰，但既有工單列的是 AI 金鑰與資料庫密碼。如果照現有工單做完，這兩把還是會留著。

問題 6 和問題 2 可以串起來：拿問題 2 的資料庫密碼把客戶的雲端硬碟權杖撈出來，再用問題 6 的加密金鑰解開，就能直接讀客戶的雲端硬碟內容。兩條單看都是「中」，串起來的實際後果比任何一條單獨都嚴重。

派工卡片點名要看的幾件事裡，有兩件掃描沒有給出結論，要據實說明：

一、ssp_libreoffice_converter.py 的暫存檔與多人同時匯出。卡片特別點名這支是整批唯一會呼叫外部程式的檔，問了「檔名會不會被使用者控制」「多人同時匯出會不會互相踩到」。掃描讀了這支檔但沒有提出任何發現——可能是真的沒問題，也可能是這一輪的快速檔沒追到那個深度。不能當成「已確認安全」，要確認得另外開檔細讀。

二、9 段手寫 SQL 的 SQL injection 檢查。研究員從 update_applicable_controls 這一段找到了問題 1，但沒有逐段回報其餘 8 段的參數綁定狀況。從問題 1 的描述看，那幾段用的是綁定參數（:u、:ids、:sid）而不是字串拼接，這是安全的寫法；但這是從報告內容推得的，不是研究員逐段核過的結論。

三、module_frame_template_ssp_route.py（38 行，零守門）通到哪裡。掃描沒有針對這支提出發現。

如果這三件會影響後續決策，需要另外開一棒針對性地讀。

⚠️ 沒有任何程式碼被執行過。 沒有跑測試、沒有實際發動攻擊、沒有驗證過概念驗證程式。所有結論都來自讀程式碼。

本報告所有 8 條發現，runner 都自己開檔核對過，不是只採信面板：問題 1 核了那段程式、警衛程式的說明、module_frame_service.py 的呼叫條件、三張表沒有防護（grep -c 各回 0）、以及入口的權限要求；問題 2 核了第 34 行字面值與 249 個檔的數字；問題 3 核了兩支入口的權限裝飾器對比；問題 4 核了第 60 行；問題 5～8 各以 git grep -l 數過檔案數。

1. 問題 1 應優先處理——這是本批目前唯一的新高風險，修法明確（既有警衛程式抄過來），影響面是「客戶資料可被別的客戶破壞」。
2. 問題 5、6 要補進既有的憑證清理工單（CM-1607／CM-1608）——它們現在不在清單上，照現有工單做完還是會留著。問題 6 與問題 2 串起來可以直接讀到客戶的雲端硬碟內容。
3. 問題 3、4 可以併一張卡——都是單點修改（補一個權限裝飾器、加一個參數），風險中等但修起來很便宜。
4. 考慮補一棒：上面「這棒沒有回答的事」那三項，特別是 LibreOffice 那支（整批唯一呼叫外部程式的地方）。
5. 問題 2、7、8 交給首腦判斷——與前兩棒重疊，應該併進既有項次而不是另計。