神腦資安事件拆解：「自動化攻擊」怎麼撈走訂單資料？三種常見手法與電商自查清單

「您好，這裡是客服中心，您上週訂的那支手機，系統誤設成十二期分期，每個月會自動扣款……」如果你最近在網路上買過 3C 產品，接下來幾週接到這種電話的機率不低。對方唸得出你的名字、買了什麼、花了多少錢，聽起來就跟真的客服一模一樣。

神腦在 2026 年 9 月 29 日發出重大訊息，承認外部伺服器遭到自動化攻擊，部分訂單資訊被擷取。我們團隊看到公告後，第一件事是回頭檢查自己手上幾套系統的訂單查詢 API。這類事件的起點，常常就是一支大家以為「沒人會亂打」的 API。

這篇把三件事分開寫：公告確定了什麼、從用詞能推論什麼、以及你今天就能拿去檢查自家系統的清單。先說清楚：神腦目前沒有公布攻擊細節，下面談手法的段落，都是依公告用詞加上業界常見案例做的推論，不代表神腦實際的入侵路徑。

神腦資安事件目前確定的事：公告只有這幾句

先講結論：神腦只公布了「外部伺服器」「自動化攻擊」「部分訂單資訊被擷取」三件事，外洩了哪些欄位、影響多少人，公告都沒有寫。下面這張表把已知和未知分開，三十秒就能看完。

原文可以看鉅亨網的重大訊息報導與 MoneyDJ 刊出的公告全文，各家媒體內容幾乎一字不差，沒有額外細節。上市櫃公司發生重大資安事件要依證交所規定發重大訊息，格式固定，所以通常只會寫到這個程度，真正的調查結果要等之後的補充說明。

值得一提的是，神腦在 2024 年 10 月也發過一次類似公告。當時同樣是外部伺服器遭到攻擊，但中央社的報導寫明「無個資或文件外洩」。兩次事件目前看不出有關聯，只能說明對外服務的伺服器，本來就是被攻擊得最頻繁的地方。

從公告用詞推敲：「自動化」「擷取」「部分」各透露什麼

公告雖然短，每個詞都把可能的範圍縮小了一點。把用詞一個一個拆開看，會比直接猜「是不是被駭客打穿」準確得多。

把這幾條拼起來，最吻合的畫面是：有人寫了一支程式，對某個對外開放的介面大量送請求，每次拿回一筆訂單，累積一段時間之後才被發現。這種攻擊不用打穿防火牆，它走的是系統本來就開著的門。

這也是這類事件最讓工程團隊頭痛的地方。每一個請求單獨拿出來看都很正常，網站應用程式防火牆（WAF）的規則不一定擋得下來。真正的問題出在「這個人有沒有權限看這筆資料」，這是商業邏輯，只有寫這套系統的人知道答案。

我們在設計自家產品線時，就是因為這樣才把權限判斷收在同一個地方。恆遠會員中樞系統把註冊、登入、訂閱和權限抽成共用中樞，新產品 1 行就能接入，不用每個產品各寫一套權限邏輯。權限只有一套，要檢查、要補洞都只改一個地方。如果你的系統權限判斷散落在每一支 API 裡，很歡迎跟我們聊聊怎麼收攏。

手法一：訂單 API 越權存取，改一個號碼就看到別人的訂單

這是我們認為最可能的一種，也是電商最常見的破口：API 只確認「這張訂單存在」，沒有確認「這張訂單是不是你的」。

資安圈把它叫做 IDOR（Insecure Direct Object Reference）或 BOLA（Broken Object Level Authorization），在 OWASP API Security Top 10 2023 排第一名。OWASP 給的建議很直接：每一個會接收外部傳入 ID 的功能，都要檢查使用者對這筆資料有沒有權限；資料的 ID 最好用隨機、猜不到的值，不要用流水號。

真實案例不難找。2026 年 4 月，TechCrunch 報導美國服飾品牌 Express 的網站，訂單頁網址裡的訂單編號是連號，只要改數字就能看到別人的姓名、電話、Email、收件與帳單地址、購買品項，還有信用卡種類與末四碼。發現的人是在追查家人帳號被盜刷時意外找到的，搜尋引擎甚至已經收錄了十幾筆別人的訂單頁。

問題出在哪一行？看下面這個常見的 Node.js 寫法就很清楚。有洞的版本只用訂單編號去查，補好的版本多比對了一個「這張訂單屬於誰」：

// 有洞的寫法：只用訂單編號查，任何登入的人都能查任何訂單
app.get('/api/orders/:id', requireLogin, async (req, res) => {
  const order = await db.order.findUnique({ where: { id: req.params.id } })
  res.json(order)
})

// 補好的寫法：同時比對訂單擁有者，查不到就當作不存在
app.get('/api/orders/:id', requireLogin, async (req, res) => {
  const order = await db.order.findFirst({
    where: { id: req.params.id, userId: req.user.id },
  })
  if (!order) return res.status(404).end()
  res.json(order)
})

兩個版本只差一個條件，但少了它，登入過的任何一個會員都能看完全站的訂單。這種洞在測試時幾乎不會被發現：開發者用自己的帳號測，永遠只會查到自己的訂單，功能完全正常。

「自動化」三個字也是在這裡發揮作用。手動改網址一次只能看一筆，寫個迴圈一小時就能跑幾萬筆。如果訂單編號是「日期加流水號」這種格式，攻擊者連猜都不用猜，照順序往下跑就好。

API 的另一個常見破口是金鑰外洩，我們在 Zeabur 資安事件白話拆解寫過完整的止血清單。兩者的共同點是：功能都正常，漏洞藏在沒人檢查的那一行。

手法二：撞庫攻擊，拿別家外洩的密碼登入你的會員

撞庫是拿其他網站外洩的帳號密碼，用程式大量嘗試登入你的網站。只要有會員在不同網站用同一組密碼，攻擊者就能登進去，看到他所有的歷史訂單。

這不是冷門手法。Verizon 在 2025 年資料外洩調查報告的延伸研究中分析 SSO 登入紀錄，發現撞庫佔每日登入嘗試的中位數是 19%，大企業高達 25%，小企業也有 12%；同一份研究指出，22% 的外洩事件是從被盜用的帳號密碼開始的。另外，Imperva 2026 年惡意機器人報告統計 2025 年自動化流量已經佔全網 53%，超過人類；27% 的機器人攻擊直接打 API，完全繞過網頁畫面。

撞庫也符合「部分」這個用詞，因為只有重複使用密碼的會員會中招。不過我們把它排第二，原因在用詞：撞庫事件的公告通常會寫「部分會員帳號遭不當登入」，神腦寫的是「訂單資訊遭擷取」，比較像資料被撈，而不像帳號被盜。實務上兩種手法常常一起出現，所以不能排除。

三種最常被混在一起講的攻擊，差別整理如下：

撞庫的根本解法在帳號治理：密碼政策、雙重驗證、異常登入通知。如果公司內部系統也有同樣的問題，可以參考我們整理的企業單一登入 SSO 完整指南，把帳號收攏到同一個入口，比每套系統各自管密碼安全得多。

手法三：免登入的訂單查詢頁，被機器人批次比對

很多電商為了方便，提供「輸入手機號碼加訂單編號就能查物流」的頁面。如果這個頁面沒有頻率限制，機器人可以拿著手機號碼清單，搭配猜得到的訂單編號大量比對。

它其實是手法一的變形：驗證條件太弱。手機號碼在過去各種外洩事件裡已經流出不少，訂單編號如果又有規律，兩個條件都等於沒設防。查詢結果如果還顯示完整姓名、地址和金額，每比對成功一次就是一筆完整個資。

防法不複雜：同一個來源短時間查太多次就擋、出現異常時才跳出人機驗證、查詢結果遮罩（王＊明、0912＊＊＊678），而且只回傳物流狀態，不回傳金額和完整地址。人機驗證怎麼選可以看我們寫的表單機器人防護採購指南，reCAPTCHA、Cloudflare Turnstile 和蜜罐各有適合的場景。

把三種手法放在一起看，跟神腦公告的吻合度，以及業主最該先做的事：

訂單資料外洩之後，詐騙電話會怎麼打

訂單資料最值錢的用途，是讓假客服聽起來像真的。對方唸得出你的名字、買的商品和下單日期，你的戒心就先降了一半。

這不是想像。2026 年 8 月 31 日，警政署 165 全民防騙專頁才示警過，詐騙集團假冒電商或金融機構，以「訂單重複設定」「持續扣款」為由，引導民眾加入假客服 LINE，再要求掃 QR Code、操作 ATM 或網路銀行（見聯合新聞網報導）。數位發展部數位產業署今年 5 月也提醒過，假客服會用「誤設批發會員」「重複扣款需要解除設定」這類說法製造恐慌。

對業主來說，外洩之後最先爆的是客服電話。事先寫好一段公告文字和客服話術，比事後補救便宜得多。今年酷澎個資外洩波及台灣用戶時也是同樣的劇本，我們在酷澎個資外洩事件的復盤裡整理過業主該準備的事。假客服也常搭配冒名 Email，公司網域的防護設定可以參考 email 冒名詐騙止血 SOP。

電商訂單 API 自查清單：這十項今天就能檢查

不用等資安廠商進場，下面十項大部分工程師半天內就能自己驗完。每一項都寫了怎麼測，測不過的就是優先要補的洞。

我們的判斷很直接：WAF、CDN 防護買得再多，也擋不住越權存取。WAF 看的是請求長得像不像攻擊，而越權的請求長得跟正常請求一模一樣。真正有效的防線寫在程式碼裡，而且要有人一支一支 API 看過。這也是我們不認同「買了資安方案就能安心」的原因。

一般的弱點掃描工具對這類洞也幫不上太多忙，因為掃描器不知道哪筆資料屬於誰。三種檢測各自抓什麼，可以看弱點掃描、滲透測試、壓力測試的差異。如果網站是 WordPress 或大量用外掛拼起來的，清單最後一項要特別注意，WordPress 被駭怎麼辦有完整的外掛防護與備份做法。

用 AI 快速做出來的系統更要小心。AI 寫出來的 API 功能測試都會過，但常常就少了擁有者檢查那一行。如果你的系統是外包或用 AI 快速做出來的，自己看不出有沒有這類洞，我們的 Vibe Coding 審計健檢會逐支檢查 IDOR 越權、資料庫權限、登入與金流流程，出一份看得懂的報告和修復優先順序。先聊聊你的系統現況，值不值得做、先看哪一塊，我們會直接告訴你。

正在規劃新電商或會員系統的話，更好的做法是在選型與驗收階段就把權限列進去。客製化電商系統與 Shopify、91APP 選型指南談過自建與平台的責任分界；多角色系統的權限與稽核軌跡怎麼驗收，可以參考政府標案系統開發跟企業案差在哪。

個資法修正後外洩要 72 小時內通報：業主要先準備什麼

先講重點：總統在 2025 年 11 月 11 日公布個資法修正條文，未來發生個資事故，要在知悉後 72 小時內通知當事人，達到門檻還要通報主管機關。理律法律事務所的整理提到，施行日期由行政院另定，細節由個人資料保護委員會的子法規定。

通報門檻與 72 小時時限出自中央社報導的辦法草案，罰則則是全國法規資料庫的第 48 條條文。實際上路時間與最終條文，請以個資會公告為準。

對中小電商來說，最實際的準備有三件事。第一，搞清楚自己保有多少筆個資，1 萬筆的門檻比想像中容易到，開站兩三年的電商大多超過。第二，存取紀錄要能回答「哪些資料被看過」。沒有紀錄的公司，出事時只能把全部會員當成受影響的人，通報與客服成本直接放大。第三，事先寫好通知範本並指定負責人，72 小時一下子就過了。

如果公司正在準備資訊安全管理制度，這三件事剛好也是 ISMS 會要求的基本功，可以搭配CNS 27001 與 ISO 27001 指南一起看。

看到這裡，如果你也在想「我們家的訂單 API 有沒有這種洞」，很歡迎把系統現況丟過來，我們陪你看從哪一支 API 開始檢查最划算。