開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶;每位用戶只可獲得一次試用。


OAuth 授權釣魚誘使你授權惡意或受攻擊者控制的 App。攻擊者不在假登入頁偷密碼,而是讓真正的身份提供者為該 App 建立權限授予。在存取被撤銷或到期前,這項授予可能讓 App 讀取資料或代你行事。
登入頁和同意頁可能真的由 Microsoft、Google 等供應商託管。這正是令人混淆之處:合法域名也會顯示危險要求,因為不可信的是第三方 App、其發佈者、所要權限,或把你引來的說法。Microsoft 把授權釣魚描述為誘騙用戶授予惡意雲端應用程式存取合法服務和用戶資料的權限。[1]
關鍵要點
- 合法的 OAuth 提示,不能證明提出要求的 App 或業務目的正當。
- 批准前,先看清發佈者、轉介來源、權限清單和存取理由。
- 更改密碼不會自動移除 OAuth 授予;要另行撤銷該 App。
- 批准後,要調查 App 能存取甚麼、實際做了甚麼,而不只看有沒有奇怪的登入。
OAuth 是授權框架,讓一項服務有限度地存取另一項服務的資源,而毋須你把帳戶密碼交給前者。例如日曆工具要求查看日曆,文件流程工具要求建立檔案。身份提供者核實你的身份,並顯示說明存取範圍的同意提示。
這個模型的保安價值在於分隔:App 取得的是代表已批准權限的權杖,而非你可重用的密碼。但分隔不代表每個要求都安全,同意本身就是保安決定。App 要求的存取超出功能所需、發佈者來歷不明,或出現在意外訊息中時,批准就可能給攻擊者一條持久取得資料的途徑。
Microsoft 區分委派存取和應用程式存取:前者代表已登入用戶行事,不能超出該用戶的存取範圍;後者以應用程式本身身份行事,毋須用戶在場。應用程式權限可涵蓋所授角色相關的資料,通常需管理員同意;高權限的委派權限也可能需要管理員批准。[2]
| 權限模型 | 應用程式以誰的身份行事 | 一般界線 | 主要審查問題 |
|---|---|---|---|
| 委派權限 | 已登入用戶 | 用戶本身的存取範圍加上已批准的權限範圍 | 這項功能需要以我的身份行事嗎? |
| 應用程式權限 | 應用程式本身 | 應用程式角色涵蓋的資源 | 背景服務為何需要這麼大的範圍? |
| 基本登入連結 | 用於登入的用戶身份 | 提示中顯示的身份或個人資料欄位 | 這是我想進入的 App 嗎? |
| 帳戶連結/資料分享 | 一項已連接的服務 | 特定的分享資料和持續連結 | 日後能否移除這個連接?移除後還剩下甚麼? |
攻擊者先註冊或攻陷一個 App,設定將要求的權限,再編造藉口:共用文件、保安更新、語音留言、報銷單、會議工具、招聘檔案或必需的整合。連結把目標帶進授權流程。認證可能在真正的供應商那裏進行,受害者看到熟悉的品牌,戒心隨之降低。
同意頁顯示 App 名稱並列出所要求的存取。攻擊者依賴對提示的麻木、含糊的 App 名稱、眼熟的標誌或看似可信的發送者。一旦批准,供應商便記錄授予並按平台規則發出權杖。之後 App 可能讀取電郵、檔案、聯絡人、個人資料或權限範圍內的其他資源,並可靜悄悄使用,毋須任何假密碼頁面。
所以這種攻擊不只是一般釣魚。密碼可能從未離開供應商,MFA 也可能完全按設計運作,造成損害的是授權決定。如果誘餌同時收集了憑證或工作階段資料,就可能有多條攻擊途徑並存,需要分別清理。
檢查在提示出現前已經開始。你是否從可信目錄、官方網站或已知工作流程主動開啟這個 App?即使託管方是真的,從主動傳來的電郵進入的同意頁風險也較高。任務出乎意料時,請透過獨立途徑向發送者確認。
然後檢查四項。一是 App 名稱:「文件檢視器」之類的通用名稱不能證明身份。二是發佈者和域名:優先揀選能對應真正供應商的發佈者,但驗證只減低不確定性,不保證行為。三是所要求的權限:逐項與所需功能對照。四是範圍和時長:留意離線存取、電郵信箱、檔案、目錄、聯絡人、代發電郵或管理權限。
| 訊號 | 風險較低的模式 | 風險較高的模式 |
|---|---|---|
| 進入途徑 | 你由已知 App 或管理員目錄開始 | 主動傳來的電郵、聊天訊息、QR code 或共用檔案 |
| 發佈者 | 預期中的機構,域名相符 | 不明、拼錯、新出現或與任務無關 |
| 權限 | 功能所需的窄範圍存取 | 無需要卻要求電郵、檔案、聯絡人、代發或廣泛的「全部」存取 |
| 時機 | 在啟用某項功能時要求 | 與目前任務無關的緊急批准 |
| 說明 | 清楚的資料用途和支援資訊 | 理由含糊、抄襲品牌,或催促批准 |
不要把「已驗證發佈者」當作自動批准的按鈕。Microsoft 建議,即使是已驗證發佈者,也要核實來源並審查所要求的權限。最小權限是切實可行的原則:功能無法說明為何需要這些存取,就拒絕要求。
密碼在認證時證明身份,OAuth 授予則記錄對 App 的授權,兩者相關但不同。更改密碼能保護日後以密碼進行的登入,也可能影響部分工作階段,但供應商仍可能承認該 App 現有的同意及更新權杖關係。刪除本機 App 或瀏覽器 Cookie,也未必能移除伺服器端的授予。
因此應對要雙線進行:如憑證或工作階段可能外洩,就保護身份;同時在帳戶的已連接 App 或企業應用程式控制中,另行移除可疑 App 的存取。例如,Google 讓用戶在 Google 帳戶的連接設定中查看已連結的 App、檢查存取、移除存取及舉報 App。[3]
撤銷沒有追溯力:它能阻止日後的存取,但無法取回已讀取的資料、收回已發出的電郵,或刪除存於別處的副本。部分供應商亦說明,移除登入連結不會刪除第三方服務儲存的資料。資料保留很重要時,請查看供應商的說明,並聯絡 App 營辦者或你的管理員。
在已知裝置上操作,並自行輸入供應商地址,不要經原本的訊息返回。如安全可行,移除前記下 App 名稱、發佈者、權限、批准時間、誘餌,以及顯示出的應用程式或租用戶識別碼。
| 暴露程度 | 用戶行動 | 管理員或資訊保安團隊行動 |
|---|---|---|
| 開啟了提示但未批准 | 關閉並舉報誘餌 | 如屬機構帳戶,封鎖或調查該 App 和發送者 |
| 批准了低範圍授予 | 撤銷連接;查看近期活動 | 確認已授予的範圍和權杖活動 |
| 電郵、檔案、聯絡人或代發權限 | 撤銷;檢查受影響的資料、規則、寄件備份和分享 | 檢查稽核和登入紀錄;保留證據;按要求通知資料擁有人 |
| 廣泛或管理員同意,或有濫用跡象 | 立即聯絡資訊保安團隊;保護帳戶和復原方式 | 按情況停用 App 或服務主體,撤銷授予和權杖,在所有用戶中搜查,評估披露責任 |
如果誘餌也收集了密碼,請更改密碼並撤銷不明的工作階段。看到陌生登入時,請按有人登入了我的帳戶中的復原檢查處理。檢查收件匣轉寄、委派人、檔案分享、帳戶復原資料和新連結的 App。擁有讀取電郵權限的 App,即使從未更改帳戶密碼,也能取得足夠資訊支援進一步的社交工程。
工作或學校帳戶方面,不要以為面向用戶的連接頁能顯示整個租用戶所受的影響。請附上時間報告事件,讓管理員檢查同意紀錄、應用程式物件、權限類型、稽核事件、權杖使用,以及授權過同一 App 的其他用戶。在某些停用情況下,現有存取權杖仍可能有效一段時間,因此事故應變應遵從供應商最新的撤銷指引。
機構應盤點第三方 App,並決定哪些用戶可授予哪些權限。只在權限風險較低且條件可信時容許用戶自行同意;較高風險的要求應經管理員審查流程。定期檢視舊授予、閒置 App、發佈者狀態、權限級別,以及登入或資料存取異常。
培訓要傳達一個實際的訊息:供應商域名可以是真的,要求卻是惡意的。教員工把權限與業務任務對照,並在不批准的情況下舉報 App。為合法的軟件申請提供快速途徑,以免繞過審查的壓力變成常態。
技術控制應落實最小權限、限制高風險同意、監察異常授予,並保留有用的稽核資料。亦應把竊取工作階段權杖的攻擊和憑證竊取視為另外的攻擊途徑。網絡安全指南提供周邊的帳戶和復原基線;App 管治則補上授權這一層。
不是。OAuth 讓 App 取得限定範圍的授權,毋須把可重用的密碼交給每個 App。風險來自批准不可信的 App、過多權限、薄弱管治或實作缺陷。
MFA 能保護認證,但不會決定 App 是否值得授權。用戶可以順利完成 MFA,然後批准惡意的權限要求。
託管頁面的一方可能合法,提出要求的 App 卻未必。請核實 App、發佈者、來源、權限清單和業務目的。
委派權限讓 App 在已登入用戶的存取範圍內代表該用戶行事。應用程式權限讓它毋須用戶登入、以本身身份行事,可能涵蓋更廣的租用戶範圍。
未必。請透過身份提供者或機構的控制移除伺服器端的連接或同意授予,再確認存取確已移除。
如憑證可能已暴露就要改,但也必須撤銷該 App。對授權授予而言,單改密碼並非完整的處理。
不能。撤銷只阻止該授予日後的授權存取,不會抹走先前的匯出或操作。請調查 App 可存取的資料和實際活動。
工作或學校帳戶出現任何可疑 App、廣泛的電郵、檔案或目錄存取、管理員同意、濫用證據,或你無法自行撤銷的要求時,都應聯絡管理員。
本文解釋一般授權風險,並非特定供應商的事故處理。權限名稱和撤銷行為會改變,請使用供應商最新的控制和機構的資訊保安流程。
Sources checked 2026 年 8 月 28 日。
註冊即可免費體驗全部高級功能。
*只限新用戶;每位用戶只可獲得一次試用。