WAF 字串封鎖，是把已知的攻擊特徵（某段字元、某個標頭、某種請求模式）寫成規則，請求一符合就擋。它對已知工具很有效，但只靠它，擋不住會依回應自動換招的 AI 自主滲透工具。
南韓資安業者 MONITORAPP 旗下的 AI Labs 分析一起金融業攻擊事件後認為：單靠封鎖單一字串，很難擋住自動化的 AI 攻擊。
本文先整理報導內容，再說明字串封鎖的三個盲點與 WAF 繞過類型，最後對照 OWASP 與金管會的建議，整理替代的防禦方向。
想先了解 WAF 的基本運作，可前往 WAF 是什麼？網頁應用程式防火牆能擋哪些攻擊、和一般防火牆的差別 觀看，本文不重複原理，直接談字串封鎖的盲點與替代做法。
新聞重點：現場封了字串，AI Labs 說效果有限
依 Financial News 轉載的聯合新聞稿（2026-11-08），事件脈絡大致是這樣：
| 項目 | 報導內容 |
|---|---|
| 工具 | ARTEX，開源的多代理框架，後端可接 Claude、ChatGPT、DeepSeek 等商用 LLM，自動做偵察、掃描、攻擊與失敗後的繞過 |
| 現場做法 | 在疑似用於金融業事件的攻擊者基礎設施伺服器上，發現 ARTEX 的中文管理者字串，資安現場在防火牆封鎖該字串、特定 User-Agent 標頭與 ARTEX 專用模式 |
| AI Labs 評價 | 這類單點封鎖效果有限：標頭容易偽造，攻擊內容是既有網頁攻擊手法的組合，不是新技術 |
| 建議 | 對業務用 API 嚴格套用身分驗證與授權檢查，並搭配能辨識攻擊流程關聯的行為式防禦 |
| 情資 | AI Labs 表示取得約 50 個攻擊者 IP 與 C2（命令與控制）伺服器網域，已緊急加入偵測模式 |
報導有兩點要留意。
- AI Labs 自己表示，攻擊基礎設施上確實發現 ARTEX 的執行痕跡，但是否直接用在金融業攻擊，仍需官方確認。
- 美國資安公司 CrowdStrike 的報告（聯合報轉述）指出，攻擊者使用中國開發的開源滲透測試工具 ARTEX，並結合 Claude 等大型語言模型。
關於 CrowdStrike 的「中等信心」，轉述報導的內容是：這項活動尚未歸咎於具體的敵對方，但攻擊者可能講中文、具有財務動機，這項評估基於 ARTEX 的使用與觀察到的中文指令，CrowdStrike 對此具有中等程度的信心。也就是說，中等信心指的是攻擊者背景的推測，而且目前沒有指向特定組織。
所以事件歸因還沒有定論，用「疑似」比較穩妥。
補充說明：以上 AI Labs 的看法，是從聯合新聞稿的轉載報導讀到的。截至撰稿時，MONITORAPP 官方網站的 AI Labs 頁面與其資源頁沒有查到這份報告的原文或新聞稿。
字串封鎖的原理與盲點
字串封鎖是簽章式（特徵比對）的做法：事先定義「這串字元、這個標頭、這個模式就是惡意」，請求一符合就擋。
優點是快、好理解，對已知工具與 payload 很有效。
問題在於它只認得「長相」，不認得「意圖」。這裡有三個盲點：
特徵是攻擊者可以自己改的
User-Agent 之類的標頭，由發請求的人決定要填什麼。你封了 ARTEX 的專用標頭，對方換一個就繞過去，報導講的「標頭容易偽造」就是這個意思。
攻擊內容本身沒有獨特特徵
報導指出，ARTEX 送出的單一 HTTP 請求與既有的網頁漏洞攻擊相似，所以只靠這個工具專屬的特徵碼，很難精準辨識。
這種請求跟一般掃描器的請求很像，沒有哪個字串專屬於這個工具。
黑名單永遠列不完
OWASP 的 Input Validation Cheat Sheet 對這件事講得很直接：不要試圖辨識所有惡意字串。
它的例子是：封鎖單引號會拒絕合法的姓名，卻不會讓資料庫查詢變安全。拒絕清單既列不完惡意輸入，也可能誤擋合法輸入。
AI 攻擊工具會怎麼變形
報導的重點是：AI 代理會依伺服器的反應調整做法，失敗了就換一種方式再試，過去這要靠人手動做。
報導沒有細講它具體用哪些變形，本文不推測 ARTEX 的內部實作。
比較有佐證的，是 WAF 繞過手法本身早就有公開整理。OWASP 社群的 SQL Injection Bypassing WAF 列了幾類概念，本文只整理類型，不附可直接使用的攻擊字串：
| 變形類型 | 對字串比對的影響 |
|---|---|
| 在關鍵字之間插入 SQL 註解 | 關鍵字被切開，特徵比對對不上 |
| 大小寫混用 | 繞過只比對小寫關鍵字的規則 |
| URL 編碼、十六進位 | 同一段內容換一種表示法，字串比對看不出來 |
| 以同義函式或寫法替換 | 邏輯相同，但特徵不同 |
AI 的差別不在於發明新招，而在於試錯很便宜：這些變形可以自動、大量、依回應結果調整地去試。
根本的防護在應用程式端
OWASP 的 SQL Injection Prevention Cheat Sheet 把解法寫成：把 SQL 結構與資料值分開，再用資料庫 API 綁定這些值，也就是使用參數化查詢。主要防禦列的是 Parameterized Queries 與 Allow-List Input Validation，兩者都在應用程式端，不靠邊界擋字串。
想看 SQL Injection 的實際攻防，可前往 SQL Injection Union-based 攻擊手法實作範例與參數化查詢防禦 與 Prepared Statements 參數化查詢如何防範 SQL Injection 與防禦實務 觀看；XSS 的部分見 XSS 跨站腳本攻擊三大類型與現代化防禦實作要點。
防禦方向
報導給的建議是兩項：對業務用 API 做嚴格的身分驗證與授權檢查，再結合能辨識攻擊流程關聯的行為式防禦。
以下對照 OWASP 與金管會的建議，整理成幾個方向。
行為分析：看流程，不只看單一請求
簽章看的是單一請求像不像攻擊；行為分析看的是一串請求的關聯。例如短時間內掃過大量路徑、同一來源反覆試錯、存取順序不合理。
這就是報導說的「辨識攻擊流程關聯」。
金管會 2026-07-14 的新聞稿也把強化持續監控列為建議，方向是能早期發現異常、關聯弱點與攻擊線索，並持續優化偵測、分流與止血效能。
正向模型（allowlist）：定義什麼是對的
與其列舉壞的，不如定義好的。OWASP 的建議是先定義應用程式接受什麼，範圍外的值一律拒絕。
它的欄位規則表有幾個例子：固定選項要完全符合允許集合，數字與日期要符合型別、格式與上下限，字串要有長度限制與欄位要求的字元或結構。這樣不管攻擊字串怎麼變形，不符合預期格式就進不來。
API schema 驗證：把格式檢查做在伺服器端
Input Validation Cheat Sheet 也談到結構化資料的 schema 驗證。JSON 要明確設定必填屬性與額外屬性，因為只列出屬性，並不會自動要求它出現，也不會拒絕未知欄位。
驗證失敗時要明確拒絕請求，不要拿部分驗證過的資料繼續處理，並且只把預期的輸入欄位綁定到應用程式物件。
對報導點名的業務用 API 來說，這比在邊界擋字串更貼近問題。想了解實作方式，可前往 API request validation 驗證與 Zod / Joi 資料防禦機制：攔截無效 Payload 避免 GIGO 汙染 觀看。
身分驗證與授權：別讓請求只靠「看起來正常」過關
報導與金管會新聞稿都提到要強化 API 與後端服務的驗證與授權。金管會的原文是：宜同步強化後端服務與 API 之身分驗證、授權檢核、異常偵測及流量控管，以降低自動化濫用與未授權存取風險。
授權是在服務端判斷「這個身分能不能碰這筆資料」，不看請求長什麼樣子，攻擊字串再怎麼偽裝也不影響這項判斷。
速率限制與異常偵測：限制自動化的規模
自動化工具的優勢是量，所以限制量是直接的對策。OWASP API Security Top 10 的 API4:2023 建議限制單一 API 用戶端執行特定操作的次數與頻率（例如驗證 OTP、密碼重設），並對輸入參數與酬載設定大小上限。
金管會新聞稿在「暫難立即修補項目」的替代控管中，也列了隔離、權限收斂、流量限制、臨時阻擋規則、端點偵測與回應，或網路分段。
臨時阻擋仍有用，但要當止血
這不代表字串封鎖沒有價值。金管會新聞稿把「臨時阻擋規則」列為暫難修補時的替代控管之一，用來爭取修補時間。
特徵封鎖適合止血，不適合單獨當長期防線，這是依上述內容做的推論，非官方明文。
台灣金融業的對應規範
金管會 2026-07-14 的新聞稿列出七項建議，與本文相關的有零信任（強化 API 驗證、授權檢核、異常偵測、流量控管）、持續監控，以及暫難修補時的替代控管。這些談的是方向，不是針對 WAF 字串封鎖的逐條規定。
常見問題 Q&A
Q1：既然字串封鎖不夠，還需要 WAF 嗎？
需要，但不要把它當成唯一的防線。
OWASP 社群對 WAF 的定義，是針對 HTTP 應用程式、對 HTTP 對話套用一組規則的防火牆。規則式過濾對已知手法仍有價值，只是規則只能涵蓋已知特徵。
Q2：看到 ARTEX 的字串或 User-Agent，先封起來可以嗎？
可以先封，但要當成止血。
報導中的現場做法就是這樣，但 AI Labs 認為單點封鎖效果有限：標頭容易偽造，攻擊內容也不是新技術。封完之後，還要處理 API 的驗證、授權與輸入驗證。
Q3：速率限制一定要在應用程式裡做嗎？
不一定，WAF 產品本身也提供這類功能。
以 AWS WAF 為例，官方文件說明 rate-based rule 會計算進入的請求，並在請求速度過快時限制其速率。特定操作（如 OTP 驗證）的設限可參考 OWASP API4:2023。
Q4：怎麼檢查自家的業務用 API 有沒有盲點？
可以依下列順序盤點，每一步都對照前面的防禦方向：
- 列出所有對外與對內的業務用 API，特別是平常較少人看的後台與整合介面，報導指出這類 API 容易落入管理死角。
- 逐支確認是否要求身分驗證，以及授權檢查是否在服務端判斷。
- 確認請求欄位有 schema 驗證：必填欄位、額外屬性的處理方式，以及驗證失敗時是否明確拒絕。
- 確認對敏感操作（登入、OTP、密碼重設）與請求大小設有頻率與大小上限。
- 確認監控能關聯一串請求，而不只是逐筆比對特徵。
小結
這次報導的核心不是「WAF 沒用」，而是「只靠特徵字串的 WAF 不夠」。
比較務實的組合是：WAF 擋已知的雜訊，allowlist 與 schema 驗證做在服務端，API 補上身分驗證與授權，再用速率限制和行為分析壓住自動化的規模。
事件的歸因還沒有定論。上述方向分別對應 OWASP 與金管會的建議，不依賴攻擊者是誰。
參考資料與延伸閱讀
- AI 駭客攻擊突破既有防線？金融業資安警示（原題為韓文），Financial News 轉載聯合新聞稿，2026-11-08
- 韓金融業遭駭 CrowdStrike 揭中國駭客用 AI 工具犯案，聯合新聞網
- Input Validation Cheat Sheet，OWASP Cheat Sheet Series
- SQL Injection Bypassing WAF，OWASP Community
- API4:2023 Unrestricted Resource Consumption，OWASP API Security Top 10
- 金管會提醒金融業強化前沿 AI 模型攻擊風險整備，金融監督管理委員會
- SQL Injection Prevention Cheat Sheet，OWASP Cheat Sheet Series
- Web Application Firewall，OWASP Community
- Using rate-based rule statements in AWS WAF，AWS 文件
- 站內延伸：WAF 是什麼、SQL Injection Union-based 攻防、Prepared Statements 參數化查詢、XSS 防禦實作要點、API request validation 與 Zod / Joi
發佈留言