攻擊者首先會入侵目標商店的 Google Tag Manager 容器,並植入一段惡意標籤,使其在每一個頁面載入。由於這段腳本是從可信的 googletagmanager.com 分析網域發出,它可以繞過常見的內容安全政策與廣告封鎖程式,同時不會觸發任何警報 。GTM 在此成為了一個無法被封鎖的傳遞機制。
有別於向可疑的第三方伺服器發送請求,GTM 標籤會轉而向 api.stripe.com 請求側錄酬載。攻擊者將完整的 JavaScript 側錄程式碼,存放在他們自己 Stripe 帳戶內的一個「客戶中繼資料(Customer metadata)」欄位中,並使用測試模式密鑰(sk_test_...)來寫入與讀取 。由於側錄酬載是從商店營運者完全信任,且視為支付基礎架構一環的網域載入,網路監控系統與內容安全政策規則幾乎不會對這類 API 呼叫進行標記。
當購物者在結帳頁面輸入信用卡號、個人資訊與帳單地址時,注入的側錄器便會擷取這些資料,並利用相同的 Stripe API 將其寫回駭客的 Stripe 帳戶中,偽裝成虛假的客戶記錄或中繼資料項目 。由於資料外傳的流量同樣是傳回
api.stripe.com,它會與合法的支付 API 呼叫完美地融為一體,讓這起資料竊取行為在防火牆日誌與異常偵測工具前近乎隱形 。
Stripe 的測試模式密鑰(以 sk_test_ 開頭)賦予了在沙盒環境中完整的讀取與寫入權限,並且可以無限制地免費建立虛假客戶與中繼資料欄位 。由於測試密鑰永遠不會觸發真實交易,其濫用行為很容易被忽略。攻擊者正是利用了多數組織將測試密鑰視為低風險,且未能以審核正式環境資料時同樣的嚴格標準來稽查沙盒活動的心態。
另一個相關但獨立的威脅,則是正式環境密鑰的曝光,這將使攻擊者可直接存取真實的交易資料,並能進行退款或轉移資金 。儘管此波攻擊行動為了隱匿行蹤採用了測試模式密鑰,但其根本原理相同:無論處於何種模式,Stripe API 密鑰都是功能強大的憑證,絕不應出現在用戶端程式碼或 Google Tag Manager 容器中
。
CVE-2026-3300 是存在於 Everest Forms Pro 外掛中的一個未經身分驗證的遠端程式碼執行(RCE)漏洞。該外掛約有 4,000 個有效安裝數 。此弱點在通用漏洞評分系統(CVSS)上獲得了 9.8 的評分(滿分 10 分),影響所有 1.9.12 及之前的版本
。
漏洞存在於 Calculation(運算)附加元件內的 process_filter() 函式中。當「Complex Calculation」功能啟用時,外掛會將使用者在字串型態表單欄位中提交的值,直接串接到一段 PHP 程式碼字串中,並在未經妥善逸出的情況下將結果傳遞給 eval() 函式執行 。由於系統對輸入值所執行的
sanitize_text_field() 函式無法消除單引號或其他在 PHP 程式碼情境中具有特殊意義的字元,攻擊者因此能夠突破預期的字串限制,注入任意指令 。
Wordfence 已阻擋超過 29,300 次漏洞利用嘗試,並指出攻擊者正在利用漏洞入侵後的權限,建立未經授權的管理員帳戶 。網站管理者應留意以下入侵指標:出現名稱可疑的新管理員使用者、伺服器上的異常檔案,或是可疑的對外連線
。
api.stripe.com 列為 script-src。若必須將其納入,請強制執行子資源完整性(SRI)雜湊檢查。同時,封鎖內嵌腳本可提供另一層防禦
Comments
0 comments