內文
JPCERT於 10/15 公布日本連續不正存取事件的調查，確認攻擊者使用 AI 掃描已知漏洞、透過 API 發動攻擊，並在攻擊伺服器發現 APK 解析及 SSRF 測試痕跡。App 內嵌的長效金鑰、過度信任前端的 API，以及缺乏逐筆授權的後端，都是企業應優先檢查的位置。
已確認的工具： JPCERT在攻擊伺服器找到 Blutter、jadx 相關檔案，以及用於SSRF測試的 Python 程式。Blutter與jadx用於App逆向工程；這份調查沒有公開攻擊者使用的AI模型名稱。
- 01
分析 App
以Blutter、jadx等工具分析App，找出API線索
- 02
辨識 API 與資訊
整理端點、驗證流程與可能外露的機密資訊
- 03
測試與濫用
檢查 SSRF、授權或設定缺陷
- 04
觸及後端資源
可能造成未授權操作與資料存取
已確認的是 AI 輔助掃描與 API 攻擊，公開資料未證明全程由自主 Agent 執行。
阻斷重點： 每一次 API 操作都在伺服器端驗證身分與資料權限；避免將長效機密資訊放進 App；對 API 個別限流並監看異常。會代取外部網址的服務，還須檢查重新導向後的目的地，避免 SSRF 通往內網。
行動建議：從外部邊界查到內部核心
企業若共用App、API或委外後端，應將外網與內部API一併盤點；逐一核對容器、測試環境與舊版App仍可連到哪些服務。
- 01
盤點App與API
涵蓋內外部API、委外App、測試環境與跨據點服務
- 02
縮小金鑰與連線權限
移除App內長效機密，限制代取網址與內網目的地
- 03
主動測試授權
測試跨帳號資料存取、SSRF與前端信任假設
看看能怎麼應對2項資源
TWISA 會員方案
主動測試授權
檢查App暴露的長效金鑰、後端權限繞過及SSRF路徑，找出需要修正的API授權與連線限制。
- 04
修正後複測
確認後端拒絕未授權操作，對照告警與實際資料存取
盤點App版本、API端點、金鑰、委外後端與跨境資料流
業務連線依授權放行，各層分別落實防護
- 01
App與外部入口
行動App、公開API及金鑰
避免長效秘密外露App可被分析，不能把前端藏碼當作後端授權
- 02
API服務層
身分驗證與每筆資料操作
看看能怎麼應對2項資源
TWISA 會員方案
API服務層
檢查App暴露的長效金鑰、後端權限繞過及SSRF路徑，找出需要修正的API授權與連線限制。
逐筆確認權限在伺服器端核對使用者、資料與操作，不只相信App送來的參數
- 03
後端與網路出口
代取網址、重新導向及內部服務
限制SSRF路徑核對重新導向後的目的地，限制後端可連線範圍
- 04
核心資料
個資、業務紀錄及服務帳號
縮小可存取範圍分離服務權限，避免一個API帳號讀取所有資料
各層日誌與流量，送往監控與應變流程
- 記錄API操作保留使用者、端點、資料範圍與執行結果
- 關聯異常注意大量查詢、反覆授權失敗與異常外連
- 修正與複驗確認請求遭拒絕，並核對後端資料沒有被讀取或變更
防護驗證須同時看請求、告警與後端結果，不能只以出現告警判定已阻擋。
App與API：可洽詢的檢測服務
日本App／API情境：檢查前端信任與後端授權
檢查App暴露的長效金鑰、後端權限繞過及SSRF路徑，找出需要修正的API授權與連線限制。
歡迎洽詢各會員，取得更詳細的產品與服務介紹及說明。
延伸CIX：把本篇風險接上防禦行動
從App分析一路走到後端API，提醒企業把身分、逐筆資料授權與網路出口一起設計。本篇案例呼應CIX第二場Building Cyber Resilience by Design，可將API測試結果帶入交流，討論多層防禦如何落實。
建議企業資安、IT維運、開發與AI導入團隊，參加TWISA後續CIX交流會，有機會更進一步瞭解 AI 帶來的資安衝擊、如何安全於企業中使用與管理 AI 與如何將 AI 應用在資安防護上，應對遭駭客濫用的 AI 攻擊風險
AI風險系列延伸閱讀
專欄更新日期：2026/10/22。