没有合适的资源?快使用搜索试试~ 我知道了~
1553本作品采用知识共享署名-非商业性使用-相同方式共享国际4.0许可协议进行许可。DISTINCT:在双窗口单点登录中使用浏览器内通信的身份盗窃路易·詹内特Ruhr UniversityBochumlouis. rub.de摘要Vladislav Mladenov鲁 尔 大 学 波 鸿 vladislav.rub.de波鸿鲁尔大学christian.mainka@ rub.de约尔格·施温克鲁尔大学波鸿joerg. rub.de单点登录(SSO)协议,如OAuth 2.0和OpenID Connect1.0是现代网络安全的基石,并受到学术界的广泛关注。 用户在受信任的身份提供商(IdP)处登录,该身份提供商随后允许许多服务提供商(SP)验证用户的身份。 以前的研究集中在标准化(本文称为教科书SSO)的身份验证流上,它依赖于HTTP重定向在SP和IdP之间传输身份令牌。然而,像单页应用程序这样的现代Web应用程序可能无法执行教科书流程,因为它们在HTTP重定向的情况下会丢失本地状态。通过使用新的浏览器技术,如postMessage,开发人员设计和实现了既没有文档记录也没有彻底分析我们称之为双窗口SSO流。在本文中,我们提供了双窗口SSO流的第一个全面的评估特别是,我们专注于浏览器内通信(InBC),用于在iframe和弹出窗口中交换SP和IdP之间的身份验证令牌。 我们通过开发D I st I nct(一种动态分析作为SSO流的一部分执行的JavaScript代码的工具)来自动化分析。DI stI nct将流转换为描述所有通信实体及其交换的消息的序列图,突出不安全的通信信道,并量化双窗口SSO流中的新威胁。 我们发现,TrancoTop1k列表中有56%的SP支持双窗口SSO。令人惊讶的是,28%的SP在没有使用官方SDK的情况下实现了双窗口SSO,导致这些自我实现的SP中有31%的身份盗窃和XSS。CCS概念• 信息系统→Web应用程序;·安全与保密→认证;授权;Web应用程序安全。关键词单点登录; OAuth; OpenID Connect; Web安全;身份ACM参考格式:Louis Jannett , Vladislav Mladenov , Christian Mainka , and JörgSchwenk.2022. DISTINCT:在双窗口单点登录中使用浏览器内通信的身份盗窃。在2022年ACM SIGSAC计算机和通信安全会议(CCS '22)的会议记录中,2022年11月7日至11日,美国加利福尼亚州洛杉矶。ACM,纽约州纽约市,美国,15页。https://doi.org/10.1145/3548606.3560692CCS©2022版权归所有者/作者所有。ACM ISBN978-1-4503-9450-5/22/11。https://doi.org/10.1145/3548606.3560692图1:教科书与双窗口SSO身份验证流程。教科书SSO使用标准化的基于HTTP重定向的通信将登录响应中的令牌从IdP传输到SP。相比之下,双窗口SSO使用iframe和popup流,它们依赖于浏览器内通信(InBC)技术(如postMessage)来在不同的窗口之间交换令牌。1引言教科书单点登录。单点登录(Single Sign-On,SSO)是一种常用且广泛流行的网站用户认证方案。2022年,大卫·G. Balash等人[8]显示,他们招募的参与者中有86%在至少一个网站上使用Google的SSO服务。在Tranco Top 1k列表中,大约有四分之一的网站实现了SSO,以通过Apple,Facebook和Google对用户进行身份验证。§6)。 为了开始认证,用户点击服务提供商(SP)网站上的登录按钮(参见图1)。然后,SP将用户的浏览器切换到身份提供商(IdP)并发送登录请求。 用户登录IdP并同意IdP可以与SP共享个人数据。最后,IdP将用户的浏览器在教科书SSO流程中,如OAuth 2.0 ( OAuth )和OpenID Connect 1.0 ( OIDC )规范[24,58]中定义的,登录请求和登录响应在技术上是HTTP重定向。这种类型的令牌交换的安全性得到了很好的研究,并且已经由安全社区[3,5,13,37,38,39,45,71,76]和标准化机构[40,41,78]解决。然而,我们发现,超过一半的网站与SSO偏离这些规范,因此,不包括以前的工作。CCSLouis Jannett、Vladislav Mladenov、Christian Mainka和JörgSchwenk1554双窗口单点登录。Web应用程序正不断向更像应用程序的体验转变例如,像Reddit这样的单页应用程序(SPA)在不重新加载浏览器主窗口的情况下更改其本地状态(包括URL地址栏)。在这些情况下,依赖于HTTP重定向的教科书SSO [24,58]不再可行。因此,网站开发人员必须在iframe或弹出窗口中执行SSO流(参见图1)。这种流的主要挑战是来自IdP弹出窗口的令牌传输/iframe 到 SP 因此, Web 应 用 程 序 使 用 几 种 浏 览 器 内 通 信(InBC)技术,例如postMessage和Channel Messaging。如果这种流使用InBC而不是HTTP通信,我们称之为双窗口SSO流。在本文中,我们专注于这些技术的安全性在SSO的上下文中 我们调查的令牌交换,这是最关键的一部分,单点登录认证流程。如果令牌泄漏给攻击者,则可能发生帐户接管。监控浏览器内通信。InBC不会生成任何HTTP流量。因此,安全分析师无法使用HTTP代理(如OWASP ZAP [55])来监视和分析此通信。 有一些工具,如PMForce [64] 或Burpsuite 的DOMinvader [56],它们使用动态代码执行来检测postMessage通信接收端的错误配置。 在本文中,我们集中在发送端的分析,并考虑进一步的InBC技术超越postMessage(参见。(见第3.3节)。 为此,我们开发了一种新的工具,用于在Web浏览器中的动态代码分析:D I st I nct可以记录和分析在SSO流中涉及的所有窗口之间的InBC。浏览器内通信的安全性。跨源InBC技术允许不同源的窗口交换消息。它提供了同源策略(SOP)的受控放松,该策略保护网站不被其他跨源网站访问最著名的InBC技术是post-Message[51]。当在SSO协议中使用时,postMessage支持SP和IdP之间的跨源通信-完全没有HTTP重定向。 与任何交换令牌的身份验证协议一样,SSO设置了严格的安全要求。虽然postMessage提供了安全检查来满足这些需求,例如消息的机密性和真实性,但这些检查是可选的,开发人员必须手动实现它们。先前的工作[23,52,63,64,66]揭示了缺乏“默认安全”方法是网站上的如果在SSO中不能保证消息机密性则导致身份盗窃的令牌泄漏是最突出的威胁。研究问题。最近的研究研究了InBC的安全性[52,64]。 它侧重于如何保护接收者免受恶意数据注入。我们在两个维度上扩展这项工作首先,我们研究了在通过SSO进行用户身份验证的上下文中InBC的安全性,SSO自动使InBC消息的实际内容与安全相关。其次,我们关注InBC中发送者的保护,这一点尚未引起学术界的广泛关注。因此,我们回答了以下研究问题:(1) 如何实现双窗口SSO流?(2) 如何自动分析双窗口SSO流(3) 有多少网站实现了双窗口SSO?(4) 双窗口SSO实现的安全性如何?RQ 1:双窗口SSO中InBC的系统化。在§3,我们强调教科书SSO和双窗口SSO之间的差异。 我们根据窗口的类型(iframe与弹出)和InBC技术(即,postMessage,JSNavigate)。最后,我们系统化了9种用于浏览器内令牌交换的不同技术据我们所知,我们是第一个提供这种深入分析的。RQ2:分析方法。以前的研究详细阐述了使用自动HTTP流量检查分析教科书SSO的技术[37,45,57,62,76]。由于InBC不会引起任何HTTP流量,因此这些方法达到了它们的极限。我们填补了这一空白,§5通过展示开源工具DI stI nct。我们使用类似于Steffens等人的动态代码检查[64]但与他们相反,我们也监视发送方。 我们进一步研究了另外八种同源和跨源InBC技术,其中postMessage只是一种特殊但重要的情况。DI stI nct可视化并自动分析复杂的SSO登录流程,突出显示不安全的InBC,并生成漏洞。RQ3:双窗口SSO在野外。我们的目标是检测,分析,情境化,并评估在SSO的InBC。我们使用D I st I nct来评估五个广泛部署的SSO JavaScript SDK和在Tranco top1k网站上的SSO实现,其中27%支持SSO。该测试集的大小与最近对SSO的研究相当(参见§6)。我们发现,56%的支持SSO的网站使用InBC。这种分布证明了先前工作中的重大差距。 我们的结果总结在表2中。RQ4:安全评估。SSO实现中的安全漏洞可能会造成严重后果,甚至在SP上完全模仿受害者。基于第4节中对不同双窗口SSO流的安全分析,我们创建了一个需求目录,涵盖了InBC需要完成的安全检查。在我们的评估(第7节)中,我们区分了使用官方SDK的SP和手动实现SSO的SP 正如预期的那样,我们在基于SDK的使用中没有发现任何安全问题。然而,我们在31%的网站中发现了漏洞,这些网站在其SSO流中手动实现了InBC这些漏洞从隐私泄露到令牌盗窃,导致未经授权的访问和帐户接管。 我们在表3中总结了我们的发现。捐款. 我们做出以下贡献:► 我们是第一个在OAuth和OIDC中系统化双窗口SSO流程的公司。它们偏离了教科书中的SSO规范,依赖于InBC而不是HTTP重定向,并且在以前的研究中没有得到彻底的研究(§3)。► 我们展示了Web安全威胁如何影响双窗口SSO的安全性,并介绍了对双窗口SSO的攻击,这些攻击尚未成为SSO社区的焦点(§4)。► 我们提出了D I st I nct,这是第一个开源1工具,可以自动检测和分析SSO中的InBC。在上面,迪-TINCT可以自动识别易受攻击的流,并提供描述通信实体的概念利用和序列图的证明(§5)。► 我们评估了Tranco顶级1K网站,并提出了实施SSO流的景观。我们的调查显示,56%的SP部署了双窗口SSO(第6节)。1D I st I ncthttps://github.com/RUB-NDS/DISTINCT。 我们还提供了一个网站,在www.example.com上运行公开演示https://distinct-sso.com。DISTINCT:在双窗口单点登录中使用浏览器内通信的身份盗窃CCS1555► 我们在24 个高排名网站中发现了漏洞,如alibaba.com 、aliexpress.com和nytimes.com,并调查了五个流行的SSOSDK的安全性(§7)。责任披露。我们向各网站运营商协调披露已识别的漏洞,并帮助修复这些漏洞。2背景:教科书SSO流程术语SSO通常指[24,58]中指定的教科书SSO流,其使用基于HTTP的通信技术。在纸技术范围IFrame/弹出积极使用1自动威胁警告模型分析方法特别是,教科书中的SSO流的特征在于登录流,该登录流(1)使用URL重定向在IdP和SP之间交换消息,以及(2)完全在单个窗口(主窗口)中执行(参见图1)。 SP向IdP发送登录请求,如果用户同意,IdP通过用户的浏览器向SP返回登录响应。登录响应包含敏感令牌(例如, code、id_token、access_token),用于在SP上对用户进行身份验证。基于HTTP的通信技术SSO的一般目的是将IdP上的用户身份验证传输回SP。其潜在的挑战是使用一种通信技术,允许将SSO消息从一个网站传输到另一个网站。在教科书SSO中,使用从IdP到SP的URL重定向以及专用参数(例如,代码或ID_token)。例如,URL重定向可以通过服务器发起的HTTP/302)或使用HTML(例如,通过Meta>或form>)。尽管重定向的发起者和接收者的来源可能不同,因此重定向可以跨来源传输SSO消息,但这种技术只能在同一个窗口对象中工作。因此,它用于教科书SSO的主窗口中。另一种流行的基于HTTP的通信技术是CORS,但在教科书SSO流程中没有使用。3双窗口单点登录流程在本节中,我们将首先介绍双窗口SSO流程。 这些流量与教科书流量有着本质的区别,对单点登录的安全性和隐私性造成了严重的影响。我们在许多现代Web应用程序(如SPA)中发现了这些流,这些应用程序不希望通过将用户重定向到其IdP而失去对主窗口的控制。通过双窗口SSO,开发人员可以使用弹出窗口或iframe在登录过程中控制主窗口我们问自己这些双窗口流程是如何工作的,因为它们需要对标准化的通信技术进行严格的更改例如,教科书SSO使用的URL重定向不再可行,因为它们无法跨多个窗口进行通信。据我们所知,我们是第一个提供双窗口SSO流(如弹出流(§3.1)和iframe流(§3.2))的系统研究的人。教科书与双窗口SSO。教科书协议流一直是在以前的作品的主要目标。研究人员和渗透测试人员在其实现中发现了几个安全问题[3,5,11,16,17,34,35,36,37,39,42,45,61,68,70,71,73,75,76]和规范[13,15,25,44,53],范围从简单的重放攻击到复杂的认证绕过。因此,他们检查了HTTP流量。相反,我们发现双窗口SSO1自定义或过时的SSO协议被视为未被积极使用。FBC:Facebook ConnectGFC:Google Friend ConnectWA:标准Web攻击模型[1]WA+:扩展Web攻击模型JS Ex.:需 要 不受信任的JavaScript执行表1:依赖于InBC的SSO协议的先前工作本文研究了双窗口单点登录的,介绍了带用户交互的iframe流程和两个基于OAuth和OIDC的弹出流程,并开源了一个自动捕获、分析和利用双窗口单点登录中InBC的工具使用浏览器内通信(InBC)技术在两个窗口(例如主窗口和登录弹出窗口)之间交换SSO消息。 这些消息在HTTP流量中不可见,因此在其分析中被遗漏。我们的研究通过强调在双窗口Web SSO中使用InBC的风险来补充这些工作。双窗口单次同步振荡的初步研究 除了教科书SSO之外,还有关于在iframe和popups中执行的SSO协议的初步研究[12,14,19,23,71]。表1概述了这些建议。我们在§8中提供了与相关作品的更全面的比较。总之,我们的工作在以下方面有所不同:(1)考虑最先进的技术;(2)另外调查自定义SP实现;(3)引入尚未成为SSO社区关注的新流程;(4)假设Web攻击者具有低exploit要求;(5)自动分析和利用双窗口SSO中的InBC。3.1基于弹出窗口的单点登录流程图1描述了弹出流。一旦用户开始登录SP的网站,主窗口将打开IdP的弹出窗口。用户在IdP上进行身份验证并同意SP对资源的访问权限。然后,弹出流终止并且弹出从IdP接收登录响应。 由于用户希望向在主窗口中运行的SP进行身份验证,因此弹出窗口必须返回已建立的身份验证。 这种返回依赖于弹出窗口和主窗口之间的InBC。在实践中,有两种变体在弹出流中执行InBC。(1) 直接弹出流:IdP使用InBC直接与SP通信,将登录响应从弹出窗口返回到主窗口。此变体不要求SP在弹出窗口中充当中继过期的规范草案[26,30,74]已经在抽象层面上描述了该流程。(2) 中继弹出流:IdP在弹出窗口中使用基于HTTP通信的URL重定向来返回[23日]FBC、GFCIDP✓ 联系我们✗✗WA手动源代码分析-[第七十一章]FBCIDP中文(简体)✗✗WA妹妹,逆向工程手动分析Flash-[14个]BrowserID IDP&中文(简体)✗✗WA+基于InBC正式模型、手册亲-[12个]SPRESSOSPIDP&中文(简体)✗✗WA+母育分析新SSO协议,正式[19个]OAuth,SPIDP✓ 联系我们✓✗JS Ex.模型人工评价员额CCSLouis Jannett、Vladislav Mladenov、Christian Mainka和JörgSchwenk15563≥ ≥≥登录响应SP。然后,在弹出窗口中加载的SP使用InBC将登录响应从弹出窗口转发回主窗口。这种流动既不是标准化的,也不是任何先前研究的主题。3.2基于IFrame的单点登录流程图 1 描 述 了 iframe 流 程 。 它 的工 作 原 理 类 似 于 它 的 popupequivalent,但它是在iframe而不是popup中执行的。因此,登录请求在SP网站上嵌入的iframe中打开用户可以选择在iframe中进行身份验证和同意,而无需在主窗口中运行网站最后,iframe与其父框架通信以返回登录响应。基于iframe的流程可以显著改善网站的登录体验。 我们区分两种变体,每种变体都提供不同的登录体验。(1) 无缝IFrame流:如果用户在IdP登录并已授予同意,例如,SP上的帐户,iframe流可以提供无缝登录体验。 当iframe接收到登录请求时,IdP静默地认证用户并立即向SP返回登录响应(即,跳过图1中的B2 在这种情况下,SP可以使iframe不可见,使得用户从无缝的自动登录中获益。(2) 交互式IFrame流程:如果缺少IdP处的身份验证或同意,则用户需要与IdP的iframe进行交互点击同意按钮。所需的用户与iframe的交互有一个显著的缺点。 它允许UI修复和点击劫持攻击[24,§4.4.1.9],其中攻击者欺骗受害者在没有注意到它的情况下与iframe进行交互,例如,通过欺诈获得同意和令牌。社区了解这些攻击,并使用X-Frame-Options或框架锚定器CSP等对策来缓解它们[40,§ 4.15]。这些对策是破坏性的,因为它们禁止嵌入同意页面。然而,我们发现Intersection Observer v2API 2 [65]允许嵌入式iframe以非破坏性的方式增强其完整性并减轻点击劫持风险。iframe 如果API返回一个积极的指示符,它保证了iframe对用户的无障碍可见性。3.3浏览器内通信技术双窗口SSO使用InBC技术(如postMessage和浏览器内存储容器)来传输和存储身份验证代币各种InBC技术已经在不同的研究范围内[4,79],我们将其用作我们分析的起点我们扩展、系统化并描述了所有可用于传输身份验证令牌的InBC方法。术语.(1) 发起方开始通信。 这是DOM中的任何窗口对象3,如主窗口,iframe或popup。发起者在SSO中,这是IdP2Intersection Observer v2 API可在基于Chromium的浏览器中使用,如Edgev79、Chromev74 和 Operav62 ( caniuse.com/intersectionobserver-v2 ) 。https://html.spec.whatwg.org/multipage/window-object.html第https://html.spec.whatwg.org/multipage/origin.html(2) 接收方是发起方的通信伙伴同样,它可以是任何窗口对象。接收方 它可以与发起者的源具有相同的源,也可以具有不同的源,我们称之为跨源情况。(3) 发起方和接收方之间的InBC使用专用技术。常用的技术有postMessage、Channel Mess- saging、JS Direct Access、JS Storage和JS Navigatevia the location技术的选择影响通信跨域InBC技术对于SSO来说是令人兴奋的,因为IdP希望发送令牌来在跨域SP上对用户进行身份验证 只有当发起方和接收方共享同一来源时,才可以使用同源InBC技术。值得注意的是,所有跨源技术也适用于同源情况。(4) 技术意味着将浏览器内消息(InBM)从发起者传输到接收者。在SSO的上下文中,IdP和SP通常交换令牌。 在本文中,我们专注于必须保持安全并防止被恶意行为者接收的InBM,例如令牌和用户数据。安全相关的InBC技术。InBC技术必须满足两个安全相关的要求:(1)InBC技术必须适用于跨源通信。例如,攻击者的网站与被攻击的网站位于不同的来源(参见第4.1节)。请注意,如果网站使用同源InBC技术,则SOP本质上可以防止其他潜在恶意源发送和接收InBM。因此,我们认为所有同源InBC技术都是安全的。(2)InBC技术必须能够发送包含字符串或对象等数据的InBM否则,攻击者既不能接收机密InBM(如身份验证令牌),也不能将恶意构建的InBM发送到易受攻击的接收器。 两种InBC技术-跨域Web消息传递和JS导航-满足了与双窗口SSO安全性相关的两个要求。(1) 跨域Web消息传递:我们发现有两种JavaScript方法可以归入这种技术。它包括后消息API [51]和通道消息API [47]。 这些API被设计用于两个win-win之间的跨域通信。发起者可以通过调用每个窗口提供的postMessage(message,receiverOrigin)方法向接收者发送postMessage接收方可以侦听“消息”事件以检索 InBM 。 信 道 消 息 传递 的 工 作 原 理类 似 。 通 过 调 用 newMessageChannel(),发起者创建一个具有两个纠缠端口的通道。一个端口被传送到接收器(例如, 使用postMessage),从而提供双向通信信道。(2) JS Navigate:这种技术允许发起方使用JavaScript将接收方导航到任意URL特别是,SOP允许对window.location属性进行跨域写访问[50]。 通过设置window.location属性,可以使用查询或片段参数将InBM附加到URL。 与URL重定向相反,浏览器可以使用JavaScript来导航不同的窗口对象(例如,弹出窗口和iframe),使其适用于双窗口SSO流。此外,JS Navigate的行为特殊,如果它只改变URL的片段。 在这种情况下,接收器窗口不会重新加载,但会通过“hashchange”事件通知其片段中的更改。1557DISTINCT:在双窗口单点登录CCS'22中使用浏览器内通信的身份盗窃安全的InBC技术。跨源JS属性技术允许发起者查询接收者的某些DOM属性。例如,SOP允许对frames.length和window.closed属性进行跨源读取访问[27,29,67]。 根据同源技术,我们确定了同源Web消息,它包含广播消息API [46]和JS自定义事件[48]。这两个API的工作方式类似于postMessage,但仅适用于同源通信。使用JS Direct Access,(1)接收方可以公开初始方调用的JavaScript回调函数,或者(2)初始方可以在接收方的DOM中设置属性。 通过使用JS Storage,发起方可以将InBM存储在localStorage、sessionStorage、IndexedDB和cook-ies等存储容器中,接收方可以检索它们。JS插件让发起者告诉接收者重新加载它的页面,即,使用location.reload()函数。4双窗口单点登录的安全性我们提出了双窗口SSO在教科书安全考虑因素之上引入的新攻击面[40,41]。因此,我们使用我们在§3中对双窗口SSO流的研究作为基础。4.1威胁模型我们依赖于Akhawe,Barth,Lam,Mitchell和Song提出的Web攻击者模型[1]。在下文中,我们揭示了Web攻击者的能力,方法和目标的抽象概述。网 络 攻 击 者 。 攻 击 者 拥 有 一 个 恶 意 网 站 , 例 如attacker.com,并可以引诱受害者访问它。 与以前的研究[19,20,21]相反,攻击者无法在被攻击的网站上执行JavaScript,例如sp.com。我们进一步排除软件或硬件缺陷,我们假设符合标准,不妥协的Web浏览器和安全TLS。受害者受害者使用SSO 在诚实SP 的网站上进行身份验证sp.com)上提供。 我们假设受害者在IdP登录(即,idp.com)并提供同意,即, 允许IdP与诚实的SP共享个人数据。因此,SSO认证无缝地发生,并且没有任何用户交互。 为此,本节中介绍的攻击不需要受害者与IdP或SP进行交互。方法和目标。 我们假设SSO流使用InBC技术在SP和IdP之间交换InBM。攻击者首先通过iframe或弹出窗口将SP或IdP的端点嵌入恶意网站。受害者加载恶意网站,该网站利用InBC的安全检查不足来(1)发送消息,破坏消息真实性,或(2)接收消息,破坏消息机密性。例如,attacker.com与sp.com或idp.com通信 如果恶意网站可以接收到安全相关的SSO消息,我们认为攻击是恶意的。类似地,如果恶意站点可以发送被接收方接受的这样的SSO消息,则攻击成功4.2InBC技术的安全性跨域Web消息传递的安全性。PostMessage和Channel Messaging是跨源InBC最方便的技术,并且由浏览器专门为此目的而设计这两个API都可以交换任意InBM,其中可能包括令牌等机密数据。(1) PostMessage:虽然postMessage允许强制执行InBM的机密性和真实性,但默认情况下不提供这些保证。 为了实现机密性,例如防止其他来源接收postMessage,发起者必须在postMessage调用中显式设置接收者的来源(接收者来源检查):receiverWindow.postMessage(InBM,“https://receiver.com“)为了确保真实性,例如,确保接收到的post-Message实际上是由预期的发起者发送的,接收者必须在postMessage处理程序中显式地验证发起者receiverWindow.onmessage=(InBM)=>{if(InBM.origin!==“https://initiator.com“)返回}(2) 信道消息传递:发起方创建一个新的具有两个纠缠端口的信道,并通过postMessage将一个端口传输给接收方。 所有发送到该通道或从该通道接收的InBM都是机密和真实的,因为只有拥有端口的两个起源可以通过该通道进行通信。因此,通道消息传递API的安全性依赖于传输端口的postMessage的机密性和真实性。JS Navigate的安全性 SOP允许每个窗口设置其他跨域窗口的window.location属性。例如,发起方可以如下设置接收方的位置:receiverWindow.location =“https://receiver.com/recv? InBM#InBM”InBM 可 以 包 含 在 URL 的 查 询 或 片 段 中 接 收 器 通 过 读 取 其window.location属性来提取InBM由发起方指定的URL固有地保证了机密性,因为InBM被显式地发送到receiver.com。然而,接收方不能确定并因此验证设置位置属性的发起方,这破坏了InBM的真实性。在实践中,众所周知的跨站点请求伪造(CSRF)保护机制,如CSRF令牌,弥补了这种真实性的损失。他们的概念简单而有效:(1)发起者和接收者共享一个共同的秘密。(2)每当发起者设置接收者的位置时,它将秘密包括在InBM中。(3)接收方从InBM中提取秘密并对其进行验证 如果验证成功,则接收方可以推断InBM实际上是由可信发起方发送的。4.3双窗口单点登录攻击我们确定了双窗口SSO中的三种攻击,这些攻击尚未成为SSO社区前两种攻击的目标是机密性;第三种攻击的目标是SSO消息的真实性安全相关SSO消息。SSO登录过程中最关键的消息是登录响应。 它包含授予访问受害者身份和资源的机密令牌。因此,必须保护其机密性,使其只能由发出相关登录请求并获得受害者同意的授权SP接收。类似地,仅允许接收到登录请求的IdP向SP发出相关登录响应总之,攻击者的目的是(1) 从受害者在SP上启动的流接收登录响应,以及(2)向SP发送恶意构建的登录响应5在SSO中,状态查询参数[24,§ 10.12]用作IdP和SP之间共享的秘密,以确保位置写入是真实的。CCSLouis Jannett、Vladislav Mladenov、Christian Mainka和JörgSchwenk1558攻击影响:丧失信心。(1) 令牌泄漏(TL):如果身份验证令牌泄漏给攻击者,则可能发生身份盗窃、帐户接管和非特权资源访问。根据代币兑换的隐秘性,受害者可能不会注意到攻击者的帐户访问。(2) 隐私泄露(PL):如果隐私数据泄露给攻击者,受害者的身份可能会被泄露。同样,其他用户身份信息,如受害者的电子邮件,地址和个人资料图片可能会泄露。 我们认为令牌泄漏使帐户接管作为固有的隐私泄漏。攻击影响:失去真实性。(1) 跨站点帐户登录(XSAS):受害者登录到攻击者的帐户,允许攻击者跟踪受害者的活动。例如,如果受害者上传了一个文件,它被上传到攻击者的帐户,攻击者可能会检索它。(2) 跨站点帐户链接(XSAL):受害者已经使用凭据登录SP的网站(即,用户名和密码)。之后,受害者决定将SP上的帐户连接到IdP。如果攻击者发送恶意登录响应,受害者受害者仍然可以使用凭据登录SP。在顶部,攻击者可以使用SP图2:双窗口单点登录中的攻击。受害者帐户接管)。(3) 基于DOM的跨站点脚本(DOM-XSS):SP在启用DOM-XSS的JavaScript接收器中处理登录响应[33],如eval()和innerHTML。攻击者发送恶意登录响应以利用接收器并获取SP上的DOM-XSS攻击1:通配符接收器攻击(WRA)。 图2描述了利用WRA接收登录响应的恶意网站。攻击的工作原理如下:受害者访问恶意网站,该网站模仿受害者在其上拥有SSO帐户的SP。恶意站点启动通常由SP启动的SSO登录流。因此,攻击者将SP的登录请求发送双方都成功地验证了应该接收登录响应的给定源(即,sp.com),是真实可信的。因此,IdP生成登录响应,该登录响应被返回给恶意网站。我们区分两种情况:(1) 直接通信:IdP直接将登录响应返回给主窗口。然而,IdP无法保护其机密性,因为跨域Web消息传递在此上下文中使用不安全。 postMessage字符串“*”允许所有源接收登录响应。因此,IdP将可能包含令牌或隐私敏感数据的登录响应泄漏到攻击者的站点。iframe流和直接弹出流都使用直接通信。(2) 中继通信:在这种情况下,IdP首先使用URL重定向将登录响应返回到弹出窗口中运行的SP。其次,SP使用不安全的InBC将登录响应从弹出窗口返回到主窗口。因此,SP将登录响应泄漏到攻击者中继通信仅在中继弹出流中使用。攻击2:恶意接收器攻击(Malicious Receiver Attack,MRA) 图2显示了MRA,它与WRA密切相关,但具有额外的扭曲。安全地使用InBC技术postMessage和JS Navigate,因为它们显式地包括接收者的来源以保护机密性。然而,通配符接收器攻击(WRA),未指定登录响应的接收器来源。在恶意接收器攻击(Malicious ReceiverAt- tack中,没有正确地验证登录响应的接收器因此,认证令牌可能泄漏。在恶意启动器攻击(MIA)中,SP不验证登录响应的启动器因此,恶意站点可以注入恶意登录响应或JavaScript代码。SP或IdP未验证或未正确验证接收方因此,攻击者将SP登录响应最终被发送到在主窗口中运行的未经验证的源attacker.com攻击3:恶意发起者攻击(MIA)。图2显示了MIA。攻击者的网站模仿IdP向SP发送登录响应。在MIA中,SP没有或没有正确地验证登录响应的真实性对抗这种攻击的最佳做法是对发起者的origin执行字符串比较,例如,验证InBM.origin ==?po s t M e s s a g e 中 的“https://idp.com“。易受攻击的检查的示例包括使用过于宽松的正则表达式或字符串比较方法(如startsWith和includes)进行比较。我们的攻击假设攻击者在IdP上有一个帐户,并在SP上执行SSO流因此,攻击者从IdP接收 如果受害者访问恶意站点,则攻击者向SP发送恶意登录响应,这会产生以下影响:(1)SP使用登录响应将受害者登录到攻击者的帐户(参见XSAS,§4.3)。(2)如果受害者已经登录在SP上,则SP将受害者的帐户链接到攻击者在IdP上的帐户(参见XSAL,§4.3)。(3)SP将登录响应传递到危险的JavaScript接收器,如eval。攻击者修改登录响应以利用接收器并获得XSS在SP上(cf.DOM-XSS,§4.3)。DISTINCT:在双窗口单点登录中使用浏览器内通信的身份盗窃CCS1559图3:DISTincTChrome扩展程序(Live-MoniT or)将所有InBC技术及其InBM以报告形式发送到后端(CommunicaTion- InspecT or),后端对其进行后处理,并输出一个突出显示威胁的序列图。5DISTINCT:动态浏览器内单点登录跟踪器检测新的通信技术先前的研究通过分析HTTP流量来评估SSO实现。 这种方法在运行时错过了通过InBC技术发送的关键SSO消息。 我们是第一个填补这一空白的人,我们将DIST NCT作为开源贡献提供给SSO实施者、研究人员和测试人员,提高了对双窗口SSO安全隐患的认识。 D I st I nct自动执行(1)捕获,(2)检测,(3)可视化,(4)安全分析,(5)利用InBC的双窗口SSO流5.1设计和建筑DI stI nct被设计为监视和分析在运行时跨窗口发送InBM因此,DI stI nct执行两个组件:LIVE-MonI toR和CommU nI cA tI on-InspectoR(参见图3)。件. (1)LIVE-MonI toR是一个Chrome扩展程序,它通过NoVNC6连接。浏览器自动加载LIE-MONI到R并导航到目标网站。接下来,分析人员必须手动定位并单击网站 如果IdP的凭证已预配置,则IdP上的身份验证和同意步骤将自动执行。否则,分析师必须在IdP上手动验证并单击同意按钮。 在整个登录流程期间,LIVE-MONI to R自动将所有InBC报告给Comm un I CA T I ON-INSPECTOR R,COMM un I C A t I on-Inspector r启动自动后处理。最后,分析人员可以在Web界面中手动检查分析结果它显示登录流的序列diagram,显示检测到的安全威胁。 如果检测到威胁,分析人员可以触发自动攻击,手动验证其成功与否,并在必要时执行较小的更改。分析方法。为了分析SSO相关的InBM,我们需要检测JavaScript中InBC技术所使用的API调用。因此,我们研究了静态和动态JavaScript分析方法。静态分析在浏览器执行JavaScript代码之前对其进行调查。虽然在许多情况下这是一种合理的方法(2)我们无法检测到执行脚本的窗口。(3)JavaScript的简化和模糊化使分析复杂化。这些原因阻碍了SSO流重建,因此我们决定使用动态分析。动态分析监视在运行时执行的代码以检测API调用。作为副作用,运行时分析解决了由JavaScript缩小和混淆引起的挑战它还提供了有关代码执行时间的固有信息,我们可以确定运行它的窗口因此,我们认为动态分析是一种强大的方法,用于在执行时间和窗口中捕获InBC技术的API调用。5.2实时监控在所有浏览器窗口的上下文中运行(即,主窗口、iframe和弹出窗口),将监控脚本注入每个页面,并访问整个网站,包括其DOM
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 5
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 十种常见电感线圈电感量计算公式详解
- 军用车辆:CAN总线的集成与优势
- CAN总线在汽车智能换档系统中的作用与实现
- CAN总线数据超载问题及解决策略
- 汽车车身系统CAN总线设计与应用
- SAP企业需求深度剖析:财务会计与供应链的关键流程与改进策略
- CAN总线在发动机电控系统中的通信设计实践
- Spring与iBATIS整合:快速开发与比较分析
- CAN总线驱动的整车管理系统硬件设计详解
- CAN总线通讯智能节点设计与实现
- DSP实现电动汽车CAN总线通讯技术
- CAN协议网关设计:自动位速率检测与互连
- Xcode免证书调试iPad程序开发指南
- 分布式数据库查询优化算法探讨
- Win7安装VC++6.0完全指南:解决兼容性与Office冲突
- MFC实现学生信息管理系统:登录与数据库操作
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功