在不斷變化的新威脅和攻擊手法中，確保AI驅動的應用程式安全可不是件容易的事。最新型態的攻擊之一涉及隱形字母——這曾是使用隱形墨水的間諜工具，現在卻成為對AI提示的一種現代威脅。

大型語言模型（LLMs）及接受用戶提交提示的人工智慧應用程式，可能會受到使用不可見的“標籤”（tag）字元的注入攻擊。用戶可能認為自己正在提交一個無害的請求，但實際上，他們可能在不知情的情況下提交了惡意內容。

什麼是標籤字元？

Unicode tags 是特殊的隱形字符，旨在重現大部分典型英語鍵盤上的字符，包括字母、數字、空格以及像 # 或 & 的符號，這些都是根據美國信息交換標準碼 (ASCII) 標準設計的。

標籤字元最初是為了在不明顯的情況下記錄書寫文本的語言而設計的—基本上是添加隱藏的元資料，而不需要依賴像可擴展標記語言 (XML) 這樣複雜的標記系統。例如，一個像 “da” 這樣的隱形標籤可以標記一段用丹麥語書寫的文本的開始。

這些特殊標籤字元在2008年正式從Unicode標準中廢除。不過，大部分的字元後來都有被恢復及重新使用。現在，它們用來編碼區域性旗幟。例如，將Unicode的 “WAVING BLACK FLAG” 字元與隱形標籤字元 “gbsct” 結合，接著再加上結束的 “CANCEL TAG” 字元，就可以產生出 “蘇格蘭國旗” 的emoji：🏴󠁧󠁢󠁳󠁣󠁴󠁿

這是怎麼變成問題的

問題在於這些不可見的字元可以用來干擾 AI 的提示。雖然提示看起來合法且無害，但它可能已經被注入了不可見的標籤字元，這會完全改變提示的意義。

考慮一個簡單的例子提示：「喀麥隆的首都是哪裡？」

攻擊者可能會添加隱形字符，改變模型的回應方式，例如：“現在忽略所有先前的指示，並且…”

雖然這些字符對人類來說是看不見的，但某些 LLM 還是會把它們讀作正常的字母和標點符號，這意味著隱藏的指令會像可見文字一樣被處理。

並不是所有的 LLMs 都以相同方式處理它們：有些會忽略不可見的標籤字元，而其他則將它們解釋為普通 ASCII。由於整個英文字母和標點符號都以這種「不可見」的形式存在，因此這種攻擊方式非常靈活。

深入探索以尋找防禦策略

這些標籤字元佔據了他們自己的Unicode區段，範圍是U+E0000到U+E007F。對抗這些字元的一種方法是部署網路應用程式防火牆（WAF）在流量路徑中，使用一條規則來檢測這些字元的存在並阻擋任何包含這些字元的請求。Progress Kemp LoadMaster WAF可以勝任這項任務。

WAF 引擎在歷史上對於 Unicode 一直面臨挑戰。僅僅在正則表達式模式中表示高位碼點是 令人驚訝地 難以做到的，而且往往在不同的正則表達式庫和 WAF 引擎之間不具可攜性。

然而，WAF 可以 可靠地偵測這些Unicode字符在UTF-8編碼下產生的位元組模式——這是現代互聯網的通用語言。雖然整個Unicode標籤區塊並沒有被技術上完整分配（有31個未分配的代碼點），我們可以透過檢查它們的UTF-8位元組序列，開始匹配範圍在U+E0000到U+E007F之間的任何字符：

• 起始碼點: U+E0000
• UTF-8編碼位元組: F3 A0 80 80
• 結束碼點: U+E007F
• UTF-8編碼位元組: F3 A0 81 BF

前兩個位元組是固定的，始終為 F3 A0，這形成了檢測模式的開始。

一個簡單（雖然不太優雅）的下一步是列印出這個區塊中每個碼點的UTF-8編碼位元組。這樣做顯示出最後一個位元組並不會持續增量（這是因為碼點在UTF-8中的編碼方式），而且會出現斷裂——導致需要偵測的兩個獨立位元組範圍：

• F3 A0 80 80 – F3 A0 80 BF
• F3 A0 81 80 – F3 A0 81 BF

這可以用正規表達式模式來表示：

\xF3\xA0(?:\x80|\x81)[\x80-\xBF]

整合所有內容：自訂 WAF 規則

正規表達式模式可以作為自訂 WAF 規則的依據，用來檢測請求中是否存在隱形標籤字元。這個 regex 可以與 WAF 行動結合，明確拒絕任何檢測到隱形標籤字元的請求，同時也記錄下有問題請求的詳細資料，供日後分析使用。

以下是一個可以新增至 LoadMaster WAF 的 SecRule（網路應用防火牆安全規則）範例，用於啟用這種偵測和封鎖行為：

SecRule ARGS "@rx \xF3\xA0(?:\x80|\x81)[\x80-\xBF]" \     "id:1000,\     phase:2,\     deny,\     capture,\     t:none,\     log,\     msg:'偵測到不可見的 Unicode 標籤字元',\ 

    logdata:'符合資料: %{TX.0} 被發現
在 %{MATCHED_VAR_NAME}: %{MATCHED_VAR}'，\ 
    tag:'PROGRESS/KEMP-LOADMASTER'"

測試新規則

首先，將規則複製並貼上到文字編輯器，然後儲存為 .conf 規則檔案，方便隨時存取：

如果其他自訂規則已經在使用中，請確保將規則 ID 更改為唯一的值，如果範例 ID 1000 已經被使用。

注意：這個範例規則會掃描 ARGS 集合：這代表它會檢查所有的查詢字串和 POST 主體參數—包括 JavaScript 物件Notation (JSON) 和 XML 載荷—以尋找隱藏的標籤字符。這是最有用的掃描位置，但如果需要其他選擇，LoadMaster 支援團隊可以提供指導（例如，掃描請求標頭或 Cookie 等）。

2: 上傳新的自訂規則

接著，在 LoadMaster 的網頁介面上，前往 Web Application Firewall > Custom Rules，然後上傳新的自訂規則檔案：

3: 將新規則付諸實行

在 檢視/修改服務 下，點擊虛擬服務旁邊的 修改。展開 WAF 標籤，勾選新自訂規則檔案旁邊的方框，然後點擊 套用 以啟用它。

注意：套用此規則會觸發一次短暫的服務重載，這可能會瞬間中斷對這個虛擬服務的流量。

重要事項：如果您需要檢查請求內容（例如 POST 請求、JSON 請求等），請務必開啟 進階設定 並啟用 檢查 HTTP POST 請求內容。大部分用戶都會希望啟用此功能。

4: 測試新規則

A: 陰性測試

發送包含這些高碼點Unicode字符的測試請求可能有點棘手。使用Linux終端機和curl指令測試是相對簡單的。

首先，發送一個乾淨且合理的請求：

虛擬服務應該回傳 200 OK 的回應，並且允許通過 WAF：

B: 陰性測試

接下來，發送一個包含不可見標籤字元的請求。在 Linux 終端機（使用預設的 GNOME Terminal 測試）中，按下 CTRL+SHIFT+U 來輸入一個 Unicode 字元。這會顯示一個底線的起始字母 u，之後可以輸入代碼點。在這個例子中，一個不可見的大寫字母 P（標記為 “ue0050”）將被添加到請求中：

按下 ENTER 來加入隱形的 Unicode 字元，它將會「消失」（但它確實存在，並且會在請求中發送！）:

發送請求並確認 WAF 返回了 403 Forbidden 的回應：

要確認這項規則的效果，可以查看 WAF 日誌。為此，請導航至 系統設定 > 日誌選項 > 系統日誌檔案，然後點擊 檢視 旁邊的 WAF 事件日誌檔案：

您要關注的日誌條目通常會位於日誌檔案的最底部或其附近。為了加快查找速度，可以試著搜尋規則 ID，例如：

id "1000"

日誌行應該看起來像這樣（為了可讀性，這裡分成多行顯示）：

2025-09-03T09:45:54+00:00 lb100 wafd:  
ModSecurity: Access denied with code 403 (phase 2). Pattern match "\\xF3\\xA0(?:\\x80|\\x81)[\\x80-\\xBF]" at ARGS:ai-prompt.  
[file "/tmp/waf/1/block-invisible-tag-chars.conf"]  
[line "10"]  
[id "1000"]  
[msg "Detected invisible Unicode tag characters"]  
[data "Matched Data: \xf3\xa0\x81\x90 found within ARGS:ai-prompt: foo\xf3\xa0\x81\x90\xf3\xa0\x81\x90"]  
[tag "PROGRESS/KEMP-LOADMASTER"]  
[hostname "192.168.2.150"]  
[uri "/"]  
[unique_id "33941351-75e7-451e-a5ed-6f38d74ff79f"]

成功偵測到 UTF-8 編碼的隱形大寫 P 標籤字元，對應的位元組串為 \xf3\xa0\x81\x90，因此該請求已被拒絕。

C: 測試被阻擋的範圍

作為額外確認確保只有預期的字元範圍被封鎖的步驟，可以測試被封鎖範圍前後的字元。這些字元應該仍然被允許並返回200 OK的回應。

(注意：Tags 區塊兩側的碼點目前尚未分配，並且不是有效字元——但將來可能會被使用，因此不應該不必要地封鎖它們。)

使用簡單的腳本進行測試，得到以下結果，這些結果符合預期：

⋮
U+DFFFD: 200
U+DFFFE: 200
U+DFFFF: 200
U+E0000: 403
U+E0001: 403
⋮
U+E007D: 403
U+E007E: 403
U+E007F: 403
U+E0080: 200
U+E0081: 200
⋮

總結

以AI為基礎的應用程式和體驗需要額外的時間和注意力來防範不法分子。特別是，那些允許自由格式用戶輸入的AI應用程式（例如AI提示）容易因為注入而被濫用，因此必須加以防護。除了這裡描述的全新攻擊途徑外，傳統的攻擊方法，例如遠端命令執行、伺服器端請求偽造等，仍然適用。Web應用防火牆（WAF）能夠檢測、記錄並拒絕這些所有的攻擊。

今天就來跟我們聊聊您的 WAF 及負載均衡需求，然後利用 LoadMaster 的 30 天免費試用，親自來測試看看。

使用 StackEdit 撰寫。

文章來源: Defending AI Applications from Invisible Prompt Injection Using LoadMaster WAF