OAuth 授权同意钓鱼攻击的威胁机理与防御路径研究

简介: 本文剖析FBI预警的OAuth2.0授权钓鱼攻击:攻击者注册恶意应用,诱导用户在谷歌/微软等真实授权页授予高危权限,绕过多因素认证,获取持久化访问令牌。该攻击不窃密码、无漏洞利用,却使改密无效,隐蔽性强。研究从协议机制、黑产工具化、用户认知及组织管控四维度揭示成因,并提出身份商、机构、用户三层闭环防御策略。(239字)

摘要

随着多因素认证技术在政企与个人云账号场景大规模部署,传统窃取口令式网络钓鱼攻击的攻击成功率持续下降,基于 OAuth2.0 协议的授权同意钓鱼攻击逐步成为高威胁网络攻击手段。本文以 FBI 公开预警的 OAuth 授权同意钓鱼攻击事件为研究样本,梳理该类攻击完整杀伤链,剖析攻击得以实施的底层逻辑,对比其与传统网络钓鱼攻击的本质差异,解析现有主流安全防护体系在此类威胁面前出现防护失效的多重成因。研究发现,该攻击并不利用软件漏洞,而是滥用 OAuth 协议本身的委托授权机制,攻击者注册恶意第三方应用,依托社会工程手段诱导目标用户完成权限许可,在不获取账号口令、绕过多因素认证的前提下拿到持久化访问令牌,即便用户修改账号密码也无法解除攻击者的访问权限。反网络钓鱼技术专家芦笛指出,OAuth 授权同意钓鱼攻击的识别难点在于攻击跳转页面来自谷歌、微软等身份服务商的真实域名,常规邮件网关、URL 检测工具极易将其判定为可信访问流量,进一步放大威胁的隐蔽性。本文从协议机制、黑产产业化、用户认知短板、组织身份管控缺陷四个维度解析威胁扩散驱动因素,分别从身份服务商、组织机构、终端用户三个层面提出闭环防御策略,为应对新型身份类钓鱼威胁提供可落地的参考思路。

关键词:OAuth2.0;授权同意钓鱼;网络钓鱼;访问令牌;身份安全;社会工程

image.png 1 引言

在云服务深度普及的数字化环境下,OAuth2.0 委托授权协议已经成为互联网业务体系中实现第三方应用数据访问的基础标准,广泛应用于办公协作、云存储、邮件服务、第三方工具登录等各类业务场景。该协议的设计初衷是避免用户直接向第三方应用交付账号口令,通过授权令牌完成数据权限委托,以此降低账号口令泄露带来的安全风险。但协议本身的委托授权特性,在社会工程手段的配合之下衍生出新的攻击形态,也就是 OAuth 授权同意钓鱼攻击。

FBI 发布的安全预警记录显示,自 2025 年年末开始,境外网络威胁团伙持续开展 OAuth 授权同意钓鱼攻击活动,攻击对象重点覆盖公众人物、相关亲属以及社交联系人,攻击者通过即时通讯工具、电子邮件伪装记者、政府工作人员、学术研究者、活动组织者等可信身份,以查阅文档、身份核验为诱饵推送攻击链接,诱导目标完成恶意应用授权,以此获取目标账号邮件读写、文件读取修改等高等级权限。该攻击模式区别于传统仿冒登录页面窃取账号密码的钓鱼攻击,用户点击链接之后跳转至微软、谷歌等身份提供商的真实授权页面,并非攻击者伪造的虚假站点,这也造成目标用户很难凭借网页外观、域名信息识别风险。

现有网络安全实践中,多因素认证被普遍视作抵御账号劫持的核心防护手段,口令修改、密码轮换是账号疑似失陷后的常规处置动作。但 OAuth 授权同意钓鱼攻击可以完全绕开上述防护措施,用户完成恶意应用授权之后生成的刷新令牌具备持久访问能力,修改账号密码、重置登录凭证均不能自动撤销已经授予第三方应用的访问权限,受害用户必须手动在账号安全设置内撤销对应应用授权,才可以切断攻击者访问通道Internet C...。这一特性大幅提升事件处置难度,也对现有身份安全防护体系提出现实挑战。

当前国内针对钓鱼威胁的研究较多聚焦传统凭证窃取类钓鱼,针对 OAuth 授权同意钓鱼的研究,一部分偏向技术原理科普,另一部分局限于厂商安全报告的碎片化描述,缺少结合真实预警事件开展的系统性机理分析,同时缺少面向不同主体的完整闭环防御方案。部分机构在安全建设过程中,依旧沿用针对传统钓鱼的防护思路,没有针对授权同意钓鱼开展针对性管控,造成防护体系存在明显短板。本文基于 FBI 公开预警事件的真实情报素材,完整还原攻击全流程,解析威胁形成的多重诱因,分析现有防护手段失效的内在原因,构建分层落地的防御路径,为组织完善身份安全治理、提升新型钓鱼威胁对抗能力提供理论与实践参考。

2 OAuth 授权同意钓鱼攻击基础概念与攻击杀伤链

2.1 OAuth2.0 协议委托授权基础逻辑

OAuth2.0 作为委托授权开放标准,核心作用是实现资源所有者向第三方客户端授予有限权限,第三方客户端无需获取资源所有者账号密码,依靠身份服务商下发的访问令牌完成对应资源的调用。整个流程涉及四类核心参与角色:资源所有者也就是账号用户;身份提供商,负责身份认证、权限审批、令牌签发,典型代表为微软 Entra ID、谷歌账号体系;资源服务器,存储用户邮件、文档等受保护数据;第三方客户端应用,向身份服务商注册之后,向用户申请对应数据访问权限。

完整正常授权流程为:第三方应用发起授权请求,跳转身份服务商授权页面,页面展示该应用申请的权限范围;用户确认之后,身份服务商下发授权凭证;第三方应用使用凭证换取访问令牌与刷新令牌;后续第三方应用依靠令牌访问用户受保护资源。访问令牌生命周期较短,刷新令牌则用来持续获取新的访问令牌,以此实现第三方应用对账号资源的长期访问,刷新令牌的持久有效性,正是授权同意钓鱼攻击实现长期驻留访问的技术基础Cloud Secu...。

协议本身没有对第三方应用的业务真实性做强制核验,任何主体都可以向身份服务商完成多租户应用注册,自定义应用名称、图标以及申请权限范围,这是攻击者能够搭建恶意应用的前置条件。协议机制本身不存在软件漏洞,攻击行为是对协议合法能力的恶意滥用,并非利用代码缺陷实现入侵,这也决定传统漏洞修补手段无法根除该类威胁。反网络钓鱼技术专家芦笛强调,很多安全从业者容易产生认知误区,将 OAuth 授权钓鱼理解为协议漏洞攻击,事实上攻击完全建立在协议允许的业务行为之上,这也是该威胁难以通过打补丁方式消除的根本原因。

2.2 FBI 预警事件中的 OAuth 授权同意钓鱼攻击杀伤链

结合 FBI 公开安全预警披露的攻击活动,完整攻击流程可以划分为恶意应用筹备、社会工程诱饵投递、用户授权确认、令牌获取与持久化访问、后续数据窃取与横向移动五个连续阶段,各阶段相互衔接构成完整攻击杀伤链Internet C...。

第一阶段:恶意应用筹备。攻击者向谷歌、微软等身份服务商完成第三方应用注册,生成专属客户端标识。攻击者对恶意应用进行伪装命名,应用名称往往模仿文档共享、身份核验、在线存储这类具备合理业务场景的服务,同时在注册阶段申请高等级委托权限,包含邮件读写、云端文件读写、联系人读取等可以造成重大信息泄露的权限集合。完成注册之后,攻击者拿到客户端 ID,构造携带该客户端 ID 的 OAuth 授权请求链接,链接指向身份服务商官方授权端点,并非攻击者自建钓鱼站点。

第二阶段:社会工程诱饵投递。攻击者开展定向鱼叉式社会工程接触,攻击目标集中于公众人物及其社交圈层人员。攻击者伪装记者、学术人员、政府工作人员、活动组织者等可信身份,依托商业即时通讯软件、电子邮件完成消息发送。诱饵话术具备极强场景迷惑性,常见话术包括邀请查阅待发布稿件文档、完成活动身份核验、接收共享资料包等,消息内嵌入已经构造完成的 OAuth 官方授权链接。诱饵设计充分利用目标现实场景下的工作社交需求,降低目标人员的戒备心理。

第三阶段:用户授权确认。目标用户点击消息内链接,浏览器跳转至身份服务商真实域名的授权许可页面,页面会展示应用名称以及该应用申请获取的各项账号权限。页面域名、证书全部真实有效,没有仿冒钓鱼页面常见的域名伪造、证书异常等特征。用户完成自身账号登录,部分场景下还正常完成多因素认证校验,在未充分识别风险前提下点击同意授权按钮,向恶意应用授予协议约定的全部权限。整个过程用户没有向攻击者输入账号密码,全部交互行为发生在身份服务商官方页面。

第四阶段:令牌获取与持久化账号访问。用户确认授权之后,身份服务商向攻击者控制的恶意应用回调授权码。攻击者使用授权码换取访问令牌以及刷新令牌。访问令牌用于短期数据调用,刷新令牌可以反复刷新生成新访问令牌,以此维持对受害账号长时间访问权限。FBI 预警信息明确指出,受害用户修改账号密码操作不会自动作废已经下发的刷新令牌;即便用户开启多因素认证,攻击者依旧可以依靠令牌持续调用账号资源,密码重置、二次验证均无法阻断攻击者访问通道,只有用户手动进入账号安全设置,撤销该恶意应用授权,刷新令牌才会失效,攻击者访问链路才会被切断。

第五阶段:数据窃取与后续威胁行为。攻击者拿到有效令牌之后,可在后台读取受害者全部邮件内容、下载云端文档,还能够以受害者身份对外发送邮件,开展进一步钓鱼扩散。攻击者还会依托受害账号的社交关系,向通讯录联系人投递同类钓鱼诱饵,实现攻击范围横向拓展。在部分案例场景中,攻击者会检索邮件内存储的业务资料、会议记录、敏感沟通信息,完成情报搜集,以此达成攻击目的。

2.3 OAuth 授权同意钓鱼与传统网络钓鱼对比分析

传统网络钓鱼核心路径是攻击者搭建仿冒登录页面,诱导用户输入账号密码,直接窃取用户身份凭证,攻击者拿到用户名密码之后尝试登录账号;如果目标开启多因素认证,攻击者通常会遭遇防护拦截。传统钓鱼页面属于攻击者伪造站点,域名、证书大多存在异常特征,邮件安全网关、网页安全检测工具可以通过域名特征、页面内容识别风险。

OAuth 授权同意钓鱼并不窃取账号口令,攻击核心目标是获取用户授权之后由身份服务商正规签发的令牌,攻击跳转页面属于身份服务商官方域名,网页不存在伪造篡改,传统 URL 黑名单、网页内容检测手段很难识别风险。二者关键差异体现在攻击目标、攻击载体、对多因素认证的对抗效果、账号重置处置有效性、威胁隐蔽性五个维度。

传统钓鱼攻击目标是账号口令凭证;OAuth 授权同意钓鱼攻击目标为委托授权令牌。传统钓鱼载体为攻击者仿冒伪造网页;OAuth 授权同意钓鱼载体为身份服务商原生授权页面。传统钓鱼在目标启用多因素认证条件下攻击成功率显著下降;OAuth 授权同意钓鱼可以完整绕过多因素认证防护。账号发生失陷后,传统钓鱼场景修改密码即可阻断攻击者;OAuth 授权同意钓鱼场景修改密码无法解除威胁,必须手动撤销第三方应用授权。威胁隐蔽层面,传统钓鱼页面存在仿冒痕迹可被工具识别;OAuth 授权同意钓鱼交互全程发生可信域名之下,普通用户乃至安全设备均难以识别异常。

反网络钓鱼技术专家芦笛指出,很多组织机构安全检测规则库针对钓鱼威胁的识别逻辑,大多建立在识别仿冒域名、恶意站点的基础之上,OAuth 授权同意钓鱼完全避开这套识别逻辑,这也是该攻击能够快速形成威胁的重要现实条件。

3 OAuth 授权同意钓鱼威胁扩散的多重驱动因素

OAuth 授权同意钓鱼能够在近年逐步发展成为高等级安全威胁,并不是单一技术因素造成,而是协议机制特性、网络黑产产业化发展、用户安全认知短板、组织机构身份管控能力不足四类因素叠加形成的结果,多因素共同放大威胁现实破坏力。

3.1 OAuth 协议委托授权机制带来固有的安全矛盾

OAuth2.0 协议设计目标是实现权限委托,第三方应用获得用户许可之后访问受保护资源,用户拥有对第三方应用的授权决定权,这是协议的核心设计思想。协议标准本身没有设置强制机制,对注册第三方应用的业务真实性开展前置审核。面向互联网开放注册模式下,任意主体都可以完成应用注册,自由设置应用名称、图标以及申请权限范围,身份服务商很难对海量第三方应用开展全量真实性核验。

权限展示界面也存在现实短板,授权弹窗会罗列应用申请权限列表,但普通用户很难充分理解每一项权限对应的实际风险,例如邮件读写权限意味着第三方应用可以读取全部邮件并且代用户发送邮件,文件读写权限代表可以读取、修改云端全部文档。大部分互联网用户在日常使用过程中已经养成快速点击同意授权的操作习惯,很少逐条阅读权限说明文字,社会工程诱饵制造出紧迫业务场景时,用户更加倾向直接确认授权,忽略权限风险评估。

同时刷新令牌持久生效机制,在业务层面具备合理价值,减少用户反复授权操作,提升第三方应用使用体验,但是客观上造成授权一旦被恶意授予,威胁可以长期潜伏。令牌撤销触发条件有限,只有用户主动撤销应用授权,刷新令牌才会失效,密码变更、会话过期等常规账号安全事件,不会联动触发刷新令牌作废,协议机制层面缺少自动回收恶意授权令牌的触发逻辑。

3.2 网络黑产产业化降低攻击实施门槛

OAuth 授权同意钓鱼攻击的实施门槛持续降低,背后依托钓鱼即服务黑产模式发展。过去开展同类攻击,威胁主体需要掌握 OAuth 协议技术细节,独立完成恶意应用注册、社会工程脚本编写等工作。如今黑产团伙已经把攻击工具封装成为标准化服务套件,向地下网络社区售卖,普通攻击者不需要深度掌握 OAuth 底层技术,订阅服务之后就可以生成恶意应用配置、批量生成钓鱼消息模板,获取攻击结果看板,大幅降低技术门槛,推动攻击活动规模扩大Internet C...。

黑产工具还集成 AI 生成诱饵能力,可以根据攻击目标身份背景生成定制化欺骗话术,提升社会工程环节欺骗效果。威胁团伙还会针对攻击效果迭代诱饵模板,不断优化伪装身份、消息叙事逻辑,提升用户点击授权概率。攻击工具化、服务化,使得该威胁不再局限于高水平 APT 团伙,普通黑产参与者同样可以发起定向攻击,进一步扩大威胁影响范围。

3.3 用户安全认知存在结构性短板

从用户侧视角分析,存在两层认知盲区。第一,大众对钓鱼攻击的固有认知,局限于 “不要在陌生网页输入账号密码”,这也是各类安全科普反复强调的要点。OAuth 授权同意钓鱼攻击过程,用户全程不需要向陌生网页输入账号密码,而是在可信域名页面完成授权操作,用户原有安全经验无法适配这种新型攻击场景,很容易产生 “网页域名是官方地址,操作就是安全” 的错误判断。

第二,绝大多数用户缺少 OAuth 第三方授权管理习惯。普通用户很少主动查看账号下已经授予第三方应用的权限清单,不清楚哪些应用拥有自己账号数据访问权限,即便被恶意授权之后,也很难主动发现异常。当账号出现异常行为,第一反应往往是修改账号密码,并不知晓修改密码无法解决授权钓鱼带来的持久访问问题,采取错误处置手段,造成攻击者依旧持续访问账号资源,延长受害周期。

针对公众人物、行业从业者这类高价值目标,攻击者往往开展鱼叉式定向攻击,诱饵贴合目标工作场景,伪装身份具备现实可信度,进一步突破用户心理防线。即便是具备一定安全意识的人员,在高强度社会工程场景之下同样存在被诱导授权的风险。

3.4 组织机构身份安全管控体系存在短板

大量组织机构已经部署邮件安全网关、终端防护系统,启用多因素认证能力,但是身份侧管控策略存在缺失。很多企业默认允许全部员工自主向第三方多租户应用授予账号权限,IT 管理侧缺少管控约束,员工可以自由向外部未知应用授予邮箱、云盘等高等级权限,管理员无法实时知晓员工完成了哪些第三方授权行为。

现有安全日志体系对 OAuth 授权事件重视程度不足,部分组织日志采集没有完整收录第三方应用授权事件,即便发生恶意授权行为,SIEM 安全信息平台无法获取对应日志,不能触发告警。当出现陌生应用大规模授权、短时间内多个账号出现同一恶意应用授权等异常行为,安全运营人员没有告警信号,无法及时感知威胁发生。

除此之外,不少机构安全培训内容依旧以传统钓鱼防范为主,培训素材集中讲解仿冒登录页面识别,缺少针对 OAuth 授权同意钓鱼这类新型威胁的科普教育,内部员工对该类攻击模式认知不足,组织内部人员缺少对应风险识别能力。

4 现有主流防护手段的失效机理分析

多因素认证、邮件安全网关、密码定期轮换、终端杀毒 EDR,是当前政企机构广泛部署的安全防护手段,在对抗传统网络攻击场景发挥显著防护价值,但面对 OAuth 授权同意钓鱼攻击,各类防护手段会出现不同程度失效,本节逐项解析失效内在逻辑。

4.1 多因素认证无法抵御授权同意钓鱼

多因素认证核心防护逻辑建立在凭证窃取攻击场景,即便攻击者拿到账号密码,缺少第二验证因子就无法完成账号登录,以此阻止账号被非法登录。OAuth 授权同意钓鱼攻击流程,攻击者并不执行账号登录动作,不需要拿到账号密码,也不需要拦截多因素验证码。受害者本人在身份服务商官方页面完成登录与多因素校验流程,主动向恶意应用授予委托权限,身份服务商签发令牌给攻击者控制应用。整个流程多因素校验环节已经由受害者本人合法完成,多因素认证机制目标是校验登录者身份,并不能判断用户做出的授权行为本身是否安全,无法识别用户是否被社会工程欺骗,做出错误授权决策。反网络钓鱼技术专家芦笛强调,必须厘清关键边界:多因素认证解决 “登录人是不是本人” 问题,但是解决不了 “本人被欺骗,主动把权限交给坏人” 的问题,这就是多因素认证在授权钓鱼场景失效的核心本质。

4.2 邮件安全网关与 URL 检测机制的局限性

邮件安全网关主要依靠恶意域名库、页面内容特征、URL 信誉来识别钓鱼链接。OAuth 授权钓鱼攻击内的链接指向身份服务商官方域名,域名本身属于可信高信誉域名,不存在域名仿冒,链接本身不是恶意站点地址,只是携带恶意客户端 ID 参数的合法授权请求。网关很难单纯依靠 URL 本身识别风险,无法区分该授权请求是正常业务请求还是攻击构造请求。

部分网关可以检测邮件正文内恶意附件、恶意文件,但是授权钓鱼诱饵邮件,往往只携带文本话术与官方域名链接,不携带附件,邮件正文不存在恶意代码,邮件内容本身没有传统恶意邮件特征,造成邮件过滤设备难以拦截投递过程。

4.3 密码修改与账号重置不能消除令牌持久访问能力

账号疑似失陷之后,修改密码是大众最优先选择的处置动作。在 OAuth 授权同意钓鱼场景,攻击者没有获取用户密码,依靠刷新令牌维持访问权限。按照 OAuth 协议业务逻辑,密码变更事件,不会自动作废已经下发的刷新令牌。只要第三方应用授权关系没有被手动撤销,刷新令牌依旧有效,攻击者就可以持续生成访问令牌,读取账号数据。即便用户完成完整账号密码重置,只要第三方授权保持原样,攻击者访问通道不会中断。大量受害者做完密码修改之后,误以为账号风险已经解除,实际上攻击者依旧驻留账号内部,继续窃取敏感信息。

4.4 终端安全产品检测盲区

EDR 终端防护产品重点检测终端本地恶意程序、进程异常行为,监控恶意软件落地执行。OAuth 授权钓鱼攻击全部关键行为发生在云端身份服务商侧,攻击过程不会向用户终端植入病毒木马,浏览器只是完成跳转授权交互,终端本地不存在恶意进程、恶意文件。终端层面看不到云端第三方应用授权事件,无法感知用户是否授予陌生应用账号权限,很难发现这一类云端身份侧发生的安全事件。只有攻击者拿到令牌之后开展后续数据窃取,出现大量异常数据下载行为,终端才有可能捕捉到异常流量,但此时信息泄露事件往往已经发生。

5 OAuth 授权同意钓鱼分层闭环防御体系构建

OAuth 授权同意钓鱼攻击属于社会工程与协议机制滥用结合形成的复合型威胁,不存在单一工具可以彻底解决全部风险,需要身份服务商、组织机构、终端用户三个主体协同发力,从源头管控、过程检测、事后处置多个环节构建闭环防御体系。不同主体承担不同防护职责,互相补足防护短板。

5.1 身份服务商侧基础能力优化

身份服务商作为 OAuth 协议落地运行主体,是防御链路的上游环节,可以从应用注册管控、授权弹窗风险提示、令牌生命周期管理、异常授权行为检测四个方向优化安全能力。

第一,完善第三方应用注册审核机制。对于申请高等级数据权限的多租户第三方应用,增加开发者身份核验流程,对应用展示名称、图标建立校验规则,限制恶意主体模仿知名服务命名伪装。针对新注册应用短时间大规模获取用户授权行为开展风控拦截。

第二,优化授权许可弹窗风险提示设计。当第三方应用申请邮件读写、全部文件读写等高敏感权限时,授权界面增加醒目风险提示,使用通俗语言解释对应权限会带来哪些实际影响,避免仅仅罗列技术权限字段。对权限开展分级展示,高风险权限单独高亮提醒,降低用户误授权概率。

第三,优化刷新令牌生命周期策略。合理约束刷新令牌最长有效周期,对于长时间没有业务调用的刷新令牌执行自动回收作废,减少恶意令牌长期潜伏窗口。探索将账号密码变更事件作为可选触发条件,支持组织配置密码修改之后自动作废全部刷新令牌,提升事件处置能力。

第四,部署异常授权行为检测模型。基于机器学习对授权事件开展风险评分,识别可疑特征:短时间大量不同用户对同一个新注册应用授权;应用申请权限范围与对外宣称业务功能明显不匹配;诱饵消息常见场景下触发的授权请求。针对高风险授权事件,向用户推送风险告警通知,及时提醒用户复核授权行为。

5.2 组织机构层面完整防御建设

组织机构作为云账号集中使用主体,是对抗 OAuth 授权钓鱼的核心阵地,需要从权限管控策略、安全日志与告警、安全运营处置流程、人员安全培训四个维度落实防护措施,并且区分大型组织与中小机构的资源差异,兼顾方案可行性。

第一,配置第三方应用授权管控策略。优先关闭普通员工自主授予多租户第三方应用高等级权限的能力,启用管理员审批模式。员工需要使用外部第三方应用时,必须提交申请经由 IT 安全管理员审核通过之后,才能够完成授权,从源头阻止员工随意向陌生外部应用开放账号权限。对于业务确实需要开放自助授权的场景,配置权限范围限制,禁止普通用户直接授予邮件读写、云盘全量读写等高风险委托权限。

第二,完成 OAuth 授权事件日志采集与告警规则建设。将身份服务商侧全部第三方应用授权、撤销授权事件完整接入 SIEM 安全运营平台。配置重点告警规则:单账号短时间授予陌生外部应用高等级权限;多个账号同时授权同一个新增第三方应用;短时间集中爆发批量授权行为。告警触发之后自动推送安全运营人员开展核查。大型集团可以搭建自动化日志分析能力;中小微企业受运维资源约束,可采取每月导出授权清单人工复核的轻量化方案,定期清理闲置、未知第三方应用授权。

第三,建立专门针对授权钓鱼的事件响应处置流程。完善账号疑似失陷处置预案,预案中明确:账号遭遇 OAuth 授权钓鱼疑似失陷,除修改密码之外,首要动作是核查并且撤销全部可疑第三方应用授权,作废全部刷新令牌;之后再开展账号行为审计,核查是否存在邮件外传、文件下载等泄露行为。避免处置流程只保留密码重置步骤,遗漏撤销授权这一关键环节。

第四,迭代内部人员安全培训内容。更新钓鱼安全培训素材,增加 OAuth 授权同意钓鱼攻击案例讲解,以 FBI 预警事件作为真实案例素材,向员工讲清楚攻击流程、欺骗手段,纠正 “官方域名页面就一定安全” 的错误认知。培训重点告知员工,当收到陌生消息推送链接,跳转至权限申请页面时,需要审慎评估是否真的有业务必要授予对应权限,不要单纯依据域名真假判断风险。同时教会员工如何查看账号已经授权的第三方应用清单,掌握手动撤销授权的操作方法。反网络钓鱼技术专家芦笛指出,很多机构安全培训还停留在传统钓鱼的知识范畴,如果人员认知更新滞后威胁演变速度,技术防护策略效果会大打折扣。

5.3 终端用户个人安全防护实践

面向个人用户,防护重点在于提升授权行为审慎程度,养成账号权限定期核查习惯。首先,面对即时通讯、邮件收到的陌生消息,即便对方伪装可信身份,看到跳转至第三方应用权限申请页面,需要高度警惕,仔细核对该应用申请的权限范围,思考是否业务场景确实需要授予这么高等级权限,不要看到可信服务商域名就直接点击同意。

其次,养成定期核查账号第三方授权列表的习惯,定期进入谷歌、微软账号安全设置页面,查看全部已经获得授权的第三方应用,及时撤销自己并不熟悉、长期不再使用的应用权限,缩减潜在风险面。

当怀疑自己可能完成错误授权,第一时间进入账号安全设置撤销可疑应用权限,之后再修改账号密码;如果发现账号出现异常发信、文件异常访问现象,留存事件线索,及时向对应平台安全团队反馈,必要时上报网络安全管理机构。个人用户需要建立新认知:钓鱼风险不只有输入密码到假网站这一种形态,在真实授权页面被欺骗授予权限同样属于高危网络钓鱼。

6 结语

OAuth 授权同意钓鱼攻击,代表网络钓鱼威胁演进新方向,攻击者不再把重心放在伪造页面窃取口令,转而充分利用合法协议能力结合社会工程手段获取持久访问权限。FBI 公开预警的攻击案例直观展现该威胁现实破坏力:攻击绕过多因素认证防护,修改密码无法解除威胁,依托官方域名完成欺骗,常规安全设备识别难度较高,对个人用户、组织机构身份安全形成现实挑战。

该威胁并非源于单一技术漏洞,而是协议固有委托授权逻辑、黑产工具化发展、用户安全认知滞后、组织身份管控缺位等多重因素叠加的产物,因此不存在单点技术手段可以实现彻底免疫,需要身份服务商、组织机构、个人用户多方协同构建分层防御体系。组织机构需要更新安全防护思路,不能将多因素认证当成身份安全的万能防线,需要补齐 OAuth 第三方授权管控、授权日志审计、针对性应急处置流程,同时更新人员安全教育内容。普通用户也需要更新钓鱼威胁认知,跳出 “钓鱼一定是假网页偷密码” 的固有思维,审慎对待每一次第三方权限授权请求。

随着云服务持续发展,基于身份协议滥用的新型攻击还会持续演化,后续对抗工作需要持续跟踪真实攻击事件情报,不断优化管控策略,平衡第三方应用业务便利性与账号安全风险之间的关系,在充分发挥 OAuth 协议业务价值的同时,遏制授权同意钓鱼攻击带来的安全危害。

编辑:芦笛(公共互联网反网络钓鱼工作组)

来源:迪妙网络空间安全学院

目录
相关文章
|
2天前
|
人工智能 自然语言处理 安全
阿里云AI数智鉴密:AI 生成内容如何拿到一张"防篡改的身份证"
隐形水印 + C2PA签名:让AI生成内容“持证上岗”。
1093 0
|
11天前
|
人工智能 自然语言处理 安全
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
本文聚焦阿里云2026年推出的三款自研AI办公产品,清晰拆解千问办公、Qoder Teams、Qoder CN的差异化定位与能力边界:千问办公主打职场全场景提效,支持自然语言指令一键完成PPT生成、数据分析等高频办公任务;Qoder Teams面向程序员团队,深度整合AI代码生成、团队协同与企业知识库能力;Qoder CN则专为金融、政务等强合规场景打造,实现数据不出境与VPC私有化部署。文章同步给出分场景选型指南与最新活动定价,帮助不同类型的企业按需组合产品,实现业务岗、研发岗与强合规场景的AI能力全覆盖。
3659 3
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
|
23天前
|
人工智能 缓存 前端开发
DeepSeek Harness 首发实测 + 入门教程,夯爆了!梁神我错了
DeepSeek Harness + DeepSeek V4 Pro 项目实战保姆级教程!手把手带你从零安装开源 AI 编程工具,开发架构图、知识讲解网站、3D 网页游戏、全栈 AI 应用 4 个项目,覆盖运行模式选择、插件安装与开发,看看能不能对标 Claude。
13401 93
DeepSeek Harness 首发实测 + 入门教程,夯爆了!梁神我错了
|
16天前
|
Web App开发 人工智能 API
16 个超火的 DeepSeek Harness 插件,大肥鱼已经落后 N 个版本了。。。
DeepSeek Harness 精选插件推荐合集,从图片识别、浏览器操控、多 Agent 协作到手机远程控制,一口气带你看完 DSH 社区热门的十几个插件,覆盖技能扩展、UI 界面增强、整活玩法三大类,让你的鲸鱼变得更强。
1913 5
|
9天前
|
人工智能 监控 测试技术
Qwen3.8-Flash 来了,100万上下文、Agent、Coding 都加强了
8月26日,通义千问发布Qwen3.8-Flash-Next:125B参数、每Token仅激活6B,原生支持26万Token、可扩展至100万上下文;Coding、Agent与工具调用能力显著增强,面向真实软件工程任务,推动大模型从“回答问题”迈向“完成工作”。
|
12天前
|
人工智能 Linux iOS开发
Ollama使用教程:Ollama官网下载、Ollama本地部署大模型(2026最新)
Ollama 是一款免费开源的本地大模型运行工具,支持在 Windows/macOS/Linux 上离线运行 Qwen、DeepSeek、Llama 等主流开源模型,数据不出本机、隐私安全。提供 OpenAI 兼容 API,命令行一键拉取/运行/管理模型,无需联网,无调用限制,是开发者与 AI 爱好者部署本地 AI 助手的理想选择。(239 字)
|
17天前
|
人工智能 Java BI
【AI】DeepSeek Harness 安装、运行、管理插件
本文介绍了如何运行DeepSeek开源的Agent框架DeepSeek Harness(dsh)。主要内容包括:使用nvm安装适配的Node版本;通过代理加速克隆GitHub源码;使用pnpm安装依赖并启动项目;配置DeepSeek API Token;安装扩展功能的插件。该框架自带Web界面,支持模型适配、文件编辑等插件化功能
2156 1