O3b 檢查結果：Excel 內容解析

檢查日期 2026-09-21｜掃描耗時 1 小時 44 分｜對應卡片 CM-2010

掃完了，範圍內找到 2 個中風險，最嚴重的是「一個小檔可以把整個產品打停」——而且有兩種不同的打法。

第一種是派工時就點名的：Excel 檔讀進來時整份塞進記憶體，一個壓縮過的小檔解開後可以吃光記憶體，落地版容器被系統殺掉、產品停擺。這條 O3a 已經順資料流撞到並登記在總表第 124 項，本棒是在它自己的範圍裡把它完整看過一遍，不另計。

第二種是本棒新找到的，比第一種更便宜：檔案裡「說明」分頁 B1 那格版本號，系統拿一段比對規則去讀它，但那格內容沒有長度上限、比對規則也沒寫好——填一百萬個數字進去（壓縮後只有幾 KB），系統會卡在那裡算到逾時被砍。四個這種請求就能讓整個網站沒反應，而且這一步跑在版本檢查之前，所以連一份合法的範本都不需要。

派工時點名要追的另外兩條，答案是「沒有」：公式注入這半邊確實沒擋（進來的字元原樣存下），但那只是半條路，另外半邊在匯出線（O2／O4 已登記）；組裝資料時沒有拿檔案裡的編號當系統內編號用。

⚠️ 另外，掃描工具的「找寫死密碼」那一輪撈到 4 條範圍外的憑證外洩，全部是既有工單已涵蓋的老問題，不另計（對照見文末）。

使用者傳上來的 Excel 檔，要把裡面九張工作表的每一格讀出來、轉成系統看得懂的資料。這一棒掃的就是**「讀」這個動作本身**——一份動過手腳的 Excel 傳上來，能對系統做什麼。共 7 支檔、1,047 行。

不含「誰能傳、誰能按確認」那條權限路（那是 O3a，已掃完），也不含兩條匯入線共用的接縫檔（那是 O9）。

本棒的題目從頭到尾是惡意檔案，不是權限——解析器是純函式，不碰資料庫也不碰登入狀態。

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

• 問題 1（版本號比對卡死）＝M11 第 25 條，✅ 已修（CM-2181，commit 48638cbdb，1.21.0 出貨）。
• 問題 2（壓縮炸彈）＝M11 第 23 條，✅ 已修（CM-2181，1.21.0 出貨）。
• 範圍外四條憑證舊帳：原卡 CM-1629／CM-1607／CM-1631 已作廢，實際由 CM-2049（資料庫密碼）、CM-2048（簽章金鑰）、CM-2051（Google 密鑰與雲端權杖加密金鑰）修掉，均 ✅ 已修。

問題 1：版本號那一格可以讓網站卡死（中，本棒新找到）

白話：系統要知道使用者傳的是第幾版的範本，作法是去讀「說明」分頁第 1 列 B 欄那一格，用一段規則把 v4.0.0 這種樣子的字撈出來。

問題在兩件事湊在一起：

1. 那一格的內容沒有長度上限——str(cell_val) 直接整個拿去比對，使用者填多長就多長。
2. 比對規則沒有綁定開頭——寫的是「找出任何位置的 v?數字.數字.數字」。遇到一長串只有數字、沒有小數點的字，比對引擎會從第 1 個字元開始貪心地往後掃、失敗，再從第 2 個字元開始掃、再失敗⋯⋯每個起點掃一遍。一百萬個數字就是一百萬次、每次掃一百萬格。

實際的程式是這樣：

# app/oscal/service/excel_parser/parser.py:140-153
cell_val = ws.cell(row=_INTRO_VERSION_ROW, column=_INTRO_VERSION_COL).value
if not cell_val:
    raise BadRequestError(...)
return _extract_semver(str(cell_val))       # ← 沒有長度上限

_SEMVER_PATTERN = _re.compile(r"v?\d+\.\d+\.\d+")   # ← 沒有綁定開頭

def _extract_semver(text: str) -> str:
    m = _SEMVER_PATTERN.search(text)
    return m.group(0) if m else text.strip()

攻擊怎麼進行：做一份最小的 Excel，只要有一張叫「說明」或「00_說明」的分頁，B1 格填一百萬個數字。壓縮後只有幾 KB，遠低於 10MB 的上限。傳到 /api/1.0/ssp-excel-imports/parse，開檔很快就過，讀到那一格就卡住。

最關鍵的一點：這一步跑在版本檢查（is_supported）之前，所以攻擊者連一份版本號合法的範本都不需要準備——隨便一個數字串就行。

⚠️ runner 開檔核對（事實陳述）：version_check.py:35 裡的 _VERSION_RE = re.compile(r"^v?(\d+)\.(\d+)\.(\d+)$") 是綁定開頭與結尾的，它沒有這個問題。出問題的是 parser.py:151 這第二份、沒綁定的副本——同一件事在兩個地方各寫了一次，一份寫對、一份寫錯。

怎麼修：兩件事各做一半就夠——① 讀那一格時先截斷，str(cell_val)[:200]；② 把規則的數字位數限制住，改成 v?\d{1,5}\.\d{1,5}\.\d{1,5}。更乾淨的作法是直接刪掉 parser.py 這一份，改用 version_check.py 裡已經寫對的那一份（符合 CLAUDE.md「先查既有能力、不要重複造輪子」）。

問題 2：壓縮炸彈——整份塞進記憶體（中，O3a 已登記，總表第 124 項）

白話：Excel 檔本質上是壓縮檔。系統在上傳時量的是壓縮後的大小（10MB 以內就放行），但讀檔時用的是「整份載入記憶體」模式。一份刻意做的檔案壓縮後 2MB、解開後幾 GB，記憶體就被吃光了。

# app/oscal/service/excel_parser/parser.py:41-42
# data_only=True：拿 Excel 開檔重算後的 cached value (VLOOKUP / INDEX-MATCH 結果)
wb = load_workbook(file_path, data_only=True, read_only=False)

read_only=False 就是「整份載入」；read_only=True 才是逐列串流讀取。

為什麼落地版特別嚴重：docker/production/docker-compose.yml 沒有給 guidant-api 設記憶體上限，而落地版是單一容器——被系統殺掉就是整個產品停擺。容器設定是自動重啟，但攻擊可以立刻再打一次。

⚠️ runner 開檔核對（事實陳述）：_iter_data_rows（sheet_handlers.py:97-101）本來就是一列一列往下讀的，沒有任何地方需要隨機跳著存取儲存格。也就是說改成串流模式不會少任何功能。

怎麼修：兩層都補——① 呼叫 load_workbook 之前先用 zipfile.ZipFile 打開，檢查解壓後總大小、檔案筆數、每個檔案的壓縮比。專案裡已經有一模一樣的東西：core/plugins/detection.py 的 profile_extracted_max_mb / profile_max_entries / profile_max_ratio，直接重用、不要再寫第二套；② 改成 read_only=True。

與 O3a 的關係：O3a 順著資料流撞到這條並已登記（總表第 124 項）。本棒是在這支檔自己的範圍裡把它完整看過一遍，不另開項次，但補上了兩件 O3a 沒查的事實：read_only=True 改過去不會少功能、專案裡已有可重用的解壓檢查。

掃描工具在設定了 attack-surface 的情況下會附帶跑一輪「找寫死的密碼」，掃的是整個 repo 不限本棒範圍。撈到四條，全部是已知的老問題：

⚠️ 其中兩條（登入簽章金鑰、雲端硬碟密鑰）工具明確查證過「現在的 .env 裡還是同一個值」——這不是歷史殘留，是現役憑證。O2 已經指出過那條串連：拿資料庫密碼撈出客戶的雲端硬碟權杖，再用加密金鑰解開，就能直接讀客戶雲端硬碟裡的檔案。本棒再次確認這四把都沒換，排優先順序時值得重看一次。

這兩條我自己開檔核對過，是事實陳述不是推論：

• 問題 1：parser.py:140-153 打開就是那樣寫的——str(cell_val) 沒有截斷、_SEMVER_PATTERN 沒有 ^$。而 version_check.py:35 的那一份有 ^$。兩份規則並存、一份寫錯，這是看著程式碼直接讀出來的。唯一沒做的是實際計時（本棒只掃不跑），所以「一百萬個數字要跑多久」是依規則形狀推算的，不是量出來的。三位審查員有兩位確認（2/3）。
• 問題 2：parser.py:42 的 read_only=False 是字面寫著的；sheet_handlers.py:97-101 的 _iter_data_rows 是逐列讀，所以「改串流不會少功能」是看程式碼得出的。三位審查員全數確認（3/3），且 O3a 已獨立報過同一條。

工具給的、我沒有逐條開檔核對的：四條範圍外的憑證外洩。工具聲稱它做了「不印出內容的逐字比對」確認這些值仍在 .env 裡，我沒有重做這個比對——但它們全部落在既有工單內，不影響本棒結論。

這一棒沒有執行任何程式碼。所有結論都來自讀程式碼，沒有真的發動過攻擊，也沒有跑過概念驗證。

面板調整過一次嚴重度：登入簽章金鑰那條研究員報「高」，三位審查員投出「中、中、高」，工具依規則降為中。本報告照實記錄降級後的結果，不還原。

兩條 2:1 的是哪兩條：問題 1（版本號卡死）與雲端硬碟加密金鑰。依工具規則，非全票通過的發現可信度上限為「中」。

本棒是 Excel 這條線的最後一塊。 O3a（誰能傳、誰能確認）＋ O3b（傳進來的檔怎麼讀）合起來，整條 Excel 匯入路徑掃完了。

兩棒的病不同形狀，值得記一筆：O3a 是本 arc 那條主線——「有人守了一半」，三條去路守了兩條。O3b 不是，解析器這裡沒有守門可言，問題是**「使用者塞多少、系統讀多少」：沒有長度上限、沒有解壓後大小上限。前面五棒累積的「權限守一半」判準在這一棒用不上**，是另一類題目。

唯一與前面接得上的線索是公式注入：進來這端不擋（本棒確認）、出去那端也不擋（O2／O4 已報），進出都沒擋才是完整一條路——這是本 arc 第二次出現「同一塊地要兩端一起看」的形狀（第一次是 O5 補上「讀」那一面）。修匯出端的跳脫處理時，可以順手考慮在匯入端也中和掉開頭字元，做成兩層防護。