A1 檢查結果：AI 聊天機器人

檢查日期 2026-09-10｜耗時 65 分鐘｜對應卡片 CM-1637

聊天功能沒有任何長度或次數限制——任何一個普通員工帳號，開四到八個連線就能讓整個系統停止回應，或者無限次呼叫把公司的 AI 額度燒光。

系統裡有一個 AI 聊天機器人：使用者打字問問題，系統把訊息原封不動送給 Anthropic（Claude），拿回覆顯示給使用者。對話記錄存在 Redis，一小時沒動就自動清掉。

這一棒檢查這個套件的 13 個檔（632 行）——能不能看到別人的對話、能不能塞東西進別人的記錄、能不能無限次呼叫把公司的錢燒光。

這支跟前面掃過的都不一樣：它是 25 支套件裡唯一會把使用者打的字送到公司網路外面、而且每次呼叫直接產生金錢成本的。

只找到這 1 條。 另外三條候選被檢查員否決（理由見下）。

問題 1：沒有長度上限，也沒有次數限制

白話：使用者在聊天框打什麼、打多長，系統完全不管，直接送給 Claude。也沒有「一個人一分鐘最多問幾次」的限制。

為什麼「整個產品停止回應」比「燒錢」更嚴重——檢查員把這條鏈追得很完整：

主專案跑 4 個同步工作程序（main.py:258）
    ↓ 一個工作程序一次只能處理一個請求
呼叫 Claude 本來就慢
    ↓ 而 Anthropic 套件的預設逾時是 10 分鐘，這個套件從來沒改過
工作程序被佔住
    ↓ 系統要等 120 秒才會強制砍掉卡住的工作程序
4～8 個並發請求 → 全部工作程序被佔滿
    ↓
整個產品的所有功能都停止回應，不只聊天

單則訊息能多大：主專案的全站請求上限是 50MB（CM-1587 訂的）。這個上限擋得到聊天訊息，但 50MB 對一則聊天訊息來說等於沒擋。

在哪裡：

# jedi_ai_bot/api/ai_bot_route.py
第 57 行  message = (payload.get('message') or '').strip()   ← 只去頭尾空白
第 60 行  if not message: return ...400                       ← 只檢查空字串
第 64 行  reply = ctx.service.chat(ctx.current_user_id(), session_id, message)
          ↑ 沒有長度檢查、沒有次數限制，直接送出去

檢查員做了額外查證：他們去主專案和 nginx 設定裡找有沒有其他層擋著——沒有找到任何頻率限制。

怎麼修（工具給的建議很具體，首腦認同）：

重點 ①（我開卡時標為「本棒核心」）：對話記錄能不能跨到別人那裡？→ ❌ 不能

我原本的擔心：對話記錄的 Redis 儲存位置是 chat_history:{使用者編號}:{對話編號}，而對話編號完全由呼叫端自己給，只做了去空白處理（ai_bot_route.py:58）。Redis 的儲存位置沒有跳脫機制，冒號在這裡是有意義的分隔符——所以我擔心有人塞 x:chat_history:999 之類的東西跨到別人的記錄。

實際查證結果：跨不過去。

儲存位置 = chat_history:{使用者編號}:{對話編號}
                        ↑ 這一段由伺服器填（api/ai/__init__.py:34 的 get_user_context().id）

攻擊者（編號 5）能產生的位置一律是   chat_history:5:<任意內容>
想碰的目標（編號 9）的位置是         chat_history:9:default

第一段是伺服器填的、而且是數字不含冒號 → 前綴偽造不了

我原本的擔心是錯的。

但這條仍值得記：這個保護完全依賴「使用者編號由伺服器填、且排在最前面」。哪天有人把編號改成呼叫端可控、或把順序調成對話編號在前，這道保護就沒了。建議在程式碼加一行註解說明為什麼順序不能改。

重點 ④：缺少認證設定時會怎樣？→ ✅ 會炸，是安全的

背景：這支套件把認證設定做成「必填欄位」，但沒有任何明確的檢查程式碼（首腦已確認整支 plugin.py 沒有 raise，也沒有建構後驗證）。這跟 jedi-issue 那支不同——那支會直接報錯拒絕掛載。

實測結果：

所以結果是安全的——系統啟動時就會炸，不會變成「不用登入就能用」的端點。

不如 jedi-issue 那支友善（那支會給明確的中文錯誤訊息說「拒絕掛載，因為會讓端點變公開」），但安全性上沒有洞。這一項不開卡。

「這條是真的嗎」→ ✅ 可信

這是六個檢查案以來 stamp 最乾淨的一次：verified，而且連「拒收原因」欄位都是空的（前一個案子六棒有五棒帶著 findings-refused 標記）。

三個獨立檢查員對 3 條候選各投一票，9 票全數投出、沒有漏投、沒有中斷。F1 是 3 票全過。

檢查員還做了額外查證：他們去主專案和 nginx 設定裡找有沒有頻率限制，確認沒有——這不是讀套件就能知道的，是主動追出去查的。

「是不是只有這一條」→ ❌ 不可信

快篩模式。13 個檔裡有 4 個是空的，實際有內容的 9 個。工具也沒有留下逐檔閱讀紀錄。

而且首腦補查證明了工具沒照卡片的重點清單走——我點名要查的兩項（對話記錄能不能跨人、缺認證設定會怎樣）工具一項都沒答，是首腦自己查的。兩項結論都是好消息，但那不是工具給的。

📌 一個開卡時的疏失（首腦自陳）

卡片寫「檔數 13」，工具報告寫 14。查了原因：工具算全部受版控檔，我給的驗證指令只算 .py 檔，差的是 harness/docker-compose.yml。

掃描範圍沒問題，反而多掃一個檔（那個檔也確實該掃，它可能有寫死的憑證）。但驗證指令的口徑該跟工具一致，記錄下來給下一棒參考。