許多工程師認為，只要公司啟用了多因素驗證（MFA）或條件式存取（Conditional Access），帳號安全就有了保障。然而，近期 Microsoft 揭露的一系列針對 Salesforce 的攻擊活動顯示，攻擊者（被認為與 ShinyHunters 組織有關）完全不需要破解密碼或繞過 MFA，而是利用企業對第三方應用程式的信任，透過 OAuth 授權機制直接「走進」企業內部。
這類攻擊最危險的地方在於：由於存取權限來自於已被授權的合法應用程式，所有的登入紀錄看起來都像正常操作，傳統的身分驗證監控幾乎無法察覺。
以下將這一年來觀察到的三種主要攻擊路徑，以工程實務的角度進行拆解。
第一路徑：利用社交工程誘導授權（Vishing）
這是一種結合語音釣魚（Vishing）與 OAuth 權限請求的攻擊。攻擊者會偽裝成 IT 支援人員撥電話給員工，誘導他們在 Salesforce 的 OAuth 同意畫面（Consent Screen）點擊同意。
OAuth 是一種開放標準授權協議，允許第三方應用程式在不獲知使用者密碼的情況下，獲得有限的權限來存取資源。在這次案例中，攻擊者將惡意程式偽裝成 Salesforce 官方的 Data Loader 工具。一旦員工點擊同意，攻擊者就獲得了代表該使用者執行 API 調用的權限，進而可以列舉 CRM 資料、獲取持久性存取權，甚至搜尋其他 SaaS 平台的憑證。
這對開發者的啟示是：身分驗證（Authentication）通過並不代表操作安全。攻擊者不需要密碼，只需要一個「被信任的授權令牌（Token）」。
第二路徑：供應鏈攻擊與令牌盜取（Token Theft）
如果第一路徑是針對「人」，第二路徑則是針對「供應商」。攻擊者不再嘗試釣魚單一員工，而是直接攻破與許多企業對接的第三方軟體供應商。
當供應商的應用程式被攻破後，攻擊者會盜取儲存在供應商伺服器上的 OAuth 令牌或重新整理令牌（Refresh Tokens）。由於這些令牌已經被客戶企業預先授權，攻擊者可以使用這些令牌直接對數百家客戶的 Salesforce 環境發起查詢。
例如在 Salesloft Drift 的案例中，攻擊者先入侵 GitHub 帳號，進而進入 AWS 環境盜取令牌，隨後利用 SOQL（Salesforce Object Query Language，一種用於查詢 Salesforce 資料的類 SQL 語言）大量撈取資料，並在操作後刪除查詢紀錄以掩蓋蹤跡。這種攻擊完全繞過了終端用戶的監控，因為流量來自於企業早已信任的整合服務。
第三路徑：配置錯誤的訪客存取（Guest Access Misconfiguration）
第三種路徑不需要任何憑證或令牌，純粹利用設定漏洞。在 Salesforce Experience Cloud 的 Aura 框架中，如果訪客使用者（Guest User）的權限配置過寬，攻擊者可以直接存取 Aura 端點。
攻擊者利用 GraphQL Aura 控制器，並透過游標分頁（Cursor-based Pagination）技術，繞過標準的 2,000 筆記錄查詢限制，將本應受限的資料全部抓取出來。這本質上是一個權限控管（Access Control）失效的問題，而非技術漏洞（Exploit）。
防禦核心：從監控登入轉向監控行為
面對這三種路徑，傳統的「登入監控」已失效。我們必須將防禦重點轉移到「授權後的行為監控」。
首先是強化對連接應用程式（Connected Apps）的治理。企業應盤點所有已授權的 OAuth 應用程式，刪除超過 90 天未使用的應用，並嚴格執行最小權限原則（Least Privilege），避免給予過高的 Scope（權限範圍）。
其次是導入實時事件監控。例如透過 Salesforce Shield 或 Defender for Cloud Apps，追蹤哪個應用程式在什麼時間點調用了哪些 API，以及查詢的資料量是否異常。
最後，對於 Experience Cloud 等對外開放的端點，必須定期審核訪客權限，確保沒有任何敏感物件被設定為訪客可讀取。
總結來說，現代 SaaS 安全的漏洞往往不在於單一軟體的 Bug，而是在於複雜的整合鏈結中，那些被遺忘且權限過大的授權令牌。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。