AID-H-020.002
極高
Secure HTML Rendering & Content Demotion
處理外部網頁內容時，最直接的控制是：網頁內容進模型前，應該先被清理、降權，並表示成不可信的純資料。Markdown 連結、遠端圖片、QR code 嵌入、隱藏指令和仿 UI 的文字，不應該原封不動保留下來，最後變成可執行或可渲染的回應元素。
網頁摘要釣魚：ChatGPT 如何被內容誘導成釣魚介面
Permiso 的 ChatGPhish 顯示，一個普通網頁如何把指令帶進 ChatGPT 的頁面摘要流程，讓 AI 助理把攻擊者控制的 Markdown，直接在 ChatGPT 的使用者介面裡，渲染成看起來可信的畫面。展示的 payload 包括釣魚連結、假的帳號警示、QR code，以及遠端圖片（圖片放在攻擊者伺服器上，一被 ChatGPT 渲染抓取，就會把使用者的 IP、瀏覽器資訊送給攻擊者）。這不只是一般的網頁型間接提示詞注入攻擊（web-based indirect prompt injection，IDPI）；真正的風險在於 ChatGPT 顯示回應的方式：使用者看到連結和圖片出現在助理回覆裡，容易以為它們也是 ChatGPT 可信回應的一部分。
6
項對應的 AIDEFEND 防禦手法
威脅分析
- 釣魚指令藏在網頁裡。 攻擊者把面向 Markdown 的提示詞注入攻擊文字放進網頁、README 或一般 HTML 頁面，等使用者之後要求 ChatGPT 摘要該頁。
- 網頁內容被轉成 ChatGPT 回覆裡的連結和圖片。 ChatGPT 先產生正常摘要，接著照著被注入的格式要求，附上一段假的安全警示、補充資源連結、圖片或 QR code。
- 連結和圖片在 ChatGPT 裡變成釣魚畫面。 連結變成可點擊，圖片被自動抓取，結果顯示在 ChatGPT 可信介面裡，而不是留在攻擊者自己的網頁上。
- 圖片被載入時，也會洩漏使用者的瀏覽資訊。 Permiso 展示的圖片和 QR code 變體，可以記錄 IP、User-Agent 和 Referer，並用圖片被載入的時間推測使用者看到回答的時間。
- 攻擊者控制的網頁內容混進助理回覆裡，使用者不容易分辨。 使用者看到的是 ChatGPT 回覆，但裡面的連結、圖片或警示文字，有一部分其實來自攻擊者控制的網頁；這些內容被保留下來，最後變成 ChatGPT 回覆裡可點擊、可載入的內容。
適用的 6 項 AIDEFEND 防禦手法
AID-H-019.005
極高
Value-Level Capability Metadata & Data Flow Sink Enforcement
ChatGPhish 本質上是出口控管問題：來自不可信網頁的值，流進可點擊連結、遠端圖片抓取、QR code 和釣魚 UI。凡是來自網頁的文字、連結或圖片，都要標成外部來源；在這些內容變成外部連線、圖片載入或可點擊動作之前，系統應該先擋下或降級。
AID-H-020.001
高
URL Normalization & Allowlist Filtering
這條攻擊依賴可用網址、短網址、重新導向、圖片和 QR code 目的地。URL 正規化與 allowlist 過濾應該把每個目的地轉成標準形式、解析重新導向，只允許連到核准過的外部網址，其他像內網、localhost 或 metadata IP 都要擋下，並在背景抓取、預覽或啟用渲染連結前先通過政策檢查。
AID-H-002.002
高
Inference-Time Prompt & Input Validation
惡意網頁真正變危險，是在模型開始處理這些內容之前。摘要流程應該把抓來的網頁內容標成不可信資料，拒絕資料通道裡那些像指令的格式要求，並在頁面試圖指定回應結構或假冒帳號安全 UI 時預設擋下。
AID-D-001.001
中
Per-Prompt Content & Obfuscation Analysis
許多 ChatGPhish payload 可以在渲染前被偵測到：強制格式覆寫、帳號警示語氣、Markdown 圖片加連結、短網址、QR code 嵌入，以及要求助理附上釣魚行動呼籲的指令。不過這是支援控制，不能單獨當成完整防線。
AID-H-018.007
中
Dual-LLM Isolation Pattern
這裡的 dual-LLM 重點，是把「讀不可信網頁」和「產生可信回覆」拆開。第一個低權限、隔離的模型只負責讀取原始網頁，並輸出型別明確的摘要；連結、圖片、QR code 和頁面提供的 UI 文字，都要拆成獨立欄位。第二個高權限模型或渲染器只接收驗證過的結構化資料，不直接接觸原始網頁指令，避免攻擊者的內容碰到可信回應介面。
身為資安防禦者，我們應該這麼做
- 盤點所有網頁摘要功能、瀏覽器助理、網頁閱讀器、RAG 預覽和 copilot 路徑，只要它會讀取第三方 HTML 或 Markdown，並在 AI 助理回應介面裡顯示可點擊連結、圖片或其他媒體，都要納入。
- 在推論前把網頁衍生的 Markdown 降權。頁面連結、圖片標籤、QR code 參照和格式指令，都要當成不可信欄位，不要當成回應指令。
- 停用不可信模型輸出裡的遠端媒體自動抓取；若必須抓取，先走安全 proxy，做標準 URL 檢查、重新導向控管，並避免帶出可識別使用者的 header。
- 對外部連結、短網址、QR code，以及來自摘要頁面的帳號警示風格 UI，加上來源標示和額外確認。
- 建立回歸測試：把假安全警示、補充資源連結、QR code、tracking pixel、短網址和隱藏格式要求放進普通網頁，確認整條鏈會在多個地方失敗。
- 記錄渲染器決策：哪些 URL 被壓掉、哪些媒體被抓取、哪些連結變成可點擊，以及回應中哪些片段來自第三方網頁內容。
1 個額外的防禦考量
助理渲染內容的來源標示
剩下的產品設計問題，不只是模型有沒有聽網頁指令。當助理回應裡的連結、圖片、QR code 或警示樣式元素來自第三方網頁，使用者需要直接看出來源。
建議做法: 除了上面對應的技術外，產品團隊也應該讓助理介面清楚區分模型自己產生的文字，以及來自外部網頁的連結、圖片、QR code 和帳號警示風格文字；任何外部目的地變成可互動前，都要有額外確認。
結論
ChatGPhish 的重點不只在模型被不可信網頁影響，而是在 ChatGPT 把那些網頁內容顯示成可信回覆的一部分時，就造成了釣魚的風險。連結、圖片、QR code 和警示文字一旦出現在 AI 助理的使用者介面裡，使用者很容易把它們當成 ChatGPT 本身的回覆。AIDEFEND 在這裡要防的是：不要讓攻擊者網頁裡的連結、圖片或警示文字，未經檢查就直接出現在 AI 助理介面裡。系統應該先確認來源、限制能連去哪裡，必要時把它擋下來或改成不可點擊。