這篇技術分析將探討近期在企業級生成式 AI 平台 Writer 中發現的一個嚴重安全漏洞，代號為 WriteOut。對於開發者來說，這個案例非常經典，它揭示了當我們為了提供方便的預覽功能而引入代理機制時，如果對 Session 隔離處理不當，會如何導致災難性的跨租戶攻擊。
首先我們需要理解什麼是租戶隔離 Tenant Isolation。在 SaaS 軟體架構中，不同公司（租戶）的資料必須完全隔開，A 公司的員工絕對不能看到 B 公司的資料。而 Session Token（會話令牌）則是使用者登入後的身份證明，只要拿到這個 Token，攻擊者就可以在不需要密碼的情況下，直接偽裝成該使用者存取系統。
WriteOut 漏洞的核心在於 Writer 平台提供的一項預覽功能。該功能允許開發者在 Writer Framework 中建立 AI Agent（AI 代理人），並透過一個公開的預覽連結讓他人測試。為了讓預覽過程能像真實環境一樣運作，系統使用了一個預覽代理伺服器 Preview Proxy，將請求轉發到一個由 AI 管理的沙箱環境 Sandbox 中執行。
漏洞發生的技術脈絡是這樣的。當一名已經登入 Writer 的受害者點擊攻擊者發送的預覽連結時，瀏覽器會根據標準的 HTTP 協定，自動將該使用者的 Session Cookie 附加在請求中發送出去。然而，Writer 的預覽代理伺服器在處理這個請求時，錯誤地將這個敏感的 Session Cookie 直接轉發到了攻擊者所控制的沙箱環境中。
在沙箱內部，攻擊者可以執行自定義代碼。這意味著攻擊者只需要在 AI Agent 中寫一段簡單的程式碼，去讀取沙箱進程的記憶體或環境變數，就能輕易地獲取被轉發過來的 Session Token，並將其傳送到自己的外部伺服器。一旦拿到 Token，攻擊者就可以進行 Session Replay（會話重播），直接接管受害者的帳號。
最危險的地方在於，這種攻擊是跨租戶的。攻擊者不需要與受害者屬於同一家公司，只要受害者點擊連結，無論他是普通員工還是系統管理員，其權限都會被劫持，導致私密對話、企業文件、LLM 憑證甚至管理權限全部外洩。
這裡有一個值得 Junior 工程師思考的設計失誤：Writer 當時其實有設置防護欄 Guardrails，試圖過濾惡意指令或禁止讀取環境變數。但問題在於，這些檢查僅限於輸入端的靜態過濾（Input-side filtering），也就是檢查使用者輸入的 Prompt（提示詞）是否包含危險字眼。
攻擊者採取了繞過策略：他們不在 Prompt 中直接寫惡意代碼，而是指令 AI Agent 去下載並執行一個遠端腳本。對防護系統來說，下載遠端檔案是一個看似正常的行為，但真正的攻擊邏輯是在運行時（Runtime）才觸發的。這提醒我們，僅靠輸入端過濾是不夠的，必須從底層的運行時行為和權限隔離著手。
針對此漏洞，Writer 的修復方案採取了兩項關鍵措施。第一，完全禁止將使用者的 Session Cookie 轉發至沙箱預覽環境中，從源頭切斷洩漏路徑。第二，將預覽功能移至隔離的來源域（Isolated Origin），利用瀏覽器的同源策略（Same-Origin Policy）來強化安全邊界。
總結來說，這個漏洞給我們的工程啟示是：任何涉及代理轉發請求的機制，都必須極其謹慎地審視哪些 Header 或 Cookie 是必要的。如果預覽環境不需要使用者身份驗證，就絕對不應該將身份憑證傳入沙箱。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。