跳至主要內容

Magecart 是甚麼?網店如何防範,由信用卡到 Pix

Laís Peixoto

作者 Laís Peixoto

Growth Marketer, Proteside

發佈於 · 2 分鐘閱讀

Magecart 是指在正規網店付款頁面植入惡意程式碼,用來複製信用卡資料,或在巴西調包 Pix QR Code 的攻擊。保護網店要堵住入侵途徑,並在買家的螢幕上核對頁面實際顯示的內容。

Magecart 是指一類攻擊:在正規網店的付款頁面植入惡意程式碼,截走顧客輸入或支付的內容。多年來,目標都是信用卡號碼。2026 年 9 月,巴西一次攻擊活動顯示,同類程式碼會調包 Pix(巴西中央銀行的即時支付系統)的 QR Code。網店照常運作,品牌正確,價格正確,顧客看不出任何異樣。

名稱的由來

這個名稱由 Mage(來自 Magento)和 cart(英文的購物車)組成。研究人員約在上個十年中期開始用它稱呼攻擊這個平台購物車的集團。後來,這個詞泛指這種手法本身,不論是哪個電子商貿平台、自建網店還是第三方服務。

定義 Magecart 攻擊的不是所用的工具,而是位置:顧客填寫付款方式的那一頁。

Magecart 攻擊如何運作

  1. 入侵:程式碼經由平台未修補的漏洞、有漏洞的插件或佈景主題、外洩的後台密碼,或被入侵的第三方腳本進入。2024 年 6 月,一個被超過 10 萬個網站使用的腳本服務在易手後開始派發惡意程式碼。
  2. 偽裝:這段程式碼通常只有幾行經混淆的代碼,藏在合法檔案、圖片或網店早已信任的服務之內。2026 年 4 月,研究人員在約 100 間網店發現程式碼藏在一張隱形圖片中。同年 6 月,另一個家族把程式碼和偷來的資料存放在一個知名支付服務內,讓流量看起來正常。
  3. 只在結帳頁發動:程式碼在其他頁面保持靜默。顧客進入付款步驟時,它會讀取信用卡或扣賬卡的欄位,或調包 QR Code、Pix Copia e Cola(顧客複製後貼到銀行 App 付款的文字付款碼),或 boleto(巴西銀行付款單)的 linha digitável(boleto 上的付款號碼)。
  4. 得手:信用卡資料會傳到攻擊者的伺服器,日後再被使用。Pix 則是顧客自己即時把錢轉到錯誤的帳戶。

定義這個問題的案例

  • British Airways,2018 年:網站和 App 上一個被修改的腳本,在約兩星期內複製了付款資料。英國資料保護機構統計有 429,612 人受影響,並於 2020 年 10 月處以 2,000 萬英鎊罰款。
  • Europol,2023 年:一次由 Europol(歐洲刑警組織)協調的行動,通知了多個國家數以百計的網店,它們的付款頁面上有正在運作的盜卡程式碼,大部分網店並不知情。
  • 2026 年:本年度的研究顯示,程式碼正轉移到一般防護不會檢查的地方:圖片之內,以及合法支付服務之內,網店很少會在那裏搜查。
  • 巴西,2026 年 9 月:一位名為 eremit4 的獨立研究人員發現、再由 Kaspersky 證實,90 間中小型網店的結帳頁上有調包 QR Code 和 Pix Copia e Cola 的程式碼。顧客選擇信用卡時,同一段程式碼會複製卡資料。研究人員把這宗案件稱為「巴西的新 Magecart」。我們在 Pix 版 Magecart 詳細分析了這宗案件。

網店為何遲遲察覺不到

信用卡方面,交易獲批,錢也入帳。損失要幾星期後才在顧客的月結單上出現,而且要等發卡銀行對照多宗個案,才會發現所有人都在同一間網店購物。

Pix 方面,款項根本沒有進來。後台顯示訂單待付款或已放棄,投訴要幾天後、貨品沒有寄出時才出現。2026 年受影響的商戶表示,他們最先察覺的是放棄訂單增加,之後才明白發生了甚麼事。

無論哪種情況,伺服器都可能看似乾淨。如果程式碼來自外部,或在瀏覽器中組合而成,網店檔案的副本不會有任何改變。改變的是顧客看到的畫面。

PCI DSS 有甚麼要求

自 2025 年 3 月 31 日起,PCI DSS 的要求 6.4.3 和 11.6.1 對所有網上接受卡付款的商戶強制執行。6.4.3 要求為付款頁面上的腳本建立清單,每個腳本都要有理由說明和完整性保證。11.6.1 要求設置機制,偵測頁面和安全標頭未經授權的變更,並最少每星期檢查一次。

這兩項要求是因應信用卡 Magecart 而制定的。它們沒有提到 Pix 或 boleto,雖然調包 QR Code 的程式碼在同一個頁面、經同一途徑執行。兩項要求的說明見 PCI DSS 合規。

如何保護網店免受 Magecart 攻擊

  1. 堵住入侵途徑:更新平台、佈景主題和插件,並移除不用的部分。大部分攻擊活動利用的都是已知且早已修補的漏洞。
  2. 保護管理後台:所有管理員啟用雙重認證,檢查有權限的帳戶,並更換各項整合服務的密碼。
  3. 減少結帳頁上執行的內容:付款頁面上每個腳本都需要負責人和用途。即時聊天、熱圖和廣告追蹤像素很少需要放在那裏。
  4. 優先使用由服務供應商託管的信用卡欄位:這可減低資料被直接複製的風險,但周圍的頁面仍可顯示假表格。託管欄位能解決部分問題,不能解決全部。
  5. 限制頁面可以把資料傳送到哪裏:設定妥善的內容安全政策,可阻礙資料傳送到不明伺服器。但如果攻擊者使用網店已經放行的服務,它就幫不上忙。
  6. 以顧客看到的樣子監察頁面:伺服器上的檔案可能沒問題,螢幕上顯示的卻是錯的。請看 如何監察結帳頁的變更。
  7. 核對顯示的付款碼:Pix、boleto 和穩定幣錢包,都要在顧客付款前,把螢幕顯示的內容與網店發出的內容比對。
  8. 為出事當天準備計劃:誰負責停用受影響的付款方式,誰聯絡服務供應商,如何通知顧客,如何保存證據。

網店可能已受攻擊的跡象

  • Pix 待付款增加,但結帳頁訪問量沒有相應下降。
  • 顧客說已付款但訂單未獲批核,收據上的收款人是另一間公司。
  • 支付服務供應商或收單機構通知,有信用卡在網店購物後被盜用。
  • 沒有人發布過任何內容,檔案卻被修改,或出現沒有人認識的管理員。
  • 付款頁面把資料傳送到團隊不認識的網域。

如果同時出現兩個跡象,在證實無事之前,都應當作安全事故處理。

Proteside 的角色

Proteside 是一層網絡安全防護,在付款人的螢幕上核對付款資料是否與賣家發出的一致,並在確認付款前攔截調包。它會建立 PCI DSS 要求的腳本清單,並更進一步:在每張訂單中,把 QR Code、Copia e Cola、linha digitável 和信用卡表格與網店產生的內容比對,並把每次調包嘗試記錄為證據。請看它如何保護 信用卡付款,以及如何支援 PCI DSS 合規。

返回網誌