寄信與通知（jedi-notification）

系統要通知人的時候——寄稽核提醒信、把流程事件推到聊天群組——走的都是這塊。它管三條通知管道：

---

檢視期間：2026-09-08（單日完成兩輪）｜範圍：48 個檔案（模組本體 30、主系統接線 18）｜共 2 輪

原始技術報告放在需求中心的 FR-078 站，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。

---

排序按風險，同風險的同一類排在一起。「出事會怎樣」那欄講的是業務影響——誰受影響、損失什麼，不是技術現象。

檢視時順手做密碼掃描撈到的四條

這四條跟寄信通知沒有關係——是檢視時順手做的密碼掃描撈到的。列在這裡是為了完整。

---

問題是什麼

郵件設定頁有一個「寄測試信」按鈕。使用者不改密碼欄位的時候，系統會從資料庫撈出存著的那組真密碼，配上使用者這次送過來的設定去試寄。

問題在於——伺服器位址那一欄也是使用者填的。

所以整件事變成：

使用者填一台自己控制的主機位址  →  密碼欄留空不改
                ↓
系統：「好，我用存著的真密碼去連你指定的那台機器」
                ↓
使用者在自己的機器上收到那組存著的郵件帳號密碼

外流的是誰的帳密

寄信設定全系統只有一份、存在最上層；而「改寄信設定」這個權限下放到各個下層客戶。所以下層的管理員，可以把上層那組郵件帳密導到自己的機器上。

外流的到底是誰的帳密，要看產品裝在哪裡：

落地安裝版裝好的時候，這一頁是空的。 出貨的初始資料只建立「改寄信設定」那四個權限與選單，一筆寄信設定的資料列都沒有——帳密全部由客戶自己填。

這是刻意的設計

持有「改寄信設定」這個權限的角色有 9 個，橫跨最上層與 7 個業務客戶；程式裡也寫明這個權限就是要下放給業務客戶的管理員。

裁定：寄信設定由客戶最上游的帳號自行管控，要不要把這個權限下放給子單位，是客戶自己的決定，不干我們的事。

拿到之後能做什麼

為什麼評為中風險

順帶一提：同一個程式庫裡已經有正確的做法——員工帳號目錄那支「測試連線」是目標位址變了就不准沿用存的密碼、要求重填。寄信這支漏了這一行。這不限制客戶任何權限，只是「你換了目標就自己重打密碼」。

---

第 2 條：寄信失敗時把密碼寫進系統紀錄（中）

問題：寄信失敗的處理程式，把整組郵件設定原封不動寫進系統紀錄檔——伺服器位址、寄件人、帳號、密碼、加密開關，整組都在裡面。

最值得注意的是觸發條件：這不需要攻擊者做任何事。密碼填錯一次、伺服器連不上一次、網路抖一下，就會寫進去。

同一支程式成功的時候是一欄一欄印的、不含密碼，只有失敗的時候把整組設定整包丟進去。而產品的「讀取郵件設定」功能本來就刻意把密碼遮掉了——遮了正門，後門卻開著。

修法：錯誤訊息只印錯誤本身（連不上、被拒絕、逾時），不要把整組設定丟進去。

第 3 條：加密連線不驗對方身分（中）

問題：連郵件伺服器時「有加密但沒認人」。對方拿一張隨便自簽的證明過來，系統照單全收、不會拋出任何錯誤，下一行就把帳號密碼送過去。

影響比第 2 條更廣：除了洩漏郵件帳密，每一封信的內容都會落到攔截者手上——包含登入用的一次性驗證碼與新帳號的初始密碼信。等於帳號被接管的材料整批送出去。

修法：選了加密就驗證對方身分；既有設定升級後行為不變。

真正的問題是設定上寫了加密、程式卻沒有兌現驗證。客戶在設定頁選了加密，他合理相信連線是安全的——實際上半路有人假冒伺服器，系統照樣把帳密和信件交出去。設定騙了他。

現在的做法：

• 設定頁在加密開關下方多一個「驗證伺服器憑證」開關，新建的設定預設開著。
• 接公司內部郵件伺服器（內部憑證或自簽）的客戶，把簽發它的 CA 憑證貼進「信任憑證」欄位即可驗過；填了就只信這一份。
• 真的拿不到憑證的客戶可以關掉驗證，開關旁會寫明風險。
• 升級前存的設定沒有這個開關的值，一律當作「不驗」——不這樣做，升級當天所有接自簽伺服器的客戶都會突然寄不出信。設定頁打開時頂部會提示「目前未驗證，建議開啟」，但不會替客戶自動改掉，要客戶自己存檔才生效。

用內部郵件轉送的客戶不受影響——他們選「無加密」本來就可以，內網直送很常見。

與第 2 條合成同一張工單（同一支檔案、同一段程式，分開改會互相踩到）。

第 4 條：「測試 Discord 群組」可當內網探測器（低）

問題：那個按鈕填什麼網址就打什麼，系統不限制目標。可以拿它去探測客戶內網有哪些機器、哪些服務開著。

誰按得動：它比「寄測試信」更嚴——要有通知設定的權限，還要是帳號層的最高管理員，兩個條件都滿足才按得下去。

還有一個權限更低的變體：把內網位址存起來，之後每次系統發通知都會去打它一次。

為什麼只評為低：回應的內容不會回傳給操作者，所以偷不到資料，只能探測。覆核者因此把提報的中風險降為低。

修法（兩層一起做）：

②比①更單純：不用維護「哪些算內網」的清單，直接比對「是不是 Discord 的網址」就好。

設定畫面完全不動，客戶照樣只填一個網址，擋在系統內部、使用者看不到。

---

寄信功能的資料格式裡宣告了「副本收件人」「密件副本」「附件」三個欄位，但實際寄信的程式完全沒有讀它們——填了就是丟掉，沒有任何警告或錯誤。

為什麼值得記：開發者看到有「副本」欄位，合理地以為填了就會寄副本，填完測試也不會報錯，但收件人永遠收不到，而且沒有任何線索指向原因。在稽核的情境下，這可能造成「以為通知了某個關係人、實際上沒有」。

不是資安問題，但確實是程式錯誤。

---

---